Zero Trust vs VPN: How They Differ

If you work in or near IT, you have probably heard that "VPNs are dead" and that zero trust is the future. If you simply use a VPN to protect your connection on a hotel network, the debate may sound like it has nothing to do with you. Both reactions miss what is going on. Zero trust and VPN are not two brands of the same product. They answer different questions, and the confusion comes from the way vendors compare them.

This guide explains the difference in plain terms: what a traditional remote-access VPN does and where it falls short, what zero trust actually means, and how related terms such as ZTNA, SASE and SD-WAN fit in. It is general background about the field, not advice for a particular organisation, and it makes no claims about any specific product.

How a traditional remote-access VPN works

A remote-access VPN gives a user a secure path into a private network. Your laptop builds an encrypted tunnel to a VPN gateway at the organisation. Once the tunnel is up, your laptop behaves as if it were plugged into the office network, with an internal address and reach to whatever the network allows. For the basic mechanics, see how does a VPN work.

This model has real strengths. It is mature, well understood, works with almost any application, and is supported by standards and guidance such as NIST SP 800-77 for IPsec VPNs. NIST's guide to telework and remote access security lists tunnelling VPNs alongside other remote access options, including portals, remote desktop and direct application access.

The weakness is the idea underneath it, sometimes called castle and moat. The tunnel is the drawbridge. Once someone is inside, the network tends to trust them. That produces several well-known problems:

• Broad access by default. A VPN user often reaches far more systems than their job needs, because restricting access network by network is hard to maintain.
• Stolen credentials become powerful. If an attacker gets a valid username and password, the VPN may give them the same reach as the real employee.
• Lateral movement. A compromised laptop on the tunnel can probe other machines on the internal network.
• Exposed gateways. A VPN gateway must be reachable from the internet, which makes it a visible target that needs constant patching.
• Performance and complexity. Sending all remote traffic through a central gateway can create bottlenecks, especially when most applications now live in the cloud.

What zero trust means

Zero trust is a security approach, not a product. The best-known definition comes from NIST SP 800-207, the Zero Trust Architecture document. Its core idea is that no user, device or network location is trusted just because of where it is. Being on the office network, or inside a VPN tunnel, does not by itself earn trust.

In practice, zero trust rests on a few principles:

1. Verify explicitly. Every access request is checked using identity, device health, location and other signals.
2. Grant least privilege. Each user gets access only to the specific resource they need, for as long as they need it.
3. Assume breach. Design as if an attacker may already be inside, so that damage is contained by segmentation and monitoring.
4. Check continuously. Trust is not permanent. A session can lose access if the device falls out of compliance or behaviour looks unusual.

None of these principles mentions a tunnel. A zero trust design might use encrypted tunnels, but the tunnel is not what makes it zero trust. Strong authentication is a foundation: two-factor authentication and the guidance in CISA's MFA resources matter far more here than the choice of tunnelling protocol. The CISA Zero Trust Maturity Model shows how an organisation can progress step by step across identity, devices, networks, applications and data.

ZTNA vs VPN

Zero trust network access, or ZTNA, is the product category most often compared with VPNs. It applies zero trust ideas to the question "how does a remote person reach one of our applications?"

In a typical ZTNA design:

• The user's device runs a small agent, or the user opens a web portal for browser-based applications.
• A broker or gateway checks who the user is, how healthy the device is and whether policy allows access.
• If allowed, the user is connected to that single application, not to the network behind it.
• The application is not exposed directly to the public internet, which reduces the attack surface.
• The decision is repeated over the session.

The comparison searches such as "ztna vs vpn" usually come down to this difference:

	Traditional remote-access VPN	ZTNA
What you get	A path onto the network	Access to specific applications
Default trust	Often broad once connected	Narrow, per application
Device checks	Optional, often at connection time	Typically built in and repeated
Exposure of the network	Gateway reachable from the internet	Applications hidden behind a broker
Best at	Legacy apps and anything network-based	Web, cloud and modern applications

ZTNA is not magic. It needs good identity systems, accurate device information and well-written policies. Some older applications that rely on open network access are hard to place behind it. And a few products sold as ZTNA are, under the hood, tunnels with better policy controls. Treat the label with healthy curiosity and ask what actually changed.

SASE vs VPN

SASE, short for Secure Access Service Edge, was coined by the research firm Gartner in 2019. It describes delivering networking and security together as a cloud service. A typical SASE bundle includes:

• SD-WAN for connecting sites and routing traffic efficiently.
• Secure web gateway to filter web traffic.
• Cloud access security broker to control use of cloud applications.
• Firewall as a service for network-level controls.
• ZTNA for access to private applications.

So a "SASE vs VPN" comparison is a comparison between an architecture and a single technology. A SASE platform can make a traditional VPN unnecessary for many remote staff, because ZTNA and web gateway functions handle the same needs with finer control. But SASE is aimed at organisations that want to consolidate several tools, and it is a large project. A small business with a handful of staff may find a simple, well-maintained VPN with strong authentication a more practical start.

SD-WAN vs VPN

SD-WAN, or software-defined wide area network, is the other term that often gets mixed in. It solves a different problem. A company with many branches needs those sites to talk to head office and the cloud. SD-WAN manages several connections at each branch, such as broadband, cellular and private links, and steers each application's traffic over the best path according to central policy.

The relationship to VPNs is nuanced:

• SD-WAN products commonly use encrypted tunnels, often IPsec, between sites, so VPN technology is frequently inside them.
• SD-WAN is about site-to-site connectivity and performance. A remote-access VPN is about individual users connecting from anywhere.
• SD-WAN on its own is not a zero trust solution. It improves how traffic flows, but it does not decide whether a given person should reach a given application.

When an article compares "sd wan vs vpn", the useful answer is that they usually operate at different layers and are often used together.

Side by side: which tool for which situation

Situation	A reasonable fit	Why
A small team needs to reach one internal server	Remote-access VPN with strong authentication	Simple, familiar and inexpensive to run
A growing company with mostly cloud and web apps	ZTNA or SASE	Per-application access and less reliance on a central gateway
A company with many branch offices	SD-WAN, often with encrypted tunnels	Manages several links and applies central policy
Legacy systems that need full network access	VPN, ideally with segmentation	Many older applications expect a network path
Contractors who need one application only	ZTNA or a tightly scoped VPN account	Least privilege, easy to revoke
An individual on hotel or cafe Wi-Fi	A personal VPN, plus HTTPS and good habits	Protects traffic on a network you do not control

The last row matters for ordinary readers. A personal VPN service, the kind you install on a phone or laptop, solves a different problem from enterprise zero trust. It encrypts your traffic between your device and the VPN service so that the local network cannot read it. It is not an identity-based access control system for company applications, and it does not replace the need for good passwords. See what a VPN cannot protect you from for the limits, and VPN for remote work for how the two ideas meet in everyday home-office setups.

Moving toward zero trust, step by step

Zero trust is a journey, not a switch. Organisations that succeed rarely rip out everything at once. A sensible path looks like this:

1. Strengthen identity first. Turn on multi-factor authentication everywhere, starting with administrators and remote access. This is the single most valuable step.
2. Inventory what you have. List applications, who needs them and how they are reached today.
3. Know your devices. Track which devices connect and whether they are patched and managed.
4. Reduce what the VPN can reach. Even before changing tools, segment the network so that a VPN user can reach only what they need. Where split tunnelling is used, understand the trade-offs described in what is split tunneling.
5. Move easy applications first. Web and cloud applications are usually the simplest to place behind ZTNA.
6. Keep the VPN where it fits. Leave legacy and site-to-site uses on tunnels until a replacement is ready.
7. Monitor and adjust. Log access decisions, review them and tighten policies over time.

Limits and what to watch for

• Zero trust is not a product you buy once. Vendors use the term freely, so ask which principles a product actually implements and how.
• A VPN is not obsolete. It remains a sound, standards-based tool, especially for site-to-site links and personal protection on untrusted networks. A badly configured ZTNA product can be worse than a well-run VPN.
• Complexity has a cost. Policies, identity integration and monitoring need people with time and skill. Small organisations should weigh that honestly.
• No approach prevents all attacks. Phishing, stolen devices and mistakes by trusted users can defeat any design. Training and basic hygiene still matter.
• Check the source of claims. Vendor comparison pages are marketing. NIST and CISA documents are a more neutral basis for evaluating a plan.

Summary

A VPN builds an encrypted tunnel, and traditional remote-access VPNs often give users broad access to a network once they are in. Zero trust is a security approach that refuses to grant trust based on location, so it verifies each request and gives each user the least access needed. ZTNA applies that approach to application access, SASE bundles networking and security as a cloud service, and SD-WAN manages branch connectivity. These ideas overlap but are not interchangeable, and many organisations use more than one. For individuals, a personal VPN remains a separate, useful tool for protecting traffic on networks you do not control.

If you are looking for that kind of everyday protection on travel or public networks, you can compare fixed-length passes on the pricing page.