Security teams should keep a VPN only where it still solves a real access problem, such as reaching on-prem systems, supporting fixed IP allowlists, or meeting specific compliance needs. For SaaS-heavy environments, it should no longer be the default remote access layer. The better test is whether the VPN adds meaningful control without masking unmanaged devices or creating a false sense of trust.
Why This Matters for Security Teams
A corporate VPN is no longer automatically the right control in a cloud-first environment because the access problem has changed. If most work is now SaaS-based, the VPN can become a legacy trust layer that adds reachability without materially improving authorization, device posture, or auditability. The decision should be driven by whether it protects a real dependency, not by habit or architecture nostalgia.
That distinction matters because VPNs often sit in the gap between convenience and control. They can still be valuable for on-prem systems, fixed source IP requirements, or niche compliance constraints, but they can also hide unmanaged devices behind a single network edge. In practice, many security teams keep the VPN long after the business problem it solved has already shifted to cloud services and browser-based access.
A better way to frame the question is whether the VPN reduces risk in a measurable way that other access patterns do not already cover. If it does not, it can become an expensive dependency that complicates troubleshooting, weakens visibility, and encourages broad network trust where narrower application controls would be safer. For cloud-heavy operations, the real question is whether the VPN is still a control or merely a compatibility layer.
In practice, many security teams discover that the VPN is still in place because a few legacy workflows were never reworked, not because it remains the best access model.
How It Works in Practice
The decision starts by mapping actual access paths. If users need to reach private on-prem resources, a VPN may still be the simplest way to provide network connectivity. If the goal is access to SaaS, cloud consoles, or browser-delivered internal apps, the VPN often adds a second trust layer without improving the application’s own authorization model. The right test is whether the VPN is solving transport reachability or compensating for an outdated application design.
Security teams should also separate three questions that often get blurred together: can the user reach the resource, should the user reach the resource, and how is that decision verified. A VPN answers the first question well, but it is weak as a substitute for device trust, session-level authorization, or strong application access policies. That is why many cloud-first environments keep VPN only for specific exceptions, not as the default remote-access path.
NIST SP 800-207 Zero Trust Architecture is useful here because it reinforces the shift from network location to explicit policy enforcement. For teams that still need a VPN, this usually means reducing its scope, segmenting what it can reach, and pairing it with stronger identity, device, and session controls rather than assuming tunnel access is inherently trusted.
- Keep the VPN for private infrastructure that cannot yet be modernized.
- Retire broad VPN use for SaaS and cloud applications that already enforce their own access controls.
- Document every exception that depends on a VPN, especially legacy allowlists and compliance-bound workflows.
- Check whether the VPN is hiding unmanaged endpoints that should instead be denied at the application layer.
These controls tend to break down when the VPN becomes the default fix for legacy access debt, because the organisation stops seeing which systems still depend on network-level trust.
Common Variations and Edge Cases
Tighter VPN use often increases migration effort, because teams must replace network-based access assumptions with application-level controls, segmented connectivity, or explicit exception handling. That trade-off is usually worth it, but the right answer depends on what the VPN is actually protecting and how much legacy dependency remains.
Some environments still need a corporate VPN for fixed-IP allowlists, regulated administrative access, or private service-to-service paths that have not yet moved to modern access brokers. In those cases, the VPN should be treated as a scoped exception, not as a universal trust boundary. By contrast, if the main use case is simply giving employees a familiar path to cloud apps, the control is probably doing more for convenience than for security.
Teams should also be cautious about interpreting “VPN required” as a proxy for stronger security. For unmanaged devices, the tunnel can create an illusion of control while leaving the endpoint itself untrusted. Where current guidance suggests replacing broad network trust with explicit access decisions, the better pattern is to keep the VPN only where it adds a unique control that the target application or platform cannot yet enforce.
In highly distributed environments, the edge case is not whether a VPN exists, but whether it has become the default answer for every access exception.
Risk and Threat Considerations
The main risk is over-trusting network access after the environment has shifted to cloud and SaaS. A VPN can create a broad ingress path that mixes legacy reachability with modern workloads, which increases exposure if the endpoint is compromised, the tunnel is overly permissive, or the same access model is used for both managed and unmanaged devices.
Failure mechanism: The control fails when tunnel access substitutes for explicit application authorization or device assurance. In that case, an attacker who steals credentials, hijacks a session, or lands on an unmanaged endpoint can inherit access to more internal resources than the user actually needs.
Impact: The likely consequence is expanded blast radius, weaker visibility into who accessed what, and delayed detection of misuse. The VPN may also preserve legacy dependencies that slow cloud migration and keep sensitive systems exposed behind a single trust boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PDP/PIP/PEP — Policy Enforcement and Trust Evaluation | VPN replacement decisions hinge on explicit policy enforcement beyond network location. |
| Recommendation — Shift access decisions to explicit policy enforcement instead of trusting tunnel presence. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | The question is about whether remote access still adds meaningful control. |
| Recommendation — Review remote access paths and remove VPN dependence where access control already exists. | ||
| CIS Controls v8 | 6.3 — User Access Rights Review | Keeping a VPN should depend on reviewing whether the access path still serves a real need. |
| Recommendation — Review remote access exceptions and retire VPN paths that no longer support a defined business need. | ||
| ISO/IEC 42001:2023 | 6.1 — AI Risk Assessment | AI tools are not the primary subject and no material AI governance issue is central here. |
| Recommendation — Omit this framework from the practical response because the question is not about AI governance. | ||
Practitioner Guidance
What to prioritise: Start by inventorying every remaining VPN use case and classify each one as on-prem dependency, fixed-IP requirement, compliance exception, or convenience access. Any entry that cannot be tied to a concrete control need should be a retirement candidate.
Decision rule: If the VPN is only being used to reach SaaS or cloud-native applications, move that traffic to direct application access with stronger policy checks. If it still protects a real private-network dependency, shrink it to that scope and treat it as an exception path.
What to verify: Confirm whether the VPN improves any of three things: reachability, authorization quality, or auditability. If it improves only reachability, it is probably not worth keeping as a default user access layer.
Practitioner takeaway: Keep the VPN only when it meaningfully changes the security posture of a real dependency; otherwise, it is usually a legacy transport layer that should be narrowed, not defended as strategy.
Related resources from NHI Mgmt Group
- How should security teams decide whether legacy PAM still fits cloud-native access needs?
- How do security teams decide whether an AI agent should keep access to regulated data?
- How do security teams decide whether to keep Cognito-like tools in scope?
- How should security teams decide whether to replace Supabase Auth or keep it and add authorization separately?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
