Organisations should use zero trust network access when the real need is access to specific private applications, not entry to the internal network. If users mainly need application-level access and off-network policy enforcement, ZTNA fits better than a full VPN. If the goal is only encrypted internet traffic, a separate control is usually more appropriate.
What ZTNA changes compared with full VPN access
ZTNA changes the access model, not just the encryption layer. A full VPN usually places the user or device into a broader trusted network segment, while ZTNA brokers access to a specific application after policy checks. That distinction matters when the business requirement is “reach this app securely” rather than “join the network and sort out access internally.”
Use ZTNA when the access need is narrow, repeatable and policy-driven: one application, one service, one workflow, or one class of users. That is why ZTNA is often a better fit for third parties, contractors and remote staff who do not need lateral network visibility. When the real requirement is network reachability across many internal hosts, a full VPN may still be the more practical mechanism.
ZTNA also supports a cleaner separation between connectivity and trust. It makes per-application policy, posture checks and conditional access the primary control points, instead of assuming that network entry is a useful proxy for legitimacy. For teams working through a migration, the right framing is usually application reach first, then decide whether any remaining use cases truly need network-level access.
Where full VPN still fits better
A VPN is still justified when the user genuinely needs broad network access for administration, discovery, troubleshooting, or legacy workflows that cannot be decomposed into application-level access yet. In those cases, the network tunnel is doing real work that ZTNA may not replace cleanly. The decision should be based on the shape of access needed, not on whether the organisation already owns a VPN product.
Full VPN also remains common where the destination cannot easily be fronted by a ZTNA broker, where segmentation is immature, or where a small number of trusted operators need access to a wide range of internal systems. That said, “we have always used VPN” is not a good justification on its own. If the access pattern is shrinking toward one or a few private applications, continuing to expose broad network reach creates avoidable blast radius.
The practical test is simple: if the user’s work can be satisfied without giving them a network foothold, ZTNA usually reduces unnecessary exposure. If the work depends on general internal network presence, a VPN may still be appropriate, but it should be treated as a higher-trust path with tighter controls and clearer justification.
How to decide between ZTNA and VPN in practice
Start by mapping the actual use case, not the preferred technology. ZTNA guidance is most useful when the access request can be expressed as a specific application, a specific policy and a specific population. If you cannot define the target application clearly, or if the user needs broad administrative reach, that is a sign the requirement may still belong with VPN or a staged migration approach.
Then compare operational realities. Device posture, third-party access, outbound-only connectivity and per-application segmentation tend to favour ZTNA. Broad troubleshooting, legacy protocols, network scanning and unmanaged internal discovery tend to favour VPN. In mature environments, many organisations end up with both, but with ZTNA absorbing the majority of routine remote access and VPN retained only for the narrow set of cases that truly need it.
For architecture decisions, use the access pattern to determine the control, not the other way around. If you want to reduce implicit trust and limit the blast radius of a stolen credential or compromised endpoint, ZTNA is usually the better default. If the requirement is broad internal reach for a short-lived but legitimate task, keep the VPN, but avoid expanding it beyond that use case.
Risk and Threat Considerations
Broad VPN access can turn one successful login into a much larger exposure than the business intended. Once a user or attacker has network-level reach, the main risk is lateral movement, internal reconnaissance and access to services that were never meant to be reachable from that session. ZTNA reduces that exposure by making the application, not the network, the trust boundary.
Failure mechanism: A full VPN can overextend trust when broad network access is granted for a narrow business need, especially if credentials, endpoint hygiene or session controls are weak.
Impact: A compromised account or device can expose more internal systems than necessary, increasing blast radius, traversal opportunities and the chance that one access path becomes a foothold for wider compromise.
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 — Identity and Access Management, Authentication, and Authorization | ZTNA is an application-centric Zero Trust access decision. |
| Recommendation — Enforce per-resource access decisions instead of broad network trust. | ||
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | The question compares remote access mechanisms and their trust boundaries. |
| AC-6 — Least Privilege | ZTNA is preferable when broad VPN reach would exceed the user's task needs. | |
| Recommendation — Restrict remote access to the minimum paths needed for the task. Grant only the access required for the specific application or function. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The decision is about controlling who can reach which internal resources remotely. |
| Recommendation — Segment remote access by application and remove unnecessary broad entry paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is selecting the right access-control model for remote users. |
| Recommendation — Define remote access rules by application need and trust boundary. | ||
Practitioner Guidance
What to prioritise: Classify each remote access use case by the minimum resource it needs, not by department or user type. If the need is application-specific, steer it to ZTNA; if the need is genuine network-level administration, keep VPN as an exception path.
What to verify: Confirm that the selected control matches the real access pattern. A ZTNA rollout should be measured by how many broad VPN use cases it eliminates, how tightly it enforces per-application access, and whether any remaining VPN users truly need network-level visibility.
Common mistake: Treating ZTNA as a cosmetic replacement for VPN while leaving the same broad reach, same legacy exceptions and same weak policy model in place. That preserves the risk but changes the label.
Practitioner takeaway: Choose ZTNA when you want to grant access to a specific private application with policy enforcement at the edge; keep VPN only where the task genuinely requires broader internal network reach.
Related resources from NHI Mgmt Group
- Guide: Remote Access Identity Guide
- What happens when healthcare organisations allow third parties to connect through VPN-style remote access instead of Zero Trust network access?
- What happens when organisations rely on broad network access instead of Zero Trust for systems that process personal data?
- Should organisations use Zero Trust instead of AAA for machine access?
- What is the difference between JIT access and Zero Trust for NHIs?