Legacy VPN extends network trust after connection, which can expose the internal environment to lateral movement if an endpoint is compromised. It also forces cloud and SaaS traffic through central gateways, adding congestion and latency. Zero trust reduces those risks by verifying each request independently and limiting trust to the specific application being accessed.
Why legacy VPN expands trust in cloud and SaaS access
Legacy VPN is a network tunnel first, not an application boundary. Once a user or device is admitted, the remote session often inherits broad network reach that is far larger than the specific cloud console or SaaS app the person actually needs. In practice, that means the control is strongest at the edge and weakest inside the environment it is trying to protect.
A more precise model is to grant access at the application or resource level rather than treating the whole internal network as trusted. That is why cloud and SaaS environments fit the zero trust approach better: the access decision can follow the request, the context, and the target instead of relying on a one-time perimeter check. NIST SP 800-207 Zero Trust Architecture provides the clearest external framing for that shift, and NHIMG’s Ultimate Guide to NHIs — Standards ties the same principle to modern identity and workload controls.
Remote access becomes less risky when the control plane is aligned to the way cloud services actually work. A VPN can still be useful for some legacy internal systems, but for SaaS, cloud admin, and browser-based access, it adds a broad network trust layer that is often unnecessary. That design mismatch is the core problem, not simply the technology itself.
Where the risk comes from in practice
The main failure mode is blast radius. If an endpoint, token, or session is compromised after VPN login, the attacker may be able to move laterally, discover internal services, and reuse the trusted tunnel to reach assets that were never meant to be available from the remote device. In cloud and SaaS-heavy estates, this is especially problematic because the real target is usually an app, API, or admin plane, not the network segment behind the VPN.
VPN concentration also creates an availability and performance problem. Cloud and SaaS traffic being forced through a central gateway can introduce latency, congestion, and troubleshooting complexity, especially when remote users are spread across regions. That makes the access path both easier to overload and harder to reason about during incidents.
For identity-heavy remote access, the better comparison is not “VPN versus security” but “broad network trust versus bounded request trust.” Zero trust reduces the value of any single compromised path because each request is evaluated independently, and access can be narrowed to the specific application, action, or resource. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because excessive privilege and visibility gaps are the same structural problems that make remote access too permissive.
How to judge the better model for your environment
Use VPN only where you truly need network-level reach for legacy systems that cannot be addressed cleanly any other way. For cloud and SaaS, the safer default is to authenticate to the application, authorize the action, and avoid exposing broader internal reach than the user needs. If the access decision does not need network adjacency, the VPN is usually adding risk rather than reducing it.
Two practical checks help determine whether your current design is too permissive:
- Can a compromised remote endpoint reach more than one business application after login?
- Does the access path rely on central network trust instead of per-request verification and least privilege?
When the answer to either is yes, the architecture is probably carrying legacy assumptions into a cloud and SaaS world. NHIMG’s The 2026 Infrastructure Identity Survey reinforces the access-control side of that decision by showing how strongly least privilege and identity governance affect incident rates in modern infrastructure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | Remote access must be authenticated and scoped to reduce excess trust in cloud and SaaS. |
| PR.AC-4 — Access Permissions and Authorizations | The question centers on over-broad access after connection and least privilege boundaries. | |
| DE.CM-8 — Vulnerability Scans and Logging for Access Paths | A compromised remote session can enable lateral movement, so monitoring access paths matters. | |
| Recommendation — Enforce per-request access controls and limit remote reach to approved resources. Restrict remote users to the specific applications and actions they are authorized to use. Monitor remote access activity for abnormal reach, reuse, and lateral movement. | ||
| CIS Controls v8 | 6 — Access Control Management | Legacy VPN risk is fundamentally an access-scope problem across cloud and SaaS resources. |
| 8 — Audit Log Management | Central gateways and application-level access both require visibility into remote access use. | |
| Recommendation — Apply least privilege to remote access paths and remove unnecessary network-wide access. Log remote access decisions and privileged cloud or SaaS actions for investigation. | ||
| NIST Zero Trust (SP 800-207) | SP 800-207 — Zero Trust Architecture | The question directly compares broad network trust with per-request verification. |
| Recommendation — Shift remote access decisions from network trust to application-scoped verification. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Leakage and Credential Exposure | Remote access risk often increases when VPN sessions or cloud access rely on exposed secrets. |
| Recommendation — Remove exposed credentials and reduce the chance that a remote session becomes a broad compromise. | ||
Practitioner Guidance
What to prioritise: Start with the access paths that combine broad network reach and high-value cloud or SaaS privileges. Those are the places where a single compromised session can create the largest blast radius.
Decision rule: If the user only needs one application, one admin function, or one SaaS workflow, prefer direct application access with strong conditional controls over a full network tunnel. Reserve VPN-style connectivity for legacy dependencies that genuinely require it.
What to verify: Confirm that your remote access design prevents a logged-in device from automatically inheriting unrelated internal reach. Also verify that cloud and SaaS admin paths are not quietly relying on the VPN as a hidden trust shortcut.
What good looks like: Access is granted per application, session scope is narrow, and a compromise in one remote session does not automatically expose the broader internal environment. The access path is explicit, observable, and easy to revoke without disrupting unrelated users.
Practitioner takeaway: The key question is not whether remote access is encrypted, it is whether the design still assumes the remote user or device should be trusted after login. In cloud and SaaS environments, that assumption is usually the risk.
Related resources from NHI Mgmt Group
- Why does Zero Trust reduce insider risk in environments with remote work and cloud access?
- Why do legacy applications increase identity and access risk in cloud and zero trust environments?
- Why do legacy VPN and manual access processes create more operational risk in Zero Trust programmes?
- Why do hybrid identity environments often create more access risk when organisations split credential management between legacy and cloud systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
