Vendor remote access to OT. Without the VPN.
An OEM needs in on Tuesday. Your engineer needs in from home. Both get a named login, a path to one machine for one job, and a recording of what was done. No tunnel onto the control network, no cloud in the path, nothing installed on the equipment.
Last updated:
Vendor remote access to OT means letting an outside party (an OEM, an integrator, a maintenance contractor) or your own staff reach a controller, HMI or SCADA server from off-site. Done properly it means four things: a named identity for every user, internal or external, a proxy in front of the asset that brokers and records the whole session, one asset for one task rather than a subnet, 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.
The vendor never touches the network.
The vendor is the user you control least: no account with you, connecting from another continent to a controller you cannot patch. So the rule is simple. They do not get a tunnel. They connect to the gate, prove who they are (MFA anchored at the gate, since they have no account in your directory), and are handed a path to one machine for one task, recorded from the first packet to the last.
A leaked vendor password is then no longer an open door: on its own it places nobody on the control network. Revoking access is one grant, not a global account. And the OEM's engineer still gets real, interactive access to do the job, not a locked-down keyhole.
Four steps, in this order.
- 01
Map who reaches OT from off-site today
Staff and vendors, and by which path: VPN, jump host, the vendor's own tool, a cellular modem on the panel. Most sites find a path nobody owns.
- 02
Close any path that lands on a flat segment
If a remote user can reach the PLCs next to the one they came for, that is the first thing to fix, before any tooling decision.
- 03
Put the highest-risk assets behind the gate
The controllers you cannot patch, the SCADA server, the safety system. Every session to them is now named, scoped to one asset, and recorded.
- 04
Fold vendor access into the same path
Third parties run through the sanctioned route because it is the easiest one: a link, a login, a session. They stop running around it.
What NIS2 requires of third-party access
NIS2 names supply-chain security as one of the ten mandatory risk-management measures. Article 21(2)(d) covers security in the relationships between an entity and its direct suppliers and service providers, and for an OT operator that lands squarely on the integrators, machine builders and support engineers who connect in to work on equipment. The obligation is not to trust them less. It is to be able to show what each of them can reach, and what they did.
Standing access does not survive the question
A permanent VPN account for a supplier cannot answer which assets it reaches or what it did last quarter. Access granted per intervention, scoped to named assets and protocols and expiring on its own, answers both by construction.
The supplier is identified, not the company
A shared vendor login makes attribution impossible after an incident, which is the moment the question gets asked. One identity per engineer, authenticated at the gateway rather than on the asset, keeps the record answerable.
Evidence is a by-product, not a project
Session records, the permission matrix per enclave, and a tamper-evident change history are produced by running the control. Article 21(2)(f) asks for policies to assess whether the measures work; that is the same data.
It applies to equipment that cannot be changed
The obligation covers the asset regardless of whether the asset can host an agent or support MFA. Enforcement in front of the device is what makes a 2009 controller reachable under a policy it can never implement itself.
None of this requires the supplier relationship to change. It requires the access path to be one you own, so the answer to a supervisory question is an export rather than an investigation.
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
Put a gate in front of the PLC and give the vendor a login to the gate, not to the network. The vendor authenticates with MFA at the gate, is granted a session to that one controller for a defined window, and everything they do is recorded. No VPN client, no tunnel onto the control subnet, nothing installed on the PLC. When the job is done the grant expires; the vendor's credential alone never reaches the network again.
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.
The gate is the first service you run, not the last.
Secure OT, zero disruption, and a base to build on.
Access Gate puts compute on the wire, next to your assets. Once the gate is in, the same box hosts the services that pull OT in securely: remote access, protocol gateways, DNS and time, historian, update server. No second appliance, no cloud.