Vendor and third-party remote access for OT, one machine at a time.
Keep the VPN or 4G link your vendors already use. Access Gate adds authentication, access to one asset, automatic session end and a log of every session.
Last updated:
To give a vendor secure remote access to one machine, keep the VPN or 4G link they already use and end it at a gate in front of that machine. The vendor signs in at the gate with their own identity and MFA, from a directory kept apart from yours, and reaches only that machine, over the protocol the job needs, for a set time. The whole session is recorded.
Vendor remote access and other third-party remote access cover every connection into your OT by someone you do not employ: equipment vendors, machine builders, integrators and maintenance contractors. Most sites open a VPN tunnel or install a 4G router at the machine for them. On its own, that is a risk: a connected user can reach the whole network, nobody controls what they do, and nothing is logged.
Trout Access Gate keeps the VPN or 4G link and adds control:
- Micro-segmentation of the LAN, so each asset can only be reached through the gate
- A bastion where every user authenticates, with staff and vendors in separate directories
- One asset per session, closed after a set time and logged on your site
For the product itself, pricing and deployment, see secure remote access for OT with Access Gate.
Is a VPN enough for vendor remote access?
No. A VPN encrypts the link and checks who opens it. It does not decide which machine the user reaches once inside. It does not record what they do. CISA and NIST both ask for more than the tunnel.
NIST SP 800-82 Rev. 3, section 6.2.10, says remote access should be limited to what the business need requires. It asks you to remove access when it is no longer needed, for example with automatic timers, and to monitor remote activities. It also says MFA should be considered for remote access to OT.
CISA's recommended practice on remote access for industrial control systems strongly recommends eliminating direct connections to control systems. It also recommends a separate authentication server for vendors and integrators, so their access can be locked down and granted back case by case. CISA's 2026 advisory on attacks against PLCs adds that a gateway or VPN in front of the PLC can enforce MFA even if the PLC does not support it.
What each common approach controls, and what it leaves on record:
| Approach | What it controls | What it records |
|---|---|---|
| VPN alone | Who opens the tunnel. Inside, the user can reach the whole network. | Connection logs at best. Not what the user did. |
| 4G router in the cabinet | Only who knows the router password. | Nothing on your side. |
| Jump server | Who logs in to the jump host. From there, any machine it can reach. | Logins to the jump host. Sessions only if you add recording. |
| Cloud access broker | Who reaches which system, through the broker's cloud. | Sessions, often in part, stored in the broker's cloud. |
| VPN + Trout Access Gate | Who reaches which machine, for how long, and which commands are allowed. | Every session end to end, tamper-evident, on your site. |
Keep staff and vendors in separate directories.
Many of the people who need remote access are not in your directory. Integrators, machine builders and maintenance contractors usually have no account with you, and you may not want to give them one in your corporate directory. Access Gate connects several directories at once. Your staff sign in with your corporate directory, for example Active Directory or Microsoft Entra ID. Vendors sign in with a separate directory: a second Active Directory you keep for third parties, or the directory built into Access Gate. MFA is enforced at the gate for both groups. Both groups then follow the same rules: one asset per task, a time limit and a recorded session. Adding or removing a vendor never touches your corporate directory.
Users work normally, and every session is recorded.
A VPN or 4G link creates a tunnel and then trusts whoever uses it. Access Gate sits at the end of that tunnel, in front of the asset. The session terminates on the gate, and the gate opens a separate connection to the asset. The user keeps full interactive access and can do the job. At the same time, every command is checked against your policy and the whole session is recorded. The recording is the evidence you give an auditor.
The gate understands OT protocols. It can allow a vendor to read a sensor but not command the associated controller. This rule is enforced by the gate, not by the vendor's laptop, so it holds even if the laptop is compromised.
The gate and its logs stay on site.
The gate and its logs run in your own environment. No session traffic and no audit data go through an external vendor cloud, and no third party processes your access data. Remote access also does not depend on a cloud service being online. Local operation and the logs keep working during an internet outage. A cloud-hosted access broker cannot offer this.
How do you give a vendor access to one PLC?
A vendor is the user you control least. They have no account with you, they may connect from another country, and the controller they need often cannot be patched. Their VPN or 4G connection ends at the gate, not on the plant LAN. They authenticate at the gate with MFA, using the vendor directory. They then get access to one machine for one task. The session closes when the time is up, and it is recorded from start to finish.
If a vendor password leaks, on its own it reaches nothing behind the gate. Revoking access is one grant, not a global account. The vendor's engineer still gets full interactive access to do the work.
How to give remote access to a PLC.
Most remote access requests in OT end at a controller. An integrator needs to change logic, a machine builder needs to read a fault, an engineer needs to check a value. The PLC cannot protect itself: it cannot ask for a second factor, and a legacy controller cannot authenticate a user or record a session. Access control for a PLC has to sit in front of it.
The gate does what the controller cannot. It authenticates the person, opens a session to that one PLC over the protocol the job needs, and records it. Because the gate understands the protocol, reading a value and writing one can be separate permissions, so a vendor who only needs to diagnose cannot change anything. Nothing is installed on the PLC and its configuration does not change.
By asset
- Remote access to a PLC: four common setups compared, and how to control each session.
- SCADA remote access: monitoring, control, and who gets which.
- HMI remote access: view-only, control, and who needs which.
Four steps from visibility to control.
- 01
See who connects to OT from outside
List your staff and vendors, and how each of them connects: VPN, jump host, the vendor's own tool, a 4G modem in the cabinet. Most sites find a connection nobody owns.
- 02
Limit each remote user to the asset they need
Today a VPN or 4G user can usually reach every PLC on the network, not only the one they came for. Micro-segment the network so each asset can only be reached through the gate.
- 03
Put the highest-risk assets behind the gate first
Start with the controllers you cannot patch, the SCADA server and the safety system. Every session to them is then named, limited to one asset, and recorded.
- 04
Move all vendor access onto the gate
Vendors use the gate because it is the easiest way in: a link, a login, a session. Every vendor session is then logged, and you can show who did what.
Six requirements for a vendor remote access tool.
Use this list to compare products, including ours. A VPN or 4G router alone gives you none of them. A cloud broker gives you some of them, but through its own cloud.
Separate directories for staff and vendors
Staff authenticate against your corporate directory, for example Active Directory or Entra ID. Vendors authenticate against a separate one: a second Active Directory or the directory built into the gate, with MFA at the gate. The same policy applies to both.
Protocol-aware, not port-based
The gate reads OT protocols such as Modbus and DNP3 and enforces rules per command and per register, not only per 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 in their configuration. Legacy controllers that cannot authenticate users or record sessions get both from the gate.
Least privilege, per session
Access is granted to one system, for one task, for a limited time, then removed. No connection to the control network stays open between jobs.
Built for uptime
The gate sits in the remote access path, not the live control loop. It has failover and an emergency access path. If the gate is offline, on-site operation continues, and it adds no delay to the running process.
Tamper-evident audit
Every session is recorded end to end: who connected, which commands they sent, how long they stayed and what changed. Users cannot alter the records, and you can send them to a SIEM or use them in an investigation.
How VPN, cloud broker and Access Gate compare.
| Capability | VPN or 4G alone | Cloud access broker | VPN + Trout Access Gate |
|---|---|---|---|
| Identity for outside vendors | Often a shared account | Yes, in the broker's cloud | Yes, in a separate vendor directory, on-premise |
| Session recording for audit | No | Partial, in the cloud | Full, tamper-evident, on-premise |
| Protocol-aware (Modbus, DNP3) | No | Rarely | Yes, per command and register |
| Agentless on the PLC / HMI | N/A | Usually needs a connector | Yes, nothing on the asset |
| Depends on a vendor cloud | No | Yes, the cloud is the broker | No, runs on your site |
| Audit data location | Not recorded | Vendor cloud | Your environment |
| Least privilege per task | No, access to the whole network | Yes | Yes, one system, time-limited |
Common questions about vendor and third-party remote access.
NIST SP 800-82 Rev. 3 (section 6.2.10) says remote access should be limited to the business need, removed when no longer required, monitored, and protected with MFA where possible. CISA recommends eliminating direct connections to control systems and giving vendors and integrators a separate authentication server. In 2026, CISA also advised putting a gateway, firewall or VPN in front of the PLC, which can enforce MFA the PLC cannot. A gate in front of each machine does each of these without changing the equipment.
Keep the VPN or 4G link the vendor already uses, and put a gate in front of the PLC. The link then ends at the gate instead of on the plant network. The vendor authenticates with MFA at the gate and gets a session to that one controller for a set time. Everything they do is recorded, and nothing is installed on the PLC. When the time is up, the session closes. The vendor's password alone can no longer reach the network.
Vendor remote access is how an equipment vendor, machine builder or integrator connects to your industrial systems (PLCs, HMIs, SCADA) from outside the site to service them. When it is done securely, the VPN or 4G link only provides the connection. Every vendor engineer has a named identity. A gate in front of the asset controls and records each session. Access is limited to one asset per task and ends automatically. Nothing depends on an external cloud.
A VPN creates an encrypted tunnel and then trusts whoever is inside it. On a flat network, a connected user, or anyone who has stolen their password, can reach much more than the one system they came to service. The VPN records none of this. In OT, one reused vendor password can reach the PLCs that run the process. Keep the VPN for the connection, and add a gate that authenticates the user, gives access to one system, ends the session on time and records it.
Third-party remote access is any connection into your environment by someone who is not your employee: an equipment vendor, a machine builder, a system integrator or a maintenance contractor. In OT it carries the most risk. The user's account is managed by another company, you do not manage their laptop, and the asset they reach usually cannot be patched. To secure it, give them an identity outside your corporate directory, such as a second Active Directory or the directory built into the gateway. Require MFA at the gate. Limit each session to one system for one task, record it, and let it expire when the job is done.
Yes, and for OT it should. The gate and its logs run in your own environment. No session traffic and no audit data go through an external vendor cloud, and no third party processes the data. Remote access also does not depend on a cloud service being online, so local operation and the logs keep working during an internet outage.
These frameworks require you to control and record access to critical systems, including access by third parties and automated systems. A gate that ties every session to a named person, gives the minimum access needed and records each session in a tamper-evident way produces the evidence an assessor asks for. It covers employees and vendors, and the equipment does not change.
More pages about OT remote access
The gate is the first service you run, not the last.
Secure your plants today. Control your digitalization tomorrow.
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. Accelerate your digitalization, in control.