Three Approaches to OT Security Enforcement
Every OT security architecture boils down to where you place the enforcement point. There are exactly three options:
- Agent-based: Install software on each endpoint (PLC, HMI, RTU, engineering workstation) that enforces policy locally.
- Firewall-based: Place network appliances at segment boundaries that filter traffic based on IP addresses, ports, and protocols.
- Proxy-based: Insert a mediating layer between the user and the target asset that intercepts, authenticates, and controls every session.
Each approach has different implications for OT environments. The differences matter because OT networks contain devices that were never designed with cybersecurity in mind, run for decades without updates, and cannot tolerate unplanned downtime.
Why Agents Fail in OT
Agent-based security works well in IT. Every laptop and server runs an OS that supports endpoint agents. OT is different.
PLCs and RTUs don't run security agents — never have, never will. A Siemens S7-300 runs a proprietary real-time operating system. An Allen-Bradley ControlLogix doesn't have a general-purpose OS. A 15-year-old Wonderware HMI running Windows XP Embedded may not support modern agent software.
The problems stack up fast:
- Warranty and support: Installing third-party software on a PLC or safety controller voids the manufacturer's warranty and support agreement.
- Requalification: In regulated industries (pharma, nuclear, defense), any software change on a validated system triggers a requalification cycle that can take months and cost six figures.
- Real-time performance: Agents consume CPU cycles. On a PLC with a 10ms scan cycle controlling a physical process, any additional load is a safety risk.
- Coverage gaps: Even if you deploy agents on every Windows-based HMI and engineering workstation, the PLCs, RTUs, and field devices remain unprotected. You get partial coverage at best.
- Maintenance burden: Agents need updates. Pushing updates to hundreds of OT devices across multiple sites, each with its own maintenance window, is operationally expensive.
Agent-based security assumes a homogeneous, updatable endpoint population. OT networks are the opposite.
Why Firewalls Are Insufficient
Firewalls are the default security control in most OT environments. They sit at network boundaries (typically between IT and OT, or between Purdue Model levels) and filter traffic. They help, but they have structural limitations for zero-trust enforcement.
Firewalls operate at L3/L4. A traditional firewall sees source IP, destination IP, source port, destination port, and protocol type. An industrial firewall may also parse some L7 protocols. But fundamentally, firewalls make allow/deny decisions on connections, not on sessions.
Here is what firewalls cannot do:
- Identity-based access: A firewall sees an IP address, not a user. If three engineers share a jump host, the firewall cannot distinguish between them.
- Per-session policy: Once a connection is allowed, the firewall has no visibility into what happens within that session. A Modbus TCP connection is either allowed or blocked; the firewall cannot permit function code 3 (read) while blocking function code 6 (write).
- Session recording: Firewalls log connection metadata (source, destination, timestamp). They do not record session content.
- Granular access control: You can restrict which IPs can reach which IPs. You cannot restrict which user can access which asset, at which time, for which purpose.
Firewalls reduce the attack surface. They do not enforce zero-trust access control.
Why Proxies Are the Right Architecture for OT
A proxy-based architecture places an intermediary between the user and the target asset. The user connects to the proxy. The proxy authenticates the user, evaluates the access policy, and then opens a separate connection to the target device on the user's behalf. The user never has direct network access to the asset.
This architecture solves every limitation of agents and firewalls:
- No endpoint modification: The proxy sits on the network, not on the device. PLCs, RTUs, HMIs, and legacy systems remain untouched. No software installation, no warranty issues, no requalification.
- Identity at the session level: The proxy authenticates the user before the connection is established. Every session is attributed to a named individual, not an IP address.
- Protocol-aware mediation: A proxy can inspect industrial protocols at the application layer. For Modbus TCP, it can distinguish between read and write function codes. For OPC UA, it can enforce node-level access. For RDP and VNC sessions to HMIs, it can record screen activity.
- Per-session policy enforcement: Access rules can specify that Engineer A can read Modbus registers on PLC-12 during business hours, but cannot write. Vendor B can access HMI-7 via RDP for a 4-hour maintenance window, with session recording enabled.
- Session recording for compliance: Because all traffic passes through the proxy, every session can be recorded, indexed, and made available for audit. This directly satisfies CMMC and NIS2 requirements for traceable user actions.
- Air-gap compatible: The proxy runs on-premise, within the OT network. It does not require cloud connectivity. It works in fully air-gapped environments.
- Invisible to endpoints: The target device sees a connection from the proxy, using standard industrial protocols. No special client software, no protocol modifications, no changes to the endpoint configuration.
Comparison: Agent vs. Firewall vs. Proxy
| Capability | Agent-Based | Firewall-Based | Proxy-Based |
|---|---|---|---|
| Endpoint modification required | Yes (software on every device) | No | No |
| Protocol awareness | Limited to host-level activity | L3/L4, some L7 parsing | Full L7, protocol-specific mediation |
| Session-level control | Partial (host-level only) | No (connection-level only) | Yes (per-session, per-user) |
| Identity integration | Per-host identity | IP-based only | Per-user, per-session identity |
| Session recording | Possible on host | No | Yes (all protocols) |
| Air-gap compatibility | Requires local management | Yes | Yes |
| Deployment impact | High (install on every device) | Medium (network changes) | Low (deploy alongside existing network) |
How This Works in Practice
The Access Gate implements proxy-based security as an on-premise appliance or VM. It deploys at the network level, creates an encrypted overlay, and becomes the single point through which all remote and internal access flows.
The deployment pattern:
- Install the Access Gate appliance or VM on the OT network. No changes to existing devices or network topology.
- Define access policies based on user identity, target asset, protocol, time window, and allowed operations.
- Connect users through the Access Gate. Users authenticate (with MFA), the proxy evaluates the policy, and a mediated session is established.
- Record and audit. Every session is logged with full attribution: who accessed what, when, for how long, and what they did.
The target devices see normal protocol traffic. The users see their normal tools (RDP client, Modbus client, web browser). The security team sees every session, attributed to a real identity, with full recording.
Proxy-based security is not a theoretical model. It is the only architecture that delivers zero-trust access control in OT without requiring changes to the devices you are protecting. For a practical comparison of how proxy-based overlay networking compares to traditional VLAN segmentation, see overlay networking vs VLANs for OT. If your security strategy depends on installing software on a PLC, it is already broken.
