Why do corporate VPNs become less effective as organisations move to SaaS and zero trust?

VPNs were built for a perimeter model where access to the network implied trusted access to resources. As applications moved to SaaS and HTTPS became standard, that assumption weakened. A VPN can still encrypt traffic, but it does not verify device health, app context, or user risk at the resource level, which is why zero trust became the stronger model.

Why This Matters for Security Teams

Corporate VPNs were designed to extend a trusted internal network, not to make fine-grained decisions about every request to SaaS applications. That becomes a problem when the control plane shifts from network location to application access, user risk, device posture, and session context. zero trust aligns better with that shift because it evaluates access at the resource boundary instead of assuming the tunnel itself is enough. NIST SP 800-207 Zero Trust Architecture captures that change in access model clearly.

In practice, the biggest failure is not that VPNs stop working, it is that they continue to work too broadly. Users connect once and then inherit a level of reach that no longer matches how modern apps are delivered or consumed. When that gap is ignored, organisations keep a strong transport control and a weak authorisation model.

Security teams also need to account for the way SaaS access is increasingly mediated by browser sessions, federated identity, and conditional access policies rather than by being inside a corporate network. In that environment, a VPN protects the path, but not the decision about whether a specific device, user, or session should reach a specific application. In practice, many security teams discover that mismatch only after SaaS sprawl and remote access have already outgrown the original VPN design.

How It Works in Practice

A VPN creates an encrypted tunnel back to a trusted network zone. That model assumes the network is the main trust boundary, so once a user is “inside,” access expands across many resources. SaaS breaks that assumption because the application is outside the corporate perimeter, often delivered over standard HTTPS and governed by its own identity and policy stack. The result is that the VPN may still secure transit, but it no longer sits in the right place to make the most important access decisions.

Zero trust shifts those decisions closer to the application. Instead of asking only whether a device can reach the network, it asks whether the request should be allowed right now, for this user, from this device, with this posture, to this resource. That model is more compatible with SaaS because the control point is the application session, not the network edge. NIST SP 800-207 Zero Trust Architecture is the clearest external reference for that design shift.

VPNs are best at protecting transport and enabling legacy network reachability.
Zero trust is best at reducing implicit trust and enforcing per-request policy.
SaaS access usually depends on identity, device trust, and application context, not subnet membership.
Broad tunnel access can create unnecessary lateral movement opportunities if one account is compromised.

This is why many organisations keep VPNs only for a shrinking set of internal or legacy services, while moving SaaS access to identity-aware controls and conditional policy. The practical question is not whether a VPN encrypts traffic, because it does, but whether it still adds meaningful security once the resource itself is outside the perimeter and the real decision is made elsewhere. These controls tend to break down in highly distributed environments when the same tunnel is used for both legacy internal access and modern SaaS access because the trust assumptions are no longer consistent.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance stronger resource-level checks against user experience and administrative complexity. That tradeoff is why some teams keep VPNs for a narrow set of legacy applications while using zero trust patterns for SaaS and remote work.

There is no universal standard for this yet, because migration stages vary widely. A company with many on-premises systems may still need VPN connectivity for specific internal apps, file shares, or admin workflows. But once the primary workload moves to SaaS, the VPN becomes a secondary path rather than the main security boundary. At that point, overreliance on the tunnel can create a false sense of control, especially if access is not continuously re-evaluated.

The edge cases usually show up where integration, admin access, or exceptions are involved. A VPN may still be reasonable for temporary access to a legacy system, but it should not be treated as proof that the user is trusted for every SaaS service. Modern access design needs to distinguish transport security from authorisation, and it needs to do that consistently across managed devices, remote devices, and privileged sessions. Organisations that fail here often keep the VPN for convenience long after it has stopped being the right control for the actual risk.

Risk and Threat Considerations

The main risk is over-broad trust. A VPN can make a remote user look like an internal user, which widens the blast radius if credentials are stolen or a device is compromised. In SaaS-heavy environments, that mismatch is especially dangerous because the real target is usually the application session, not the network tunnel.

Failure mechanism: Attackers often exploit the gap between network access and resource-level authorisation. If they steal credentials, hijack a session, or compromise a device that can join the VPN, they may gain reach far beyond the applications they actually need. The tunnel then becomes a trust amplifier rather than a meaningful security boundary.

Impact: The consequence is excessive access, weaker detection of abnormal use, and a larger lateral movement surface across internal and cloud services. In SaaS environments, that can translate into unauthorized data exposure, account takeover, or hidden persistence through overly permissive access paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, 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 CSF 2.0	PR.AC — Access Control	VPN-to-zero-trust migration is fundamentally an access control shift.
Recommendation — Apply PR.AC to move access decisions from network location to resource-level policy.
NIST Zero Trust (SP 800-207)	AC — Access Control Policy Enforcement	Directly addresses per-request access decisions replacing perimeter trust.
Recommendation — Enforce access at the application boundary using device, user, and context signals.
CIS Controls v8	6 — Access Control Management	Covers limiting access paths and reducing overbroad remote connectivity.
Recommendation — Remove unnecessary VPN reach and restrict remote access to approved resources only.
MITRE ATT&CK	T1133 — External Remote Services	VPNs are a common remote access path that attackers target after credential theft.
Recommendation — Monitor and harden remote service access to reduce abuse of VPN entry points.

Practitioner Guidance

What to prioritise: Treat SaaS access and legacy network access as separate problems. If the main business apps are cloud-delivered, focus on application-level policy, session controls, and device posture rather than trying to stretch the VPN into a universal trust layer.

What to verify: Confirm which resources still truly require network-level connectivity and which only need authenticated, conditional access. If a user can reach most of the environment after one VPN login, the control is probably broader than the current risk model justifies.

Common mistake: Retaining a VPN because it is familiar while leaving SaaS governed by generic allow rules. That creates a split architecture where the transport is hardened but the access decision is still too loose.

Practitioner takeaway: The right question is not whether the VPN is secure in isolation, but whether it still enforces the trust decision at the point where modern applications actually consume risk.