What breaks when utilities rely on VPN access for OT operations?

VPN access often turns network connectivity into a stand-in for authorization, which makes lateral movement easier and audit evidence less precise. Once a user is on the network, proving what they were entitled to reach becomes harder. Utilities should prefer explicit, per-resource access decisions over broad network admission.

Why This Matters for Security Teams

Utilities rely on OT uptime, so VPNs are often treated as a practical shortcut for remote operations. The problem is that a VPN proves network membership, not task-level authorization. That gap matters most in environments where engineers, vendors, and service accounts all need different reach, because one broad tunnel can expose far more than the operator intended. OWASP’s Non-Human Identity Top 10 and NIST control guidance both push toward explicit access boundaries rather than implicit trust.

For OT teams, the real risk is that a compromised account, misrouted route table, or over-permissive remote desktop path can turn maintenance access into lateral movement across engineering workstations, historians, and jump hosts. NHIMG’s research on Ultimate Guide to NHIs shows why excessive privilege and poor visibility remain persistent problems, and those conditions become more dangerous when VPN admission is mistaken for authorization. In practice, many security teams discover the control failure only after an incident review shows the tunnel was allowed before the asset was ever meant to be reachable.

How It Works in Practice

A VPN-centered model usually creates a flat trust boundary: once a user or vendor is inside, the network begins doing the work of access control. That works poorly in OT because operators need different permissions for a historian, an engineering workstation, a PLC management interface, and a vendor support portal. The stronger pattern is to combine remote access with explicit, per-resource policy so connectivity does not automatically expand privilege. NIST guidance in SP 800-53 Rev. 5 Security and Privacy Controls supports this separation of access and network reach.

In practice, utilities should think in terms of who, what, and for how long:

• Authenticate the operator or service identity before network entry.
• Authorize each target asset or application separately, not the whole subnet.
• Use just-in-time access windows for maintenance and break-glass events.
• Log the exact resource, command, and time of each privileged action.
• Prefer short-lived credentials and session-based approvals over long-lived VPN trust.

This approach aligns with the visibility and lifecycle concerns NHIMG highlights in the Ultimate Guide to NHIs, especially where credentials outlive the work they were issued for. It also improves auditability because the evidence trail is tied to a specific asset and action, not just a connected session. These controls tend to break down when legacy OT protocols, shared vendor accounts, or unmanaged jump servers force teams back into broad network admission because the environment cannot enforce per-resource policy cleanly.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance maintenance speed against the risk of uncontrolled reach. That tradeoff is especially sharp in outage response, where teams may need rapid access to substations, control rooms, or remote field devices. Current guidance suggests using pre-approved break-glass paths with narrow scope, short TTLs, and strong post-event review rather than leaving a permanent VPN corridor open.

There is also no universal standard for this yet across all OT stacks. Some utilities can enforce session brokering and application-level authorization, while older plants may only support coarse network segmentation. In those cases, security teams should at minimum segment vendor access, isolate admin paths, and eliminate shared credentials so a connected user cannot pivot freely. NHIMG’s 52 NHI Breaches Analysis and the SonicWall VPN Mass Breach via Stolen Credentials case study show how quickly remote access becomes a breach path when identity and network trust are blended. Where OT uptime depends on remote access, the safer question is not whether VPN exists, but whether it still grants more reach than the task requires.

Related resources from NHI Mgmt Group

• What breaks when broad VPN access is used for CMMC readiness?
• What breaks when VPN-based remote access is the default for OT?
• What do teams get wrong when they keep VPN-style access for regulated systems?
• Why do VPN-style access models create risk in healthcare?