They create risk because they optimise for connectivity, not authorisation. Once a user or vendor is inside the tunnel, legacy OT systems often cannot apply modern, granular access checks on their own. The result is implicit trust across multiple systems, which is especially dangerous when operations depend on availability and a single compromised path can affect critical infrastructure.
Why VPNs and static perimeters fail in OT
VPNs and static perimeters were built to extend network reach, not to make a high-risk operational environment continuously verify who is requesting access, what they may touch, and under what conditions. In OT, that mismatch matters because availability, safety, and deterministic operations are often more important than convenience, and older systems frequently lack modern authorization controls of their own.
The problem is not remote access by itself, it is the trust model. A tunnel that authenticates once and then grants broad network reach can turn a single compromise into broad lateral movement, especially when flat network design and legacy protocols let one foothold influence multiple systems.
What risk the tunnel actually introduces
A VPN often collapses multiple trust boundaries into one entry point. Once inside, a user, contractor, or vendor session may inherit the same reach as an internal workstation, even though the operational task only required a narrow slice of the environment. That creates an exposure gap between initial access and effective authorization.
Static perimeters add a second problem: they assume the network edge is the main place to enforce trust. In OT, the edge may be easier to defend than the interior, but it is still a poor substitute for per-asset and per-action controls. When the perimeter becomes the control, insider mistakes, stolen credentials, and compromised remote tools all gain outsized impact.
That is why modern remote access guidance increasingly pairs strong authentication with NIST SP 800-207 Zero Trust Architecture and OT segmentation principles in NIST SP 800-82 Rev 3: access should be evaluated continuously and constrained to the minimum needed for the specific operational function.
Why OT environments are especially exposed
OT environments often contain assets that cannot easily enforce fine-grained identity checks, session-level policy, or modern device posture validation. Many protocols were designed for reliability and uptime, not for hostile zero-trust conditions. If the network layer says “allowed,” the controller, HMI, or engineering workstation may have no meaningful way to disagree.
That means the security decision shifts upward into the access path itself. If the remote path is too broad, the control plane becomes a de facto master key for the plant. If credentials or session tokens are stolen, attackers do not need to defeat each individual OT asset, they only need to abuse the trust granted by the access bridge.
Practical OT defense therefore depends on treating remote access as a constrained service, not a general-purpose extension of the corporate network. NIST and CISA both emphasize segmentation, monitored remote administration, and minimizing exposed pathways in industrial environments; see CISA Industrial Control Systems for current industrial guidance.
Why the trust model matters more than the transport
A secure tunnel can still be the wrong design if it grants too much standing reach. The key question is not “Is the VPN encrypted?” but “Does every session prove need, limit scope, and stop abuse quickly?” In OT, that usually requires tighter segmentation, shorter-lived access, stronger identity verification, and separate handling for vendors and high-risk maintenance windows.
For practitioners, the most useful mental model is that perimeter tools move packets, but they do not by themselves establish least privilege. If an adversary captures a valid remote path, the blast radius is determined by how much that path can reach, not by how well it was encrypted in transit. That is why tunnel security must be evaluated together with asset segmentation, device trust, and session revocation.
Remote Access Identity Guide is a useful reference point for replacing broad VPN trust with identity-aware access patterns, while SonicWall SSL VPN account compromises 2025 and CitrixBleed 2 2025 show how valid access paths and session material can be abused once trust is concentrated at the perimeter.
Risk and Threat Considerations
VPN and static-perimeter designs create a single, high-value trust path that attackers can target through credential theft, session hijacking, or compromise of the remote access appliance. In OT, that is especially dangerous because one successful entry point can bridge into systems that were never meant to face modern authorization pressure.
Failure mechanism: Access is authenticated at the edge, but not sufficiently re-authorized for each OT asset or action, so the network tunnel becomes a broad implicit-trust channel that enables lateral movement and operational abuse.
Impact: A compromise can spread from remote access into engineering, supervision, or control functions, increasing the chance of process disruption, unsafe changes, extended downtime, or loss of operational visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | OT tunnel risk hinges on restricting flows between trust zones. |
| IA-2 — Identification and Authentication (Organizational Users) | VPN access depends on strong user authentication at the entry point. | |
| IA-9 — Identification and Authentication (Service and External Systems) | Remote tools and third-party connections often act as non-user access paths. | |
| Recommendation — Enforce OT traffic restrictions so remote access cannot freely traverse critical segments. Require strong authentication before granting remote operational access. Authenticate non-human and third-party access paths before they can reach OT assets. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about replacing implicit perimeter trust with continuous verification. |
| Recommendation — Apply zero trust principles to replace broad perimeter trust with per-session and per-resource checks. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | OT risk is reduced by segmenting and hardening remote access paths. |
| Recommendation — Segment OT networks and tightly manage remote access infrastructure. | ||
Practitioner Guidance
What to prioritise: Treat every remote-access path to OT as a privileged pathway, not a convenience feature. Start by mapping which users, vendors, and tools can reach which assets, then remove any path that is broader than the task actually requires.
What to verify: Confirm that access can be revoked quickly, that sessions are tied to a specific operator or vendor use case, and that compromise of one account does not create unrestricted reach across the plant. If the access model cannot answer those questions cleanly, it is too permissive.
Practitioner takeaway: In OT, the right control objective is not “secure the tunnel,” it is “make the tunnel narrow, observable, and revocable enough that it cannot become a hidden trust bridge across critical systems.”
Related resources from NHI Mgmt Group
- Why do VPNs create more risk in OT than in normal enterprise networks?
- Why do shared credentials and static authentication create so much risk in brownfield OT networks?
- Why do shared VPNs and jump boxes increase lateral movement risk in OT networks?
- Why do traditional VPNs and static access paths create more risk in modern infrastructure environments?