What do organisations get wrong about VPN replacement in critical infrastructure?

Why This Matters for Security Teams

VPN replacement becomes a security issue when organisations assume the tool change itself is the control improvement. In critical infrastructure, that mistake can leave operators exposed to the same lateral movement, excessive trust, and credential abuse that made the VPN model risky in the first place. Current guidance suggests the real objective is not remote access modernization for its own sake, but reducing blast radius and making every session measurable against policy.

That matters because critical infrastructure environments often combine legacy protocols, long-lived vendor access, and high operational uptime requirements. A new access gateway, ZTNA layer, or identity-aware proxy does not automatically change segmentation, authorization scope, or device trust. Without those changes, the environment still behaves like a flat network with a fresher front door. NIST control guidance on access enforcement in NIST SP 800-53 Rev 5 Security and Privacy Controls remains relevant because the control intent is about restricting access, not merely tunnelling it differently.

In practice, many security teams discover the weakness only after a maintenance account, third-party connection, or remote engineering workflow is abused, rather than through intentional review of trust boundaries.

How It Works in Practice

Effective VPN replacement starts with a policy redesign, not a product swap. Security teams should identify the resources that actually need remote access, then bind access to identity, device posture, time, session purpose, and explicit resource permissions. That shifts the access model from network reachability to authorization at the application or service level. For critical infrastructure, the practical question is whether a user or service can reach one defined asset for one defined task, not whether they can enter a broad internal address space.

This is also where operational and regulatory pressure intersects. The EU NIS2 Directive pushes organisations toward stronger risk management and access control expectations, while incident patterns tracked in the CISA cyber threat advisories and the ENISA Threat Landscape repeatedly show that stolen credentials, exposed remote services, and weak privilege boundaries remain dependable intrusion paths.

• Map remote access by use case: engineering, vendor support, operations, emergency access, and automation.
• Replace broad subnetwork access with resource-level authorization and just-in-time elevation where possible.
• Log session intent, command scope, and changes to high-risk assets, not just connection success.
• Separate human remote access from machine-to-machine access and treat secrets as governed credentials, not convenience tokens.
• Test whether a compromise of one user or vendor account can still pivot into adjacent control systems.

For AI-enabled operations, emerging guidance from initiatives such as Anthropic Project Glasswing is relevant because agentic tools can widen the blast radius if they inherit overbroad access. These controls tend to break down in hybrid plants with flat legacy segments and always-on vendor tunnels because identity policy cannot compensate for unrestricted network paths.

Common Variations and Edge Cases

Tighter remote access controls often increase operational friction, requiring organisations to balance resilience against maintenance speed and vendor support constraints. That tradeoff is real in critical infrastructure, especially where outages are expensive and change windows are short.

There is no universal standard for this yet in terms of one best replacement architecture. Some environments need ZTNA with strong device attestation, while others need brokered access, jump hosts, or segmented bastion patterns because of legacy OT protocols and equipment that cannot natively support modern identity enforcement. Best practice is evolving toward layered access control, but the mechanism should fit the asset class rather than force every environment into the same remote access pattern.

Edge cases also include emergency access, service accounts, and third-party maintenance. These are often where VPN replacement projects fail because teams modernize employee access but leave privileged vendor paths untouched. In those cases, the right answer is usually narrower policy, stronger session recording, and explicit approval workflows, not broader connectivity with a new brand name. For organisations exploring agent-mediated operations, current security practice suggests treating autonomous access as a separate governance problem, not a simple extension of user VPN replacement.

When the environment includes safety systems, disconnected sites, or legacy assets that cannot support per-session authorization, partial replacement may be the realistic target. In those cases, the goal is to reduce standing access and make exception paths visible, not to claim a full zero trust outcome before the asset base can support it.

Related resources from NHI Mgmt Group

• What do organisations get wrong about infrastructure access audits?
• What do organisations get wrong about segregation of duties in federated environments?
• What do organisations get wrong about automated data classification?
• What do organisations get wrong about transaction control assurance?