How should security teams govern VPN use in a zero trust architecture?

VPNs in Zero Trust: what changes in the governance model

In a zero trust architecture, the VPN should be treated as one access path, not as the trust decision itself. Governance has to separate connectivity from authorization, so the tunnel only establishes reachability while the application still enforces identity, device, and policy checks. That distinction is central to NIST SP 800-207 Zero Trust Architecture.

This also means the security team should decide which users, devices, workloads, and third parties still need VPN access at all, versus which access paths should move to stronger, more granular controls. A practical governance model allows the VPN to exist for legacy or special cases, but refuses to treat network presence as evidence of trust.

How to govern VPN access without recreating perimeter trust

Use the VPN as transport, then apply policy at the application or resource boundary. The key governance question is whether the VPN is still solving a real network transport need, or whether it has become a broad entitlement that bypasses finer-grained controls.

Good governance usually covers three decisions: who may use the VPN, what they can reach after connecting, and when the exception should expire. The strongest control pattern is identity-centric access, backed by device posture and policy enforcement, rather than flat remote network access. For a broader identity roadmap, Zero Trust Identity Guide is the best internal reference point.

Where remote access remains necessary, teams should define whether the VPN is an exception path, a fallback for unmanaged environments, or the approved method for a limited application set. That decision matters because each use case implies a different tolerance for standing access, logging depth, and segmentation.

Operational controls that make VPNs compatible with zero trust

The most useful control set is not “remove the VPN” but “remove implicit trust.” That means strong authentication, device posture checks, and per-application policy should be enforced on every connection. If the access decision is still coarse, the VPN is only hiding a perimeter model behind modern language.

• Require strong identity assurance for VPN entry, then re-evaluate authorization before application access.
• Segment access so a connected user can reach only the resources needed for that role or task.
• Retire dormant or broad VPN accounts and review whether long-lived remote access is still justified.
• Log VPN entry, denied requests, and downstream application decisions as separate events.

For teams managing remote access estates, Remote Access Identity Guide is a useful companion because it ties VPN governance to MFA, device posture, ZTNA, and dormant account cleanup. If your environment also has service-side or workload-side remote access, the same principle applies to SPIFFE and SPIRE: the access path is not the trust decision, the verified identity is.

Risk and Threat Considerations

VPNs become risky when teams confuse encrypted transport with trustworthy access. If stolen credentials, a compromised device, or an overbroad remote access rule can still open a large internal segment, the VPN is amplifying blast radius instead of reducing it.

Failure mechanism: An attacker uses valid VPN credentials, hijacks an authenticated session, or abuses broad network reach after a successful login. Once inside, they can move laterally, target internal services, and bypass controls that were never designed for perimeter-style remote access.

Impact: Remote access abuse can turn a single account compromise into internal reconnaissance, privilege escalation, or data exposure. The practical loss is not the tunnel itself, it is the false assumption that tunnel presence equals trust.

The risk is sharper when VPN accounts are long-lived, shared, weakly monitored, or tied to static network segments. In those conditions, the access path becomes hard to revoke cleanly and difficult to distinguish from legitimate remote work.

Practitioner Guidance

What to prioritise: Treat VPN governance as an access policy problem first and a networking problem second. Decide which applications still require VPN transport, and which should be reachable only through identity-aware policy at the app layer.

What to verify: Confirm that VPN authentication strength, device posture checks, and downstream application authorization are independently enforced. If any of those checks happen only at the tunnel, the design is not zero trust in practice.

Common mistake: Teams often modernise the access technology but preserve the old trust model. The sign that this has happened is a broad VPN that still behaves like an internal network substitute, with little segmentation and weak revocation discipline.

Practitioner takeaway: Keep the VPN if you need it, but strip it of implicit trust. In zero trust, the tunnel is just a path, while authorization must remain conditional, granular, and continuously revisited.

Related resources from NHI Mgmt Group

• How should security teams use IPS in a zero trust architecture?
• How should security teams use OAuth as part of a cloud native zero trust architecture?
• How should security teams use SOAR to support a zero trust architecture in large, understaffed environments?
• How should security teams use cyber threat intelligence to strengthen a zero trust architecture?