Why do VPNs create more risk in OT than in normal enterprise networks?

Why This Matters for Security Teams

VPN risk is amplified in OT because the access model is usually designed for connectivity, not containment. Once a user authenticates, the session often resembles an internal presence rather than a narrowly scoped task. In enterprise IT, that may be tolerable when endpoint controls, EDR, and segmentation are strong. In OT, the same assumption can expose engineering workstations, historians, remote maintenance paths, and controller-adjacent systems.

This is why guidance from the NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture matters here: trust should be explicit, contextual, and continuously re-evaluated, not granted once at tunnel establishment. NHIMG has shown how broadly exposed identities and weak rotation practices create durable attack paths in connected environments, with the Ultimate Guide to NHIs — Key Challenges and Risks noting that 97% of NHIs carry excessive privileges. In OT, that same privilege sprawl becomes operationally dangerous because lateral movement can affect availability, safety, and physical process integrity.

In practice, many security teams encounter the danger only after a vendor account or maintenance credential has already been used to reach systems that were never meant to be broadly reachable.

How It Works in Practice

OT networks are often flatter than enterprise networks, so a VPN can behave like a master key rather than a controlled corridor. The main issue is not the tunnel itself, but the trust it tends to confer once the user or device is inside. That trust can bypass the intent of zone-based design, especially where segmentation is light, legacy protocols are in use, or vendor access is granted for troubleshooting and commissioning.

Security teams should think in terms of constrained access paths, not blanket internal access. A safer pattern is to pair remote access with strong identity proofing, device posture checks where feasible, and narrowly scoped authorization tied to a specific task, asset, and time window. The operational goal is to prevent a valid credential from becoming persistent lateral movement. NHIMG case research such as the Schneider Electric credentials breach and the SonicWall VPN Mass Breach via Stolen Credentials show how credential compromise can scale quickly when remote access is too permissive.

• Limit VPN access to a jump host or brokered session rather than direct OT subnet access.
• Apply asset-specific allowlists and maintenance windows, not broad internal reachability.
• Use MFA, but do not treat MFA alone as sufficient containment.
• Log session start, command paths, and target assets for after-action review.
• Separate vendor access from operator access so one compromise does not collapse both trust zones.

Current guidance suggests aligning remote access with zero trust principles, but there is no universal standard for OT VPN containment yet. These controls tend to break down when legacy PLC environments require direct vendor connectivity because protocol dependencies and downtime constraints limit enforcement.

Common Variations and Edge Cases

Tighter remote-access control often increases operational overhead, requiring organisations to balance availability against containment. That tradeoff is real in OT, where maintenance windows are short and some assets cannot tolerate aggressive endpoint controls or frequent reauthentication.

One common edge case is vendor support. Some environments still rely on shared VPN profiles or long-lived access for third-party technicians, which weakens accountability and makes incident scoping harder. Another is segmented enterprise-to-OT convergence, where corporate IAM practices are imported into plants without accounting for process-critical dependencies. Best practice is evolving here: current guidance suggests task-based access, temporary approvals, and brokered connections, but implementation differs by site maturity.

The more the environment depends on always-on remote administration, the more important it becomes to reduce standing trust and verify each session independently. The Top 10 NHI Issues underscores how excessive privilege and weak lifecycle control turn access paths into long-lived liabilities, which is especially dangerous when a VPN account can touch both IT and OT assets. Where safety systems, historians, and vendor appliances share the same trust plane, VPNs become a high-consequence bridge rather than a convenience layer.

Related resources from NHI Mgmt Group

• Why do perimeter VPNs increase lateral movement risk in enterprise networks?
• Why do shared VPNs and jump boxes increase lateral movement risk in OT networks?
• Why do AI systems create new risk in certificate management?
• How should security teams authenticate AI agents in enterprise environments?