Treat VPN as a transport layer, not as a trust decision. Access should still be explicitly authorized based on identity, session context, and resource sensitivity. If the VPN becomes the reason access is allowed, the zero trust model has not actually replaced perimeter trust.
Why VPN and zero trust can both be present without being equivalent
A VPN can still be useful, but only as a protected transport path into a network. Zero trust changes the decision point: every request still needs explicit authorization based on identity, device or session context, and the sensitivity of the target resource. If VPN access is treated as a standing trust grant, the architecture is only perimeter security with a modern wrapper.
That distinction matters because many environments keep VPN for compatibility, while using zero trust policy to decide whether a user, workload, or session may reach an application at all. In practice, the VPN should not be the control that proves trust; it should just reduce exposure on the way to the actual policy decision.
For workload and service access patterns, this is the same architectural shift described in Zero Trust Identity Guide and in Guide to SPIFFE and SPIRE, where identity, attestation, and per-request policy matter more than network placement.
How to avoid letting VPN recreate perimeter trust
The practical rule is simple: a VPN may establish reachability, but it should not establish entitlement. Access should still be mediated by a policy layer that can consider who the caller is, whether the session is healthy, and whether the resource should be reachable from that context. That is especially important for high-value applications, admin paths, and east-west traffic that was previously treated as implicitly trusted once inside the tunnel.
Teams also need to separate authentication from authorization. Logging into the VPN proves one thing, namely that the tunnel can be opened. It does not prove the caller may reach every app, subnet, or internal admin interface. The cleaner model is to authenticate once, then continuously enforce authorization at the application or gateway boundary, with shorter-lived sessions and stronger checks for sensitive resources.
For general identity and access control design, IAM and IGA Basics is the right companion because it frames authorization, entitlement governance, and least privilege as separate decisions from network connectivity. The transport may change, but the access decision should not.
What teams should standardise when both controls must coexist
When VPN and zero trust overlap, the goal is not to remove every VPN overnight. The goal is to make the VPN one of several guarded entry paths, not the trust anchor. Teams should standardise on identity-based access rules, device or session posture checks where available, and resource-level policy that can restrict sensitive systems even when the user is already on the corporate network.
That usually means documenting which applications still require VPN for transport reasons, which ones are directly reachable through zero trust controls, and which ones should be migrated to finer-grained access paths. It also means watching for exceptions where network location quietly becomes a proxy for trust, because those exceptions tend to expand until they become the default security model again.
For remote access design and retirement of legacy VPN assumptions, Remote Access Identity Guide is useful because it treats VPN, MFA, ZTNA, device posture, and dormant access paths as one governance problem rather than separate tools.
Risk and Threat Considerations
VPN overlap becomes risky when teams confuse network location with trust. A stolen VPN credential, an overbroad tunnel policy, or a compromised internal session can turn the VPN into a fast path to lateral movement if downstream systems still assume anything inside the tunnel is safe.
Failure mechanism: The VPN grants broad connectivity, but authorization is not re-evaluated at the resource boundary, so a valid session inherits access that was never meant to be universal. Attackers then abuse that implicit trust to reach sensitive internal services, pivot laterally, or maintain access after initial compromise.
Impact: The organization loses the main benefit of zero trust, which is reduced blast radius. A compromise that should have been contained to a single session can become enterprise-wide exposure, especially where legacy internal apps, admin tools, or service endpoints still accept network presence as proof of legitimacy.
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 SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Access Permissions and Authorization | VPN overlap hinges on explicit authorization beyond network reachability. |
| Recommendation — Enforce resource-level authorization so VPN connectivity never becomes implicit trust. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | The question covers authenticated access paths that still need separate authorization. |
| AC-6 — Least Privilege | Zero trust with VPN overlap depends on limiting what connected users can reach. | |
| Recommendation — Require strong authentication for remote and service access before policy decisions. Restrict tunneled access to the minimum resources each session truly needs. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | VPN is a network transport control that must not replace access decisions. |
| A.5.15 — Access control | The core issue is keeping access decisions separate from connectivity. | |
| Recommendation — Document VPN as a network control and pair it with separate access enforcement. Apply access control rules independently of VPN membership. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The overlap problem is about controlling access after connectivity is established. |
| CIS-5 — Account Management | Remote access still depends on disciplined account and session governance. | |
| Recommendation — Define and enforce access rules that do not rely on network location alone. Limit standing access and remove dormant VPN-linked accounts promptly. | ||
Practitioner Guidance
What to prioritise: Treat the most sensitive applications first. If a system would be catastrophic to expose to every authenticated VPN user, it should be the first candidate for resource-level policy, stronger session checks, or removal from broad tunnel reach.
What to verify: Confirm that VPN success does not automatically map to application access. The test is simple: after the tunnel comes up, can the policy engine still deny specific resources based on identity, context, or sensitivity? If not, the zero trust layer is not doing real work.
Decision rule: If the VPN is only carrying traffic, keep it. If it is deciding who may reach what, move that decision into explicit authorization and treat the VPN as a transport control, not a trust control.
Practitioner takeaway: The overlap is healthy only when the VPN narrows exposure and zero trust makes the actual access decision; once the tunnel becomes the trust signal, you have reintroduced perimeter security under a different name.
Related resources from NHI Mgmt Group
- How should security teams replace VPN trust with zero trust access controls?
- How should security teams replace VPN-based privileged access when they move internal applications to Kubernetes and zero trust?
- How should security teams enforce least privilege for remote workers using VPN and zero-trust access tools?
- How should security teams run access reviews for non-human identities?