Zero trust creates pressure to move away from VPNs because a network tunnel still assumes the network boundary is meaningful. The memo argues that applications should be accessed directly, with security decisions made on identity, device, and request context. That breaks the old model where reaching the network implied broad access to internal resources.
Why zero trust pushes access closer to the application
Zero trust changes the access model from “connect to the network, then assume internal reachability” to “prove the request is acceptable every time, then grant only the specific path needed.” That is why VPN-based access feels misaligned: a tunnel grants broad network presence, while zero trust is designed to make access decisions at the application, not the perimeter.
The practical shift is toward direct application access mediated by identity, device posture, and request context. That reduces implicit trust in the network location of the user and narrows the blast radius if a credential, endpoint, or session is compromised. The underlying architecture is described in NIST SP 800-207 Zero Trust Architecture, which treats network reachability as insufficient evidence of trust.
This is also why VPNs tend to become a transitional control rather than the target state. They still solve encrypted transport and remote connectivity, but they do not, by themselves, answer the zero trust question of whether the requester should be allowed to reach a particular resource at that moment. In contrast, identity-centric access patterns map more naturally to direct, policy-driven access and workload-level trust decisions, as reflected in SPIFFE workload identity specification and the NIST zero trust model.
What breaks in the VPN-first model
A VPN collapses many resources behind one authenticated entry point, which is convenient but coarse. Once connected, the user often inherits a wider internal trust posture than zero trust would tolerate, especially if segmentation, application policy, and session re-evaluation are weak. The risk is not the tunnel itself, but the assumption that tunnel membership should translate into broad internal access.
That assumption becomes dangerous when accounts, tokens, or device trust are compromised. Attackers value VPNs because they can turn one stolen credential into a credible internal foothold, and lateral movement becomes easier when the network edge is doing too much of the work. The contrast is visible in breach reporting such as SonicWall VPN Mass Breach via Stolen Credentials, where access to the tunnel itself was the enabling condition, not the end state.
Zero trust pressure therefore shows up as pressure to separate authentication from blanket reachability. The control objective becomes: establish who or what is requesting access, validate device and context, then permit only the application or action that is explicitly authorised. That is a tighter and more auditable trust boundary than a remote-access network that behaves like an internal network extension.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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-1 — Identity and Credential Management | Zero trust access depends on verified identities, not network location. |
| PR.AC-4 — Access Permissions and Authorizations | Direct application access requires least-privilege authorization at the request level. | |
| PR.AC-5 — Network Integrity | VPNs rely on network trust, while zero trust reduces reliance on network position. | |
| Recommendation — Bind access decisions to verified identity rather than to VPN membership. Enforce least-privilege authorisation for each application or resource request. Reduce implicit trust in network location and segment access by application need. | ||
| NIST Zero Trust (SP 800-207) | SP 800-207 — Zero Trust Architecture | This question is fundamentally about shifting from perimeter trust to continuous verification. |
| Recommendation — Adopt per-request policy enforcement and direct application access instead of broad network trust. | ||
| CIS Controls v8 | 6 — Access Control Management | VPN replacement decisions depend on tighter control of who can reach which resources. |
| 6.3 — User Access Provisioning | Zero trust access models require narrowly provisioned access paths, not blanket internal reach. | |
| 6.8 — Unsuccessful Logon Attempts | Compromised credentials are a major driver for VPN abuse and remote-access compromise. | |
| Recommendation — Restrict remote users to only the systems and services they actually need. Provision only the specific access required for the user’s role and context. Monitor and respond to anomalous authentication attempts on remote access paths. | ||
Practitioner Guidance
What to prioritise: Treat the VPN as a fallback transport mechanism, not as the primary access policy. The first design decision should be which applications can be reached directly with contextual policy enforcement, and which remaining services truly still need network-layer remote access.
What to verify: Check whether your current VPN grants more network reach than the underlying business use case requires. If users can land on an internal segment and then discover apps from there, you have preserved legacy trust assumptions even if MFA is in place.
Common mistake: Replacing the VPN login with stronger authentication but keeping the same broad post-connect access. That improves entry assurance, but it does not convert network trust into least-privilege application access.
Practitioner takeaway: Zero trust does not merely ask for stronger remote access, it asks for narrower and more context-aware access, so the architectural goal is to remove implicit trust from the network hop itself.
Risk and Threat Considerations
VPN-based designs create a concentration risk: one successful compromise can expose multiple internal systems because the tunnel is treated as a signal of legitimacy. That makes credential theft, session hijack, and device compromise more valuable to an attacker than they would be in an application-by-application model.
Failure mechanism: The failure is the trust boundary itself, when network location is allowed to substitute for per-request authorisation. If the VPN client, credential, or endpoint is compromised, the attacker may inherit broad internal reach that exceeds the original access need.
Impact: The result is larger blast radius, easier lateral movement, and weaker containment after initial compromise. Zero trust pressure exists because the older access model makes it too easy for one access path to become many internal paths.
Related resources from NHI Mgmt Group
- How should security teams replace VPN-based privileged access when they move internal applications to Kubernetes and zero trust?
- What is the difference between JIT access and Zero Trust for NHIs?
- Why do browser-based access points create extra risk in Zero Trust environments?
- Why does network-based SSH access create risk in Zero Trust environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
