Should organisations keep VPNs or move to identity-based OT access?

Why VPNs Hold Up Less Well in OT Than Identity-Based Access

VPNs solve transport encryption and remote reach, but in OT that is often the wrong control objective. If a remote user lands inside a flat or lightly segmented environment, the VPN can become a broad trust tunnel rather than a narrow access decision. Identity-based access is better when the real requirement is to constrain who can reach which controller, engineer workstation, or vendor support path.

That distinction matters because industrial environments are usually defined by containment, fixed trust zones, and tightly scoped operator actions. A remote access mechanism should therefore reduce the blast radius of a valid login, not merely make the login private in transit. For OT teams, the control question is less “is the tunnel encrypted?” and more “what industrial resources become reachable once the tunnel is up?”

What Identity-Based OT Access Changes Operationally

Identity-based OT access shifts enforcement from network location to authenticated user, device, and session context. Instead of treating the VPN as a blanket gateway, organisations can make access contingent on role, device posture, time, approval, and the exact asset being reached. That is a stronger fit for environments where vendor access, maintenance windows, and break-glass support all need different treatment.

This also improves governance. It becomes possible to answer who accessed which OT asset, under what approval, and for how long, rather than only seeing that a remote connection entered the network. In practice, that makes recertification, exception handling, and incident review much more defensible.

When a Hybrid Model Still Makes Sense

VPNs are not automatically obsolete. They can still be useful as one transport layer, especially where legacy protocols, brittle tooling, or site constraints make full replacement unrealistic. The mistake is to keep the VPN as the primary security boundary when it is really just a conduit.

A sensible hybrid pattern is to keep the encrypted transport only where needed, then layer identity-driven authorization, segmentation, and session controls on top. The OT and ICS Identity and Access Guide is useful here because it ties access design to shared accounts, vendor remote access, and segmentation rather than to network reach alone. The same logic is reflected in Remote Access Identity Guide, which treats VPNs as one control point inside a broader identity model.

For OT environments that still rely on established remote access infrastructure, the practical issue is not whether to remove VPNs everywhere tomorrow. It is whether every remote path is bounded by the same access policy and whether any one login can move laterally beyond the intended asset set. That is where Zero Trust Identity Guide becomes relevant as a design reference.

Risk and Threat Considerations

The main risk with VPN-centric OT access is overreach. Once an attacker or contractor account is valid, the tunnel can expose more of the plant network than the user actually needs, especially where segmentation is weak or legacy remote-access exceptions have accumulated over time. Identity-based controls reduce that exposure by narrowing the session to the specific resource, not the whole network segment.

Failure mechanism: A stolen credential, abused vendor account, or hijacked session can be used to pivot through the VPN into adjacent OT systems when network reach is broader than the job function requires.

Impact: The likely result is expanded lateral movement, harder containment, weaker accountability, and a much larger operational blast radius if the remote session is compromised.

Practitioner Guidance

What to verify: Check whether remote OT users can reach only the target asset, or whether the VPN puts them inside a routable network zone with unnecessary lateral access. If the answer is the latter, treat the VPN as a transport dependency, not a control boundary.

Decision rule: If remote access is used for vendors, maintenance, or emergency support, require per-asset authorization and session logging before you accept any broad network-level entry path. If you cannot constrain the session to the intended industrial resource, reduce privilege before you redesign connectivity.

What good looks like: Remote access requests are tied to named identities, approved scopes, short-lived sessions, and observable actions on specific OT assets. The organisation can prove who connected, why they connected, and what they were allowed to reach.

Practitioner takeaway: Keep VPNs only as a transport mechanism where needed, but move the security decision to identity, scope, and segmentation, because that is what limits OT blast radius in practice.

Related resources from NHI Mgmt Group

• Should organisations replace VPNs and bastions with identity-based access controls?
• Should organisations keep ADFS or move to cloud identity for external access?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between OT network segmentation and identity-based access control?