Configure Modbus Access

Control Modbus/TCP access to PLCs and RTUs — default-deny on port 502, identity-scoped grants, and TLS for a protocol with no encryption of its own.

Modbus is the workhorse protocol of the OT network — PLCs, RTUs, and field devices reading and writing registers over TCP port 502. It has no authentication and no encryption of its own: anything that can reach the device can read or command it. Access Gate puts identity, policy, and encryption in front of Modbus so only sanctioned systems talk to a controller.

What You Get

Default-deny on 502. Nothing reaches the controller's Modbus port unless an explicit ACL rule allows it. This alone removes the "any host on the LAN can command the PLC" exposure.
Identity-scoped peer access. Modbus is usually machine-to-machine — a SCADA server or historian polling a PLC. Grants are written between assets (or groups of assets), so only the SCADA host reaches the PLC, and nothing else does.
TLS for a protocol that has none. Modbus/TCP is plaintext. The gate can wrap the session in TLS between the master and itself, then forward the request to the field device over the protected segment — so traffic is encrypted in transit and the legacy PLC needs no cryptographic capability of its own.

Set It Up

Add the controller to an enclave — see Protecting an asset with enclaves.
In Enclaves → [Your Enclave], add an allow rule for the modbus protocol — or tcp:{custom_port} if the device runs Modbus on a non-standard port.
Set the principal to the specific system that should talk to the PLC — typically another asset (the SCADA server or historian), or a group of polling hosts.

Modbus enclave allowing a single master to reach the controller

Worked Example: Securing an HMI-to-Pump Link

The images below trace commands from an HMI reaching a pump through the Access Gate. The enclave is configured so only the HMI can reach that pump and push commands to it — nothing else on the network can.

Before — access control only

From the HMI, we read and then write the VFD speed to 55, and stop the pump.

Read and write commands sent from the HMI

The commands are processed and received by the pump.

The pump's logs showing the received commands

After — adding TLS encryption

Open the rule's Advanced Configuration and require TLS. Access Gate maintains a TLS tunnel between the HMI and the pump to encrypt the traffic. Modbus traffic is encrypted in transit from the master to the Access Gate, which authenticates the session, enforces enclave policy, and forwards the request to the field device over the protected segment. The legacy PLC requires no cryptographic capability of its own. For how this differs from native Modbus/TCP, see The Difference Between Secure Modbus and Modbus TCP.

Encrypted Modbus connection through the Access Gate

Notes & Gotchas

Don't break the control loop. Before enforcing, observe real Modbus traffic so you know which systems legitimately poll or command the device — turn on inspection first and translate observed flows into rules, as in the Quick start.
Latency budgets. Modbus polling can be tight. Inline enforcement adds a small, deterministic amount of latency. Validate against your scan-cycle requirements.
Unit IDs behind a gateway. A single Modbus/TCP endpoint can front multiple serial devices by unit ID. Map which unit IDs sit behind a gateway so a rule covers the devices you intend.
Other OT protocols. The same default-deny, identity-scoped model applies to other industrial protocols on the network — Modbus is the most common starting point, not the only one.