What breaks when VPN-based remote access is the default for OT?

Why This Matters for Security Teams

When VPN-based remote access becomes the default for OT, the control plane starts to look safer than it is. A VPN proves a remote endpoint can join the network, but it does not prove the session is limited to a single work order, asset, or maintenance window. That gap matters because OT environments often contain legacy protocols, flat segments, and assets that were never designed for broad trust.

Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs points to the same failure pattern: access that is too durable, too broad, and too hard to revoke quickly. In OT, that translates into larger blast radius, weaker session accountability, and more reliance on perimeter trust than on task-bound authorization.

NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which is a useful proxy for how often machine-to-machine access remains under-governed in practice. In OT, many teams discover the risk only after a vendor account or remote support tunnel has already been reused beyond its intended purpose, rather than through intentional access design.

How It Works in Practice

The operational break is not the tunnel itself, but the assumption that network entry equals appropriate access. A VPN usually authenticates a user or endpoint once, then grants a session that can reach multiple hosts, subnets, and sometimes administrative interfaces. For OT, that model conflicts with least privilege and zero standing privilege because the session is not tied tightly enough to a specific maintenance task.

Better practice is moving toward context-aware access, where the decision is made at request time and constrained by device posture, role, asset criticality, time window, and approved change ticket. NIST zero trust guidance supports that shift by treating each request as something to verify, not something to inherit from network location. In mature environments, access is mediated through jump hosts, per-asset policies, and short-lived credentials rather than a reusable network badge.

• Use task-specific access paths for maintenance instead of broad subnet reach.
• Issue short-lived credentials or session tokens that expire when the job ends.
• Bind remote access to approved assets, work orders, and maintenance windows.
• Log each action at the session and command level so investigations can reconstruct intent.
• Revoke access automatically when a vendor contract, ticket, or incident closes.

That operational model aligns with the Ultimate Guide to NHIs — Key Challenges and Risks, especially where standing credentials and excessive privileges drive exposure. It also fits the direction of OWASP Non-Human Identity Top 10, which treats long-lived access and weak lifecycle control as recurring failure modes. These controls tend to break down when remote support is rushed through legacy VPN concentrators because the access model cannot express per-asset constraints.

Common Variations and Edge Cases

Tighter OT access control often increases operational friction, requiring organisations to balance uptime and vendor convenience against reduced blast radius. That tradeoff is real, especially where plants depend on third-party specialists, 24/7 response, or older controllers that cannot support modern identity tooling.

Best practice is evolving, not settled, for environments that must keep legacy VPNs. In some cases, a VPN may remain as a transport layer, but it should be wrapped with additional controls such as MFA, device trust, per-session approval, and proxy-based access that prevents lateral movement. For high-risk assets, a brokered model is usually safer than direct network reach.

Another edge case is emergency access. Break-glass connectivity should be exceptional, heavily monitored, and time-boxed. It should never become the normal path for routine maintenance, because routine use turns exception into standing privilege. For multi-site OT estates, policy also needs to distinguish between read-only diagnostics, firmware updates, and control actions, since each has a different risk profile.

Where VPN-based remote access fails most visibly is in flat OT networks with shared credentials and unmanaged vendor endpoints, because one broad session can pivot from a support task into plant-wide exposure.

Related resources from NHI Mgmt Group

• What breaks when session monitoring is missing from industrial remote access?
• What is the difference between role-based access and API key governance for NHI security?
• What breaks when remote access still depends on persistent VPN credentials?
• What breaks when vendor remote access in OT is not tightly controlled?