The short version
OT secure remote access is not a VPN with a nicer login screen. It is a different job: give a named person, staff or third-party vendor, a path to exactly one asset, for one task, with the whole session recorded, and keep the decision and the record on-premise. A flat VPN gives you none of that. It gives you a tunnel and then trusts whoever is inside it.
The reason this matters is who needs the access. The people who reach your OT do not all live in your directory. Your engineers authenticate through your corporate identity provider. The integrator, the OEM, and the maintenance contractor often have no account with you at all, and they are the ones connecting from another continent to a controller you cannot patch.
Where the flat VPN falls down
A traditional VPN terminates on a gateway and drops the user onto a subnet. From there, trust is implicit. Three problems follow, and they are the ones an auditor and an attacker both find first:
- The reachable surface is the whole segment. A vendor who came to service one HMI can reach the PLCs next to it. So can anyone who phished that vendor's credential.
- There is no per-session record. The VPN logs "connected" and "disconnected." What happened in between, which commands, which registers, is invisible.
- Revocation is all-or-nothing. You disable the account globally, or you leave it. There is no per-asset, per-task grant to remove.
On a flat OT network, a single reused vendor credential can reach the controllers that run the process. That is not a hypothetical; it is the shape of most published OT intrusions.
What "done right" actually means
Secure OT remote access replaces the tunnel with a brokered path. Instead of moving the network to the user, you broker the user to one system through a proxy that sits in front of the asset.
- Identity for staff and vendors, on one policy plane. Employees authenticate through your IdP. Outside parties with no account get an identity and MFA anchored at the gateway itself, so internal and external access run through the same brokered, recorded, least-privilege path.
- A full proxy, not a tunnel. The session terminates on both sides. The operator still gets real, interactive access to do the work, but every command is checked against policy and the whole session is recorded as compliance evidence. This is the industrial proxy model: compute on the wire, in front of an asset that can offer nothing of its own.
- 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.
- On-premise, no cloud dependency. The gateway and its logs run in your environment. No session traffic and no audit data route through an external vendor cloud, and local operation and the record survive an internet outage.
Vendor remote access, specifically
Vendor and third-party access is where this earns its place, because the vendor is the user you control least. The move is simple to state: the vendor never touches the network. They connect to the proxy, prove who they are, and are handed a path to one asset for one task, recorded end to end. A leaked static credential is no longer the same as an open door, because the credential alone does not place anyone on the control network.
How it maps to the frameworks you answer to
NIS2, CMMC, and NERC CIP all 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. It is the same industrial DMZ conduit logic, scoped down to a single access path.
Where to start
- Map who reaches OT from off-site today, staff and vendors, and by what path (VPN, jump host, vendor's own tool).
- Confirm no remote path drops a user onto a flat control segment. If one does, that is the first thing to close.
- Put the highest-risk assets behind a brokered, recorded access path so every session is identity-bound, least-privilege, and logged.
- Fold vendor access into the same path, so third parties run through the sanctioned route instead of around it.
The full picture, VPN versus cloud broker versus an on-premise proxy, is in the pillar on secure OT and vendor remote access. The short version is the one at the top: give one person a path to one asset, record it, and keep it on-premise.