The VPN has been the default answer to remote access for more than 20 years. It was designed for a world where users sat in offices, applications sat in the data centre, and the occasional remote worker needed a tunnel back in.
That world has gone. Your users are at home, on trains and on supplier sites. Your applications are split across on-prem, private cloud, Microsoft 365 and a long tail of SaaS.
So, the VPN vs ZTNA question isn’t really about swapping one remote access product for another. It’s about whether network-level trust still makes sense at all. In this blog, we break down how each model works, where VPNs fall short, where ZTNA fits into a wider Zero Trust strategy, and how to move from one to the other without breaking the services your organisation depends on.
How a VPN works, and where the model breaks
A remote access VPN (SSL/TLS or IPsec) builds an encrypted tunnel from the user’s device to a concentrator at the network edge. Once the user authenticates, the device is handed an IP address on the internal network. From there, access is governed largely by network controls: subnets, VLANs, ACLs and firewall rules.
The encryption is fine. The trust model is the problem.
A VPN answers one question, once: “Is this user allowed onto the network?” After that, it largely stops asking. That creates four issues you’ll probably recognise:
- Too much implicit trust. Once connected, users (or attackers with stolen credentials) can often reach far more than they need, which makes lateral movement easy.
- Authentication stops at the door. Nothing checks whether the session or the device is still trustworthy after login.
- Coarse access, thin visibility. Policy is tied to subnets and ACLs rather than users and applications, so least privilege is hard to enforce and you can’t see what people actually do once connected.
- A bigger attack surface. Internet-facing gateways are a favourite target, and keeping them patched and managed is a constant overhead.
What is ZTNA, and how does it work?
Zero Trust Network Access (ZTNA) connects a verified user to a specific application, never to the network. Every request is evaluated against identity, device posture and context before access is granted, and the application itself stays invisible to anyone who isn’t authorised to use it.
Most modern ZTNA services, including Zscaler Private Access (ZPA), use a broker model. Here’s what happens when a user opens a private application:
- The user requests an application. A lightweight client on the device (or a browser, for clientless access) sends the request to a cloud-delivered broker, not to your network.
- Identity is verified. The broker checks the user against your identity provider, such as Entra ID or Okta, typically with MFA and SSO.
- Device and context are assessed. Posture signals such as OS version, disk encryption, EDR status and certificate presence are combined with location, time and risk.
- Policy is applied. The request is checked against granular, application-level policy: this user, on this device, can reach this application, right now.
- An inside-out connection is stitched together. An app connector sitting next to the application has already made an outbound connection to the broker. The broker joins the two sessions. No inbound ports are opened, and the application is never exposed to the internet.
- Access is continuously reassessed. If device posture changes or risk increases, access can be restricted or revoked mid-session.
That inside-out architecture is the key difference. With a VPN, you publish a front door and defend it. With ZTNA, there’s no front door to find.
ZTNA typically sits inside a wider Security Service Edge (SSE) or SASE platform. In Zscaler’s case, ZPA handles private application access while Zscaler Internet Access (ZIA) secures internet and SaaS traffic, so the same identity-led policy applies wherever the user is and whatever they’re connecting to.
That inside-out architecture is the key difference. With a VPN, you publish a front door and defend it. With ZTNA, there’s no front door to find.
ZTNA isn’t Zero Trust. It’s where Zero Trust gets real.
Here’s the uncomfortable truth: plenty of organisations have bought ZTNA and still don’t have Zero Trust. They’ve replaced the VPN client, kept the same flat access groups, and recreated “everyone in IT can reach everything” in a shiny new console.
Zero Trust is a strategy and a process, not a product. ZTNA is one of the most powerful tools for delivering it, because it turns principles like least privilege and “never trust, always verify” into enforceable policy. But the tool is only as good as the thinking behind it. That means knowing your applications, knowing who genuinely needs what, and having an identity and device estate you can trust as policy inputs.
The same goes for the wider platform. Buying SASE isn’t the same as achieving resilience. The value comes from design, migration and ongoing tuning, which is exactly where many programmes stall.
So, should you kill your VPN?
Eventually, for most user-to-application access, yes. Right now or tomorrow, probably not.
There are still legitimate places for VPN-style connectivity: some site-to-site links, certain legacy or non-standard protocols, specialist OT environments and a handful of admin workflows. The goal isn’t a big-bang switch-off, but to shrink the VPN’s role steadily until what’s left is small, well understood and tightly controlled.
The security vs productivity trap
Zero Trust has a reputation for adding friction. Done badly, it does: more prompts, more blocked requests, more tickets. And friction creates its own risk, because people route around controls that get in their way.
Done well, ZTNA should feel faster and simpler than the VPN it replaces. No “connect to VPN” step, no backhaul, and the same experience in the office and at home. If your users are complaining after a ZTNA rollout, the problem is almost always the policy design, not the technology.
Moving from VPN to ZTNA without disruption
You don’t need to replace everything at once. The organisations that get this right treat VPN to ZTNA migration as a phased programme, run VPN and ZTNA in parallel, and build confidence one use case at a time.
- Discover and map. Inventory your private applications, who uses them and how. VPN logs are a goldmine here: they show what people actually access, not what the documentation says. Most teams find applications they didn’t know existed.
- Get identity and devices ready. ZTNA policy is only as trustworthy as its inputs. Clean up identity groups, enforce MFA and SSO, and decide which device posture signals you’ll rely on.
- Pick a focused first use case. Third-party and contractor access is often the best place to start: high risk, clearly scoped and a quick win. Replacing VPN access for a single business unit or a set of web apps works well too.
- Design least-privilege policy. Build policy around applications and roles, not networks. Start slightly broader if you need to, use the logs to see real usage, then tighten.
- Pilot, measure, expand. Run ZTNA alongside the VPN for the pilot group. Track login times, ticket volumes and user feedback, then roll out in waves.
- Shrink the VPN. As each group moves, remove its VPN access. Reduce the concentrator’s scope until only the genuine exceptions remain, then review those too.
- Operate and optimise. Zero Trust isn’t a project with an end date. Review policy, monitor access patterns and tune continuously as applications, users and threats change.
Why this matters now for the UK public sector
For public sector organisations, VPN vs ZTNA is no longer just an architecture decision, but increasingly a compliance and assurance one.
The NCSC’s Zero Trust architecture design principles already set the direction: know your users, devices and services; assess device and service health; use policy to authorise every request; authenticate and authorise everywhere; and don’t trust any network, including your own. A traditional VPN, which grants network-level trust after a single check, sits awkwardly against almost every one of those principles. ZTNA maps onto them directly.
GovAssure is raising the bar on what “good” looks like for government departments and arm’s-length bodies, with assessments grounded in the NCSC’s Cyber Assessment Framework. At the same time, the UK Government Cyber Action Plan is putting investment behind public sector cyber resilience. Together, that creates both the pressure and the opportunity to modernise secure access.
The same logic applies to large enterprises in regulated sectors such as financial services, transport and retail, where operational resilience and audit scrutiny are rising just as fast.
Zero Trust for the real world, with FullProxy and Zscaler
We’re security and infrastructure people ourselves, so we know the hard part isn’t choosing ZTNA. It’s getting from a VPN-dependent estate to working, least-privilege access without disrupting the services your users rely on.
That’s what we do. As an accredited Zscaler partner, FullProxy designs, deploys and manages ZPA and ZIA, taking you from platform to performance:
- Zero Trust roadmaps built around your applications, your users and your constraints, not a vendor’s ideal estate
- Policy design and migration support to move from VPN to ZTNA in phases, with VPN and ZTNA running side by side
- Embedded expertise and managed services
- Ongoing optimisation and monitoring, so policy keeps pace with your organisation
Alongside Zscaler, we’re a Fortinet Expert Partner and F5 Gold Partner, so we can work with the mixed estate you actually have. And we’ve delivered in complex, high-assurance environments across the UK public and private sectors.
Not sure where you are on the journey? Book a Zero Trust maturity review and we’ll help you benchmark your current access model and identify a practical first use case. Or download “Your next steps to Zero Trust” for a quick guide you can share with your team.
You don’t need to replace everything at once. The organisations that get this right treat VPN to ZTNA migration as a phased programme, run VPN and ZTNA in parallel, and build confidence one use case at a time.
VPN vs ZTNA: FAQ
What is the main difference between a VPN and ZTNA?
A VPN gives an authenticated user access to a network. ZTNA gives a verified user access to a specific application, based on identity, device posture and context, and re-checks that access continuously. The result is a much smaller attack surface and far less scope for lateral movement.
Is ZTNA more secure than a VPN?
For user-to-application access, yes. ZTNA removes the public-facing gateway, hides applications from unauthorised users and enforces least-privilege access per application. It’s only as strong as its policy design and identity controls, though, so implementation matters.
Can ZTNA completely replace a VPN?
For most remote user access, it can. Some site-to-site connectivity, legacy protocols and specialist environments may still need VPN-style connections for a while. The practical goal is to shrink the VPN’s footprint to a small, well-controlled set of exceptions.
Is ZTNA the same as Zero Trust?
No. Zero Trust is a security strategy built on principles such as “never trust, always verify” and least privilege. ZTNA is one of the key technologies for putting those principles into practice for application access.
How long does it take to migrate from VPN to ZTNA?
A focused pilot, such as third-party access or a single business unit, can often be live in weeks. A full migration usually runs in phases over several months, depending on the number of applications, identity maturity and how much legacy you’re carrying.
Does ZTNA work with legacy and on-premises applications?
Yes. App connectors sit alongside on-prem and private cloud applications and make outbound connections to the ZTNA service, so applications don’t need to be rewritten or moved to the cloud.
What is the difference between ZIA and ZPA?
Zscaler Internet Access (ZIA) secures users’ traffic to the internet and SaaS applications. Zscaler Private Access (ZPA) is Zscaler’s ZTNA service, connecting users to private applications without exposing them or the network. Together they apply consistent, identity-led policy to all user traffic.
Does ZTNA help with NCSC and GovAssure requirements?
ZTNA aligns closely with the NCSC’s Zero Trust architecture design principles, including policy-based authorisation of every request and not trusting any network by default. It can help evidence stronger access controls within a GovAssure assessment, as part of a wider Zero Trust approach.
