In short
ZTNA vs VPN comes down to scope. A VPN places the signed-in user on the network, while zero trust network access brokers a connection to one application at a time after checking identity, device and context, with the application hidden from the internet. ZTNA reduces exposure and lateral movement; a VPN still suits some legacy and site-to-site traffic.
Want an impartial recommendation?
Tell us about your users, systems and priorities and we will tell you which option fits, and why.
The short answer
A remote access VPN builds an encrypted tunnel from a device to a gateway, and once the user has signed in the device is given an address on the internal network. From there, what it can reach depends on routing and firewall rules, which in many organisations are broad because they were written for convenience. The VPN gateway itself has to listen for connections from anywhere on the internet.
Zero trust network access (ZTNA) starts from the opposite position: nothing is reachable until a policy engine says so. Each request for an application is checked against the user's identity, the device, its health and the context of the request, and only then is a connection brokered to that one application, usually through a connector that makes outbound connections only. There is no network address to be handed, and nothing for an attacker to scan.
For a vendor-neutral definition of the term itself, see our explainer on ZTNA. The step-by-step mechanics are on how zero trust network access works.
ZTNA vs VPN comparison
| Remote access VPN | Zero trust network access (ZTNA) | |
|---|---|---|
| Access scope | Network or subnet level once connected | One application (or a defined group) per policy |
| Trust model | Authenticate once at connection, then largely trusted | Every request evaluated by policy; access denied by default |
| Exposure to the internet | The VPN gateway listens for inbound connections | Applications sit behind outbound-only connectors or a cloud broker; only the broker is public |
| Lateral movement | A compromised device can often reach many systems | Limited to the applications the policy allows |
| Signals used | Mostly credentials, sometimes MFA and a basic posture check | User identity, device identity, device health and user behaviour (the NCSC's four signal types) |
| During the session | Usually unchanged until disconnect | Can be re-evaluated and revoked as conditions change |
| User experience | Connect, wait, disconnect; traffic often hairpins through head office | Usually transparent or always-on; private and internet traffic can take different paths |
| Legacy and server-initiated traffic | Handled well, since it is network-level | Varies by vendor; some keep a VPN-style option for these flows |
| Contractors and unmanaged devices | Hard to restrict without separate gateways or rules | Per-app access, often clientless through a browser |
| Logging | Connection logs plus firewall logs | Per-application allow and deny decisions, with the signals that drove them |
The table describes typical designs. A tightly segmented VPN with strong MFA and posture checks is far better than a flat one, and a ZTNA platform configured with broad rules can behave much like a VPN, which is the NCSC's first anti-pattern (below).
Still not sure which way to go? Ask us
Tell us what matters most to you and we will recommend one, with the trade-offs explained.
Why organisations are moving off remote access VPNs
The usual reasons are practical rather than fashionable:
- Exposed gateways. An internet-facing VPN appliance must accept connections from anyone, so every vulnerability in it is reachable from the whole internet, and patching it often means downtime.
- Broad access. Once connected, users and their devices frequently reach far more than they need, which turns one stolen password or infected laptop into a network-wide problem.
- Network location as trust. Rules that allow traffic because it comes from the VPN address pool or an office IP range are exactly what the NCSC warns against.
- Questions from insurers and auditors. Cyber insurance proposal forms and supplier security questionnaires can ask how remote access is protected and whether MFA is enforced on it.
- Ageing clients and appliances. End-of-life VPN clients or hardware force a decision anyway, so it is a natural point to change the access model rather than buy the same thing again.
If several of these apply, our VPN replacement project guide sets out the options and a migration plan.
What the NCSC says about VPN-style trust
The NCSC's ZTNA guidance, published on 27 May 2026, does not ban VPNs. It lists VPN-as-a-service alongside SSE and SASE as examples of network-level policy engines, and its first design requirement, transporting network traffic securely, names IPsec as a typical protocol. What it insists on is that policy is enforced before any connection is made, and that being on the corporate network, a VPN or a known location is not enough to gain access.
Three of its four anti-patterns describe VPN thinking carried into a new product:
| NCSC anti-pattern | What it looks like | How to avoid it |
|---|---|---|
| Recreating the 'walled garden' trust model | An SSE or SASE platform dropped in as a straight VPN replacement: users authenticate once and then reach most of the internal network | Scope each policy to the minimum applications needed, and pair ZTNA with segmentation |
| Trusting network location | Allowing access because a request comes from an office range, a VPN address pool or an internal cloud range | Send every request through the policy engine; treat location as a supporting signal at most |
| Maintaining legacy access routes that bypass the policy engine | Keeping the old VPN, direct routes or static firewall rules running beside ZTNA indefinitely | Remove them wherever possible; restrict any that must stay to the minimum and govern them centrally |
The remaining one, the third on the NCSC's list, is exposing private applications to the internet: the problem ZTNA brokers and outbound-only connectors exist to solve. Our summary of the NCSC ZTNA guidance covers all eight requirements.
Weighing up the options?
We can compare them against your own requirements and give you a straight answer.
When a VPN is still reasonable
Replacing remote access VPNs does not mean every tunnel goes. Network-level connectivity still makes sense for:
- Server-initiated traffic, where something inside the network needs to connect out to the remote device, for example some management and support tools. Per-app ZTNA is designed around user-initiated connections.
- Legacy protocols and thick-client applications that a particular ZTNA product cannot carry. Coverage differs a lot between vendors, so test these in a trial.
- Site-to-site links between offices, data centres and cloud networks, usually IPsec. SASE platforms use these tunnels themselves to connect branches.
- A transition period, while applications move across one at a time.
The practical answer for many organisations is a hybrid: ZTNA for most applications and a tightly scoped VPN for what is left, ideally under the same policy engine. Cisco Secure Access, for example, includes VPN as a service alongside its ZTNA for applications that need network-level access, and NordLayer combines business VPN gateways with zero trust controls such as device posture checks and, on Premium, a cloud firewall for segmentation. The transport differences are covered on ZTNA vs IPsec and SSL VPN.
Zero trust VPN: what the phrase usually means
You will see "zero trust VPN" used in two ways. Sometimes it means a conventional VPN with MFA and a device check bolted on, which is an improvement but still grants network-level access. Sometimes it describes a product that uses a VPN-style tunnel underneath but makes per-user, per-application decisions, such as a WireGuard-based client that only reaches what policy allows.
Three questions separate the two:
- Is the gateway hidden until the user has authenticated, or does it listen for anyone on the internet?
- After sign-in, can the device reach the network, or only named applications?
- Is access re-checked during the session, and is every allow and deny decision logged?
Zero Networks Connect is an example of the second kind: its remote access service has no open ports on the internet, MFA is required before a port opens for that user's IP address only, and remote users fall under the same segmentation policy as everything else. See Zero Networks Connect.
ZTNA, SSE and SASE: where the VPN replacement sits
ZTNA on its own replaces the private access part of a VPN. If remote users also need web and SaaS protection that used to come from backhauling traffic through the office firewall, you are looking at a security service edge (SSE), and if branch networking is changing too, SASE. Our ZTNA vs SASE page explains how the layers nest, and ZTNA providers compares every platform we supply.
Moving from VPN to ZTNA with Forever Systems
We supply several competing ZTNA, SSE and SASE platforms, so we can recommend on fit rather than steer you to one vendor. A typical route:
- Review who uses the VPN today, which applications they reach, and which firewall rules trust the VPN address pool.
- Classify each application: web, thick-client, SSH or RDP, or legacy and server-initiated.
- Shortlist and trial two or three platforms with a pilot group on real applications.
- Migrate application by application, then close the VPN's inbound ports and remove rules that trusted it.
Scope and timescales are confirmed at quote; see how to implement zero trust network access for the full phased plan. Contact us to talk through your current VPN.
Explore ZTNA vs VPN
How Forever Systems helps with ZTNA and SASE
We are an independent IT and cyber security provider. We supply and support several zero trust access and SASE platforms, so we can recommend what fits how your people work rather than one vendor's answer to everything.
- Assess first: we look at your current VPN, firewall, identity set-up and the applications people need to reach before suggesting anything new
- Vendor-aware advice across ZTNA, SSE and SASE options, including Cisco Secure Access and Check Point Harmony SASE
- Pilots and phased roll-out: we can help you start with one group of users or one application, then extend access policy by policy
- VPN replacement: planning the move away from remote access VPNs, including identity provider integration and device posture checks
- Ongoing support: policy changes, licence reviews and renewals, with the details confirmed at quote
We work with businesses, schools, charities and public sector organisations. Pricing depends on users, features and term, so ask us for a quote.
Frequently asked questions
Is ZTNA better than a VPN?
For user access to private applications, ZTNA usually reduces risk because it grants access per application after checking identity and device, keeps applications off the internet and limits lateral movement. A VPN is still reasonable for site-to-site links, server-initiated traffic and some legacy protocols.
Can ZTNA completely replace a VPN?
Often for most users and applications, but not always for everything. Many organisations keep a tightly scoped VPN or VPN-as-a-service for the few flows ZTNA cannot carry. The NCSC advises removing legacy routes that bypass the policy engine wherever possible and restricting any that remain.
Is ZTNA a type of VPN?
Not in the usual sense. Some ZTNA products use encrypted tunnels, including WireGuard or QUIC-based transports, but the decision is made per user and per application by a policy engine, rather than giving the device an address on the network.
Is a VPN with MFA zero trust?
It is better than a VPN without MFA, but if the user still gets network-level access after signing in, it does not meet the NCSC's requirement that policy is enforced per request before access, using several signals. The NCSC specifically warns against trusting VPN address pools.
Is ZTNA slower than a VPN?
Not inherently. Performance depends on the provider's points of presence, where connectors sit and the route to the application. Because ZTNA does not have to send all traffic through head office, users often avoid the hairpin a VPN creates. Test with your own applications during a trial.
What is the difference between ZTNA and SASE?
ZTNA controls access to private applications. SASE combines ZTNA with web and SaaS security (the security service edge) and SD-WAN networking for branches. See our ZTNA vs SASE comparison.
Still deciding?
Ask us and a member of our team will reply by email with a straight answer.