What is an industrial proxy?
A security proxy built for OT. It brokers every session in front of PLCs, HMIs, SCADA, and the legacy IT servers you cannot secure at the asset, understands industrial protocols, needs no agent on the device, and is engineered for uptime with failover and a logged break-glass path.
Last updated:
An industrial proxy sits in the access path in front of an asset you cannot secure on its own, terminates each session, authenticates the user, authorizes the specific command, and records it, before anything reaches the PLC, HMI, SCADA server, or legacy application server behind it. It differs from a generic forward or reverse proxy in three ways that matter for OT: it is protocol-aware (Modbus, DNP3, S7comm, and more), agentless on the asset, and built for resilience. Trout Software's Access Gate is an industrial proxy.
Placement is a deployment choice. The proxy can sit inline, as a transparent enforcement point that nothing reaches the asset around, or out of band, with sessions routed to it. That choice balances security against performance: inline cannot be bypassed, out of band adds no risk to the running process. Either way the real-time control loop and any safety system stay off the enforcement path, so the process takes no added latency or jitter and keeps running if the proxy is offline.
What makes a proxy industrial?
A web proxy relays HTTP for browsers. An industrial proxy mediates access to assets that were never meant to be reached and cannot defend themselves. Five properties separate the two.
Protocol-aware
It parses OT protocols such as Modbus, DNP3, and S7comm and enforces at the command and register level, not just the port.
Agentless on the asset
The PLC, HMI, SCADA server, or legacy application server installs nothing and never changes. All enforcement happens at the proxy.
Built for resilience
Because OT prioritizes uptime, it runs with failover and a break-glass path so it does not become a single point of failure for the running process.
Identity-bound and recorded
Every session is tied to an authenticated identity, restricted to what that identity may do, and recorded end to end for audit.
Least privilege, just in time
Access is scoped per asset, protocol, and command, and time-boxed for vendors, so standing access is retired instead of managed.
Where it sits, and where it does not touch
Plants are layered, roughly along the Purdue model: sensors and actuators at Level 0, controllers at Level 1, supervisory HMI and SCADA at Level 2, site systems like the historian at Level 3, an industrial DMZ at Level 3.5, and enterprise IT above. An industrial proxy enforces access across those boundaries. Where it belongs, and where it must not, is the first thing a controls engineer will check.
It governs the access path, not the control loop.
The proxy mediates the north-south sessions that people, vendors, and engineering workstations use to reach an asset. The east-west control loop, the cyclic I/O, and the safety system are kept off the enforcement path, so they never depend on it and take no added latency.
Inline or out of band is a deliberate choice.
It can be placed inline as a transparent enforcement point that cannot be bypassed, or out of band with sessions routed to it. Inline maximizes security; out of band removes any risk to the running process. The right answer is a per-site balance of security against performance, not a default. Where it is placed inline on a segment that also carries control traffic, it is engineered to be transparent to that timing.
It fronts OT assets and the legacy IT you cannot replace.
The same pattern that brokers Modbus to a PLC brokers RDP, VNC, SSH, or HTTPS to a legacy Windows or application server running a custom, unsupported, or unpatchable program. Any asset you cannot harden at the asset itself, controller or server, gets identity-bound, recorded, least-privilege access in front of it.
An industrial proxy governs the access path to a controller, not the control loop inside it. Remove it and a vendor can no longer reach the asset. The process the asset is running does not skip a beat.
What "protocol-aware" actually means
Protocol awareness is the property that separates an industrial proxy from a TCP relay or a port-based firewall rule. A port filter can allow or block 502/tcp, but the port is a weak signal: a service, or an attacker, can run a protocol on a port that is not its default, or tunnel one protocol inside another the firewall already allows. Access Gate puts compute on the wire, so its parser detects and validates the actual protocol from the traffic itself, not from the port it arrived on. From there it performs a protocol break: it terminates the session, parses the application-layer message, and enforces policy on the actual operation before it forwards anything to the asset. That is what lets you grant a vendor read-only telemetry on one machine while denying every write, with one rule instead of a network redesign.
| Protocol | Default port | What protocol-awareness enforces |
|---|---|---|
| Modbus/TCP | 502 | Carries a function code and register range. Allowlist function 3 (read) while denying function 16 (write multiple) to the coil that starts a pump. Modbus has no authentication of its own, so the proxy is the only place that decision can be made. |
| Siemens S7comm / S7comm-plus | 102 | The dangerous operations are not reads, they are CPU stop/start and block download, which change the running logic. The proxy can allow a maintenance read while blocking or recording a program download as its own event. |
| EtherNet/IP + CIP | 44818 · I/O 2222 | The clearest case for the control-loop rule. Implicit I/O on UDP 2222 is the cyclic real-time data that runs the machine and stays off the proxy. Explicit messaging on 44818 is configuration and programming, and that is what you broker. |
| DNP3 | 20000 | Common in water and electric outstations. Its Secure Authentication is rarely enabled. Protocol awareness means brokering control commands differently from polls, over links that are often slow or intermittent. |
| OPC UA | 4840 | Session-based and capable of real security, but frequently deployed with the None security policy in the field. The proxy enforces at the session and node level rather than trusting how the server was left configured. |
| IEC 60870-5-104 | 2404 | Telecontrol for electric utilities. The proxy distinguishes control commands from monitoring traffic and binds each to an identity the protocol itself cannot carry. |
| MQTT | 1883 · TLS 8883 | Publish/subscribe telemetry, increasingly the northbound path off the floor. Protocol awareness means topic-level control and telling a publish from a subscribe, not just opening a broker port to everyone. |
| BACnet/IP | UDP 47808 | Building automation and management. The proxy can allow a read of a sensor object (present-value) while denying a write to a setpoint or an override of a life-safety point. |
| Profinet | L2 (no TCP port) | The clearest stays-on-the-underlay case. The cyclic real-time channel (RT/IRT) is never brokered and must not traverse enforcement; the acyclic configuration and device-management traffic (DCP) is what the proxy governs. |
For the human and legacy-IT access layer, the same break applies to RDP, VNC, SSH, and HTTPS, so reaching a Windows or application server is brokered, scoped, and recorded exactly like reaching a controller.
The rule underneath all of it: broker the human, vendor, and management access to the asset, and leave the cyclic control and safety traffic on its own path. Deep packet parsing adds latency, and a control loop has no tolerance for it. The proxy belongs in the access path, not in the loop that keeps the process running.
Where an industrial proxy earns its place
Most OT access is not a person at a plant HMI. It is someone from outside the control room who needs to reach one machine, for one reason, for a short time. That is the traffic an industrial proxy is built to broker. Six cases cover most of it.
Vendor access to one controller for one task
An OEM needs to tune a drive or pull a fault log off a single PLC. The old answer was a VPN into the cell or a cellular modem left behind. The proxy replaces both: one asset, one protocol, time-boxed, recorded, and nothing else in reach.
Support on expensive, contract-bound equipment
A five-axis machining center or a packaging line ships with a service contract that assumes remote diagnostics. Rather than let the builder install an out-of-band connection you do not control, you front the machine with the proxy and give scoped, logged access to that asset and nothing adjacent.
Break-glass during an incident
At 2 a.m. people need a fast way in, and fast usually meant unlogged in the old model. The proxy gives operators a documented emergency path that is still bound to a named person and still recorded, so the one time you most need the record, you have it.
Commissioning and startup
Integrators need broad reach for a few weeks, then none. Open wide access for the commissioning window, scope it to the cell being built, record it, and revoke it cleanly at handover, instead of leaving standing integrator accounts behind.
Firmware and logic changes
A program download is the highest-consequence action on a controller. Brokering it through the proxy means the one action that changes what the machine physically does is authenticated, authorized, and recorded as a distinct event, not buried in a flat session.
Legacy IT and application servers
An old Windows server running a bespoke, unsupported line-of-business or SCADA application cannot be patched or replaced on any near horizon. The proxy fronts it over RDP, VNC, SSH, or HTTPS, so access to the software you depend on and cannot modernize is still identity-bound and recorded.
How it compares to the tools you already have
A team researching an industrial proxy is really asking how it differs from the tools already in the rack. A firewall filters traffic between zones. A VPN grants network reach. A jump host forces a chokepoint. A data diode enforces one-way flow. None of them authenticate a named person to a specific command on a specific asset and record it. That gap is the proxy's job.
| Tool | Identity-bound | Per-command | OT protocol-aware | Records session | Agentless on asset | Interactive access |
|---|---|---|---|---|---|---|
| Industrial proxy | Yes | Yes | Yes | Yes | Yes | Yes |
| Firewall / NGFW | No | No | Partial | No | Yes | n/a |
| VPN | No | No | No | No | Client needed | Yes |
| Jump host / bastion | Often shared | No | Rarely | Partial | Yes | Yes |
| Data diode | No | No | n/a | n/a | Yes | One-way only |
- Firewall, even application-aware: filters traffic by rule between zones. It does not authenticate a person, bind the session to their identity, or record what they did inside an allowed flow. Complementary, not equivalent.
- VPN: grants network reach. Once connected, the user is on the network and can reach whatever routing allows, with no notion of the specific asset or command. A VPN answers whether a device may join the network. A proxy answers whether an identity may perform an operation. See secure OT remote access.
- Jump host / bastion: better than a flat VPN because it forces a chokepoint, but it still tends to rely on shared credentials, gives a foothold rather than per-command control, and rarely parses OT protocols. An industrial proxy is the OT-aware, identity-bound, recorded evolution of the jump host.
- Data diode: hardware-enforced one-way flow, excellent for exporting telemetry out of a zone with physical certainty. By design it cannot broker an interactive maintenance session, so it does not solve vendor access. A different tool for a different job.
A VPN extends your network to a person. An industrial proxy extends one authorized action to one asset, and nothing else.
Forward, reverse, and where the industrial proxy fits
A forward proxy sits in front of clients and mediates their outbound requests, for web filtering or egress logging. A reverse proxy sits in front of servers and mediates inbound requests to them, for load balancing or TLS termination. An industrial proxy is architecturally a reverse, or mediating, proxy: it fronts the protected asset and terminates the session on both sides, so nothing the client sends reaches the controller unexamined. The label that matters is not forward or reverse. It is that this proxy is protocol-aware for OT, identity-bound, agentless on the asset, and engineered for availability.
An industrial proxy is a reverse proxy with a security mandate: it fronts the asset, terminates the session, and forwards only the exact operation policy allows.
What happens when the proxy fails
Operators do not ask whether a device in the path is secure. They ask what breaks when it dies. Answering that plainly is the reason an industrial proxy is safe to deploy on a running plant.
The process keeps running.
Because the proxy governs the access path and not the local control loop, a dead proxy stops new access sessions, not the process. The line keeps running on its own controllers and HMIs. You lose the ability to reach in from outside until it recovers. You do not lose the plant.
Fail-open versus fail-closed is a deliberate, per-asset decision.
Fail-closed protects the asset but can block a legitimate operator in an incident. Fail-open preserves access but drops enforcement. In OT that choice is made per asset and logged, never left to a default. The resilient answer is to remove the dilemma where possible with a high-availability pair, so a single fault never forces it.
Break-glass is available and recorded.
The emergency path is itself authenticated and logged, so the route you reach for in a crisis does not become an unaudited backdoor.
Historian and polling continuity is preserved.
Continuous collection stays on a path designed for it, so enforcement on human and vendor access never puts gaps in the historical record the plant runs its decisions on.
Agentless is an operations decision, not only a security one.
Most controllers cannot host an agent, and the HMIs and workstations that can often sit in validated or vendor-supported configurations you cannot modify without breaking support. Nothing on the asset means nothing new to patch, nothing to re-certify, and nothing that can crash the device you cannot afford to reboot.
The moment a proxy enters the access path, its failure mode becomes a safety decision. Fail-open, fail-closed, and break-glass are chosen per asset and logged, never left to a default.
The evidence an industrial proxy produces
A control that cannot produce a record is a hope, not a control. For every asset behind it, an industrial proxy should let an operator export the following, on demand.
- The named identity behind each session, not an IP or a shared account.
- The per-asset and per-command scope that identity was allowed.
- A command-level record of which protocol operations and register writes reached the asset, and which were blocked.
- Tamper-evident, time-synced logs with a stated retention period.
- Coverage tied to the asset inventory: which assets sit behind enforcement.
- Proof the control cannot be bypassed: in-path enforcement, with break-glass logged.
With Access Gate this evidence stays on-premise, not in a vendor cloud, which matters for sovereignty and for regulators who ask where audit data lives.
A control that cannot produce an identity-attributed, command-level record is not an access control. An industrial proxy exists to produce that record.
How it maps to the standards you answer to
An industrial proxy is the enforcement point the frameworks already describe. Naming that mapping is the fastest way to place it in an existing compliance program.
| Framework | What the proxy provides |
|---|---|
| NIST SP 800-207 (Zero Trust) | The proxy is the Policy Enforcement Point in the data path, acting on allow/deny decisions from a policy decision point. This is the cleanest one-line mapping. |
| IEC 62443 | A conduit enforcement point between zones (62443-3-2). It supplies foundational requirements a legacy device cannot: FR1 identification and authentication, FR2 use control, FR3 system integrity, FR5 restricted data flow, FR6 timely response to events. See the PLC security pillar for the full mapping. |
| NIST SP 800-82 Rev 3 | Aligns with its guidance on remote access, least privilege, and monitoring for ICS. |
| NERC CIP-005 | Can serve as the Intermediate System that Interactive Remote Access must route through, and can determine and disable an active vendor session. See NERC CIP compliance. |
In Zero Trust terms an industrial proxy is the Policy Enforcement Point for OT: the place where never trust, always verify stops being a slogan and becomes a session that was checked and recorded.
You cannot modernize every asset. You can put a modern proxy in front of it.
Most OT protocols have no native authentication or encryption, and most controllers cannot be patched to add it. The same is true of the legacy IT servers running software no one will rewrite. Replacing them is a multi-decade program. An industrial proxy inserts modern identity, authorization, encryption, and audit in front of the existing asset, with no change to the asset and no downtime. It is the practical way to bring Zero Trust to a plant that cannot be rebuilt.
What to ask before you buy one
Each item below is a real discriminator. Ask for the answers in a demo, not a datasheet.
- 01Which OT protocols does it parse, and can it enforce at the function-code / register level, not just the port?
- 02Is it truly agentless on the controller, HMI, SCADA server, and legacy application server?
- 03Does it run high-availability with failover, and what is its documented fail-open / fail-closed behavior?
- 04Is the break-glass path logged?
- 05Does it bind sessions to your identity provider (Active Directory, Entra ID, SAML, RADIUS) with MFA at the network layer?
- 06Does it record command-level sessions, and can you export the evidence on-premise with a stated retention period?
- 07Does it require re-IP, rewiring, or a VLAN redesign to deploy? It should not.
- 08Can it be placed inline or out of band, so you can choose the security-versus-performance balance per site?
- 09Can it determine and disable an active session on demand?
- 10Does any part of it depend on a vendor cloud to function?
If a proxy cannot tell a read from a write, it is a firewall with extra steps. Ask for function-code enforcement in the demo, not the datasheet.
The industrial proxy, answered
An industrial proxy is a security proxy purpose-built for operational technology. It sits in the access path in front of a PLC, HMI, SCADA server, or legacy application server, terminates each session, authenticates the user, authorizes the specific command against policy, records it, and forwards only what is allowed. Unlike a generic web proxy, it understands OT protocols such as Modbus, DNP3, and S7comm, and it is built for resilience with failover and a break-glass path. Trout Software's Access Gate is an industrial proxy.
A forward proxy sits in front of clients and mediates their outbound requests. A reverse proxy sits in front of servers and mediates inbound requests to them. An industrial proxy is a mediating proxy in the access path: it terminates the session on both sides and acts as a bastion between the person requesting access and the OT asset. The difference that matters is not forward versus reverse, it is that the industrial proxy is protocol-aware for OT, agentless on the asset, and engineered for availability.
A VPN grants network reach: once connected, the user is on the network and can reach whatever routing and firewall rules allow. An industrial proxy grants one authorized action on one asset and records it. For OT remote and vendor access, the proxy is the safer model because it scopes access to a specific asset, protocol, and command rather than handing over the network.
It is the OT-aware, identity-bound, recorded evolution of the jump host. A classic jump host forces a chokepoint but often relies on shared credentials, gives a network foothold rather than per-command control, and rarely parses OT protocols or produces command-level audit. An industrial proxy fixes all three.
A data diode enforces hardware one-way flow, which is excellent for exporting telemetry out of a zone with physical certainty. By design it cannot broker an interactive, bidirectional maintenance session, so it does not solve the vendor and remote access problem most operators actually have. The two are complementary, not alternatives.
No. A firewall, even an application-aware one, inspects and filters traffic between zones. It does not authenticate a person, bind the session to their identity, or record what they did. An industrial proxy decides whether this specific user, in this specific session, may send this specific command to this specific asset, right now, and keeps the full record. A firewall filters. A proxy mediates and attributes.
It does not, because it governs the access path, not the real-time control loop. The cyclic I/O and safety traffic are kept off the enforcement path. Where the proxy is placed inline on a segment that also carries control traffic, it is engineered to be transparent to that timing.
With a high-availability pair and the control loop kept off the proxy, a proxy outage stops new access sessions, not the running process. The line keeps running on its own controllers and HMIs. A break-glass path is available and logged. Fail-open versus fail-closed is chosen per asset, not left to a default.
Both are supported and it is a deployment choice. Inline placement is a transparent enforcement point that cannot be bypassed. Out-of-band placement routes sessions to the proxy and adds no risk to the running process. The right option is a per-site balance of security against performance.
Yes. The same pattern that brokers Modbus to a PLC brokers RDP, VNC, SSH, or HTTPS to a legacy Windows or application server running custom, unsupported software. Any asset you cannot secure at the asset itself, controller or server, can get identity-bound, recorded, least-privilege access in front of it.
At the zone boundary you are enforcing, typically Level 3 or 3.5 reaching down to Levels 2 and 1, as the single brokered doorway into the zone. It governs the north-south access sessions and stays off the east-west real-time control loop.
The PLC installs nothing. The proxy stands in front of it: the operator or vendor connects to the proxy, which authenticates them, checks the specific Modbus or DNP3 request against policy, records the session, and forwards only authorized traffic. A twenty-year-old PLC that cannot run an agent gets identity-bound access, authorization, and audit it could never host itself.
Access Gate secures your assets first, then exposes the simple services your teams and vendors actually want, so they run through the sanctioned path, not around it.
OT runs through you, not around you.