How do organisations decide when to retire a VPN in a cloud workflow?

Why This Matters for Security Teams

Retiring a VPN in a cloud workflow is not a simple infrastructure swap. The VPN often provides more than transport security: it can also support segmentation, access scoping, audit context, and a rough trust boundary for administrators and contractors. When that layer disappears, the organisation must prove that equivalent visibility and policy enforcement still exist somewhere else. NIST Cybersecurity Framework 2.0 is useful here because it forces the question into governance, protection, detection, and recovery outcomes rather than tool preference.

Security teams sometimes over-focus on user experience or cost reduction and under-specify what the VPN was actually compensating for. In cloud-first environments, that hidden dependency may include source IP restrictions, session attribution, or a control point for conditional access. If those functions are not replaced, the organisation may create a policy gap even if connectivity looks cleaner. Current guidance suggests the right retirement decision is based on control equivalence, not on whether access still works.

In practice, many security teams encounter the missing control only after an audit finding, a privileged access incident, or a cloud misconfiguration has already exposed the gap.

How It Works in Practice

The decision process usually starts by mapping the VPN’s real functions. For each user group, service account, and admin path, identify whether the VPN is providing network reachability, identity assurance, device posture enforcement, logging, geo-filtering, or a compensating control for legacy applications. If a function is still required, the replacement must own it explicitly. That may mean conditional access, identity-aware proxying, session recording, cloud-native logging, or application-layer authorization rather than a direct network tunnel.

A practical retirement review should also test where policy decisions are made. A VPN that only forwards traffic is not enough if the cloud workflow depends on browser controls, API authorization, or identity correlation across SaaS, IaaS, and internal apps. The control owner should be able to show which system now answers questions such as who accessed what, from where, under which device state, and with what approval path.

• Map each VPN use case to a specific security outcome, not a technology label.
• Verify that the replacement control can enforce least privilege and log decisions centrally.
• Check whether privileged workflows still need stronger segmentation than general user access.
• Test exception handling for third parties, emergency access, and legacy systems before retirement.

For cloud and remote access patterns, the CISA Zero Trust Maturity Model is a useful benchmark because it emphasises identity, device, application, and data controls rather than reliance on a perimeter tunnel. Teams should also look at OWASP Application Security Verification Standard when access is shifting toward application-layer enforcement and session controls.

These controls tend to break down when legacy network appliances are still the only place where exceptions, logging, and privileged routing are visible because the replacement stack has not absorbed those functions.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance reduced network exposure against support complexity and migration risk. That tradeoff is most visible when the VPN still supports a small number of high-risk or hard-to-modernise workflows.

Best practice is evolving for hybrid estates. In some environments, the VPN may remain for specific administrator paths while ordinary workforce access moves to identity-aware access or application-specific gateways. That is not a failure to modernise; it is a deliberate staging model. The key is to document which use cases are exempt, why they are exempt, and what exit criteria exist for the remaining tunnel dependency.

There is no universal standard for this yet, but organisations generally should be cautious where workflows involve regulated data, unmanaged endpoints, or partners outside the core identity system. In those cases, the VPN may still be covering for immature browser controls, weak device trust, or incomplete audit trails. If the organisation is subject to resilience expectations, NIS2 guidance and zero trust transition guidance from CISA can help frame whether the new access design is resilient enough to support retirement.

For cloud workflows, the safest rule is simple: retire the VPN only after the replacement stack can prove equivalent visibility, enforceable policy, and auditable exceptions for every access path that matters.

Related resources from NHI Mgmt Group

• Should organisations let an LLM decide when an agent workflow is complete?
• How do organisations decide whether an AI workflow needs stricter controls?
• How should organisations decide whether their multi-cloud identity model is working?
• How can organisations decide whether their AI security workflow is mature enough?