Secure OT remote access, done right.
Staff and vendors reach your industrial systems from off-site, with real freedom to do the work, but every session brokered, recorded, and kept on-premise. More than a VPN tunnel, and more than a cloud access broker.
Secure OT remote access lets staff and third-party vendors reach industrial systems from off-site without extending the network to them. Done properly it means four things: identity for both internal and external users, a full proxy that brokers and records every session in front of the asset, least-privilege access per task, and no dependence on an external cloud. That is a different thing from a VPN tunnel or a cloud-hosted access broker. Trout's Access Gate is built for it.
Your engineers and their vendors, under one policy
The hard part of OT remote access is that the people who need it do not all live in your directory. Employees authenticate through your corporate identity provider. The integrator, the OEM, and the maintenance contractor often have no account with you at all. Most tools handle one case or the other. Trout connects multiple identity systems and, for outside parties with no account, anchors identity and MFA at the gateway, so internal and external access run through the same brokered, recorded, least-privilege path.
Freedom to act, with a full record of what was done
A VPN gives a tunnel and then trusts the user. A full proxy terminates the session on both sides and stands in the path in front of the asset. The operator still gets real, interactive access to do the actual work, not a locked-down keyhole, but every command is checked against policy, the whole session is recorded, and the result is compliance evidence you can hand to an auditor. Freedom and accountability stop being a trade-off.
Because the proxy is protocol-aware, it can allow a vendor to read a sensor but not command the associated controller, and the rule lives at the network, not in the endpoint's configuration, so it holds even if the endpoint is compromised.
The access path stays inside your environment
The gateway and its logs run in your own environment. No session traffic and no audit data route through an external vendor cloud, and there is no third-party data processor sitting in the access path. That also removes a dependency: remote access does not rely on an internet link to a cloud service to function, and the audit trail is not held by someone else. Local operation and the record survive an outage. For a cloud-hosted access broker, none of that is true.
What makes it built for OT
Six properties separate a purpose-built OT access proxy from a generic tunnel or a cloud broker.
Identity for staff and vendors
Employees authenticate through your corporate identity provider; outside vendors who have no account in your directory are given an identity and MFA at the gateway itself. One policy plane governs both, so internal and external access follow the same rules.
Protocol-aware, not port-based
The proxy parses OT protocols such as Modbus and DNP3 and enforces at the command and register level, not just the port. A user can be allowed to read a value but not to write one.
Agentless on the asset
Nothing is installed on the PLC, HMI, or SCADA server and nothing changes on it. Legacy controllers that cannot authenticate or record a session get identity-bound, recorded access they could never host themselves.
Least privilege, per session
Access is granted to one system, for one task, for a limited time, then revoked. There is no standing connection to the control network waiting to be abused.
Built for uptime
The gateway sits in the remote-access path, not the live control loop, with failover and a break-glass path. On-site operation continues if it is offline, and it adds no latency to the running process.
Tamper-evident audit
Every session is recorded end to end, identity, commands, duration, and results, stored out of the user's reach and usable by a SIEM or in a forensic review.
VPN vs. cloud broker vs. on-premise proxy
| Capability | VPN tunnel | Cloud access broker | Trout Access Gate |
|---|---|---|---|
| Identity for outside vendors | Shared account, often | Yes, via their cloud | Yes, anchored on-premise |
| Session recording for audit | No | Partial, in the cloud | Full, tamper-evident, on-premise |
| Protocol-aware (Modbus, DNP3) | No | Rarely | Yes, command and register level |
| Agentless on the PLC / HMI | N/A | Usually needs a connector | Yes, nothing on the asset |
| Works with no internet / no cloud | Tunnel needs the link | No, cloud is the broker | Yes, self-contained |
| Audit data location | Not captured | Vendor cloud | Your environment |
| Least privilege per task | No, full network | Yes | Yes, one system, time-boxed |
Secure OT remote access, answered
Secure OT remote access is the practice of letting staff and third-party vendors reach industrial systems (PLCs, HMIs, SCADA) from off-site without extending the network to them. Done properly it means identity for both internal and external users, a full proxy that brokers and records every session in front of the asset, least-privilege access per task, and no dependence on an external cloud. That is different from a VPN tunnel or a cloud-hosted access broker. Trout's Access Gate is built for it.
A VPN builds an encrypted tunnel and then trusts whoever is inside it. On a flat network, a connected user, or anyone who has taken their credentials, can reach far more than the one system they came to service, and the VPN records none of it. In OT that means a single reused vendor credential can reach the PLCs that run the process. A VPN moves the network to the user; secure OT remote access does the opposite, brokering access to one system and recording every session.
Put a proxy in front of the control network. The vendor connects to the proxy, not to the network, authenticates with MFA (anchored at the gateway if they have no account in your directory), and is granted a path to exactly one system for one task. Every command is checked against policy and the whole session is recorded. The vendor never lands on the network and never sees anything else on it.
Yes, and for OT it should. The gateway and its logs run in your own environment, so no session traffic and no audit data route through an external vendor cloud, and there is no third-party data processor in the access path. It also means remote access does not depend on an internet link to a cloud service: local operation and the audit trail survive an outage.
These frameworks require controlling and recording access to critical systems, including third-party and automated access. A proxy that binds every session to a named identity, enforces least privilege, and produces a tamper-evident recording gives you exactly the access-control and traceability evidence an assessor asks for, for both employees and vendors, without changing the underlying equipment.
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.