ZTNA vs VPN: how zero trust network access differs from VPNs in access scope, trust decisions and exposure, and how to plan a transition.
Virtual private networks (VPNs) have long been the default way to give remote users access to internal systems. Zero trust network access (ZTNA) takes a different approach that limits what an attacker can reach if an account or device is compromised.
How a VPN works
A VPN creates an encrypted tunnel that places the user’s device on the corporate network. Once connected, the user can often reach far more systems than they need, and VPN gateways exposed to the internet are frequent targets for attackers.
How ZTNA works
ZTNA grants access to specific applications rather than whole networks. Each request is evaluated against identity, device health and context, and applications are typically hidden from the internet behind a broker. This reflects zero trust principles described in guidance such as NIST SP 800-207: never trust by default, always verify, and grant least privilege.
Key differences
| VPN | ZTNA |
|---|
| Access scope | Network-level | Application-level |
| Trust decision | At connection | Continuous, per request |
| Exposure | Gateway visible on the internet | Applications hidden behind a broker |
| User experience | Connect first, then work | Often seamless per application |
Planning a transition
- Start with web applications and third-party access.
- Integrate with your identity provider and device management.
- Run VPN and ZTNA side by side during migration.
- Retire VPN access for groups once their applications are covered.
5 proven steps to move from VPN to ZTNA
- Inventory applications and users. Identify which applications remote users access and group them by sensitivity and protocol.
- Strengthen identity first. ZTNA depends on reliable identity, so enforce phishing-resistant multi-factor authentication and clean up group memberships.
- Start with web applications. Browser-based internal applications are usually the easiest to publish through ZTNA.
- Add device posture checks. Require managed, compliant devices for sensitive applications and offer limited access from unmanaged devices.
- Retire VPN gradually. Reduce VPN scope as applications move, keeping it only for specific legacy use cases until they can be addressed.
Benefits of ZTNA
- Users reach only the applications they are authorised for, limiting lateral movement.
- Applications are hidden from the internet, reducing attack surface.
- Access decisions consider identity, device health and context continuously.
- Cloud delivery can improve performance for distributed workforces.
Common mistakes to avoid
- Recreating broad network-level access inside a ZTNA tool.
- Neglecting third-party and contractor access, a common source of risk.
- Ignoring user experience, prompting workarounds.
Frequently asked questions
Is VPN insecure?
VPNs are not inherently insecure, but broad network access and exposed gateways have made them frequent attack targets.
Does ZTNA support non-web applications?
Many ZTNA services support SSH, RDP and other TCP or UDP applications through a client agent.
A 90-day action plan
Days 1 to 30: analyse remote access logs to list applications and user groups, and enforce strong authentication for all remote users.
Days 31 to 60: deploy a zero trust access service for a pilot group and a handful of browser-based applications, with device posture checks for sensitive ones.
Days 61 to 90: expand to more applications and third-party users, reduce network-level access and set a date for retiring the remote access concentrator for most staff.
Questions to ask providers
- Which protocols and application types are supported?
- How are device health and identity signals evaluated continuously?
- Where are points of presence located relative to our users?
- How is contractor and partner access handled without agents?
- What logs and integrations are available for security monitoring?
Key terms explained
- Zero trust: a security model that verifies every request rather than trusting network location.
- Device posture: the security state of a device, such as patch level and encryption.
- Lateral movement: an attacker moving from one compromised system to others.
- Policy decision point: the component that decides whether to grant access.
The bottom line
Remote access has changed from connecting users to a network to connecting users to specific applications. Moving to identity-based, application-level access reduces exposure, limits the damage from compromised accounts and often improves user experience. Strengthen identity first, start with straightforward applications, include contractors and partners, and reduce legacy network-level access in stages. With a clear plan, organisations can modernise remote access without disrupting the people who depend on it every day.
Further reading on ZTNA vs VPN
For authoritative, vendor-neutral guidance on ZTNA vs VPN, see NIST SP 800-207 Zero Trust Architecture. You can also browse our free whitepapers.
