NEW Self-serve signup is live. Free for 2 machines, forever. ₹349/machine/month after. See pricing →
/ compare · ztna vs vpn

ZTNA vs VPN: the honest difference and which you need

ZTNA authorises every request per-resource. A VPN grants broad network access after one login. This guide covers the real difference, the mesh-VPN middle ground that absorbed most of ZTNA's benefits, and how to choose by organisation size.

The short answer

ZTNA wins for enterprise remote access. VPN wins for site-to-site connectivity. A modern mesh VPN is the middle ground that covers most organisations below enterprise scale.

The "ZTNA vs VPN" framing is usually presented as a clean replacement story — ZTNA is new and good, VPN is old and bad. The honest version is more useful: they're optimised for different jobs, and the most relevant option for many organisations is neither a legacy VPN nor a pure ZTNA product but the mesh VPN that sits between them.

The core difference: implicit vs explicit trust

A traditional VPN works on implicit trust. You authenticate once — username, password, maybe a second factor — and you're "on the network." From there you can reach whatever the network routing and firewall rules allow, often a lot. The check happens at the door; once you're through, you're trusted.

ZTNA works on explicit, per-request trust. There is no door and no "inside." Every request to every resource is authenticated and authorised on its own: is this identity, on this device, in this posture, allowed to reach this specific resource right now? A stolen credential exposes only what that identity was explicitly granted — not the whole network.

The single sentence that captures it: a VPN answers "are you allowed on the network?" once; ZTNA answers "are you allowed to do this specific thing?" every time.

Side-by-side comparison

AspectTraditional VPNZTNA
Trust modelImplicit after one loginExplicit, per-request
Unit of access"on the network"user → specific resource
Stolen-credential blast radiusEverything the VPN reachesOnly granted resources
Lateral movementEasy once insideMinimal by design
Inbound ports on resourcesVPN concentrator exposedNone (connector outbound)
Site-to-site connectivityYes (core use case)No (not the model)
Device-posture checksRareNative
Operational complexityLowMedium-high
CostLow$7-15/user/month
Best fitSite-to-site; simple remote accessEnterprise remote access; compliance

The thing ZTNA can't do

The most common mistake in "ZTNA vs VPN" decisions: assuming ZTNA replaces a VPN entirely. It doesn't replace the site-to-site job.

Site-to-site connectivity means linking two offices' networks so devices at one site can reach devices at the other — POS terminals reaching head-office systems, a branch's computers reaching a shared file server, IP cameras at multiple sites feeding one monitoring station. This is network connectivity between places, not user access to applications.

ZTNA has no model for this. ZTNA connects users to resources. It does not connect networks to networks. An organisation that rips out its VPN and deploys only ZTNA discovers its branch offices can no longer talk to each other. Site-to-site stays a VPN job — specifically, a modern mesh VPN job.

The mesh-VPN middle ground

Modern mesh VPNs — Tailscale, NetBird, MeshWG — occupy the space between legacy VPN and pure ZTNA, and for most organisations they're the right answer. They're architecturally networks, so they handle site-to-site and device-to-device connectivity that ZTNA can't. But they've absorbed most of ZTNA's security improvements:

  • No exposed inbound ports. The WireGuard handshake originates outbound from each node. Resources are never directly reachable from the internet — the same property ZTNA's connector model provides.
  • Per-flow ACL policy. Instead of "on the network = reach everything," mesh VPNs enforce allow/deny rules per source, destination, protocol, and port. Not per-resource like pure ZTNA, but a long way from a legacy VPN's implicit broad trust.
  • Identity integration. Mesh VPNs tie device enrolment to SSO, so access maps to identities, not just to whoever holds a static key.
  • Small attack surface. No bulky VPN concentrator; WireGuard's ~4,000-line codebase versus a legacy VPN appliance.

What they don't do: gate per-resource with device-posture evaluation on every request. That residual gap is what pure ZTNA still owns — and it matters at enterprise scale and under compliance mandates. Below that, the mesh-VPN middle ground delivers the right balance.

How to choose by size

Your situationChoose
Connecting branch offices / multi-site networksMesh VPN (ZTNA can't do site-to-site)
Small business, a few sites + small remote teamManaged mesh VPN with ACLs (MeshWG)
Mid-market, many internal apps, growing contractor baseEvaluate pure ZTNA for the user-access layer; keep mesh VPN for site-to-site
Enterprise with a zero-trust compliance mandatePure ZTNA, mandated regardless of preference
Fully remote, no offices, no site-to-site needMesh VPN (per-user) or ZTNA — both viable; cost and app-count decide

Frequently asked questions

What is the difference between ZTNA and VPN?

A traditional VPN authenticates a user once at connection time and then places them on a network with broad implicit access — being connected means being trusted. ZTNA (Zero Trust Network Access) authorises every request to every resource individually — there is no network to be 'on,' only explicit per-resource grants. The security consequence: a stolen VPN credential exposes everything the VPN reaches; a stolen ZTNA credential exposes only the specific resources that identity was granted.

Is ZTNA replacing VPN?

ZTNA is replacing the traditional VPN in large enterprises, particularly for remote-access use cases, because the per-resource model materially limits breach blast radius. But VPNs are not going away — site-to-site connectivity (linking two offices' networks) is still a VPN job, not a ZTNA job, and modern mesh VPNs have absorbed many of ZTNA's security benefits (no exposed ports, per-flow policy) while remaining far simpler and cheaper. For small and mid-sized organisations, a good mesh VPN often remains the better fit.

Is ZTNA more secure than a VPN?

For the remote-access use case, yes — ZTNA's per-request authorisation removes the implicit broad trust that makes a stolen VPN credential so dangerous, and removes lateral movement as an easy attacker technique. But 'more secure' depends on the comparison. A traditional VPN concentrator with an exposed inbound port is meaningfully less secure than ZTNA. A modern mesh VPN with outbound-only handshakes and per-flow ACLs closes most of the same gaps; the residual difference (per-resource vs per-flow granularity) matters at enterprise scale and matters less for a small business.

Can ZTNA do site-to-site connectivity?

Generally no — and this is the most common misunderstanding. ZTNA is built for user-to-resource access: a person reaching a specific application. It is not designed to connect two offices' networks so their devices interoperate. Site-to-site connectivity remains a VPN job. Organisations that need both — branch connectivity and per-resource user access — typically run a mesh VPN for the site-to-site layer and add ZTNA for the per-resource user-access layer, or use a mesh VPN with strong ACLs that covers enough of both.

Do I need ZTNA or a VPN for my small business?

Most small businesses need a VPN — specifically a modern managed mesh VPN — not full ZTNA. The typical SMB need is connecting branch offices and giving a small team remote access, which is a connectivity problem a mesh VPN solves directly and cheaply. Full ZTNA's per-resource model earns its cost at enterprise scale or under a compliance mandate. A managed mesh VPN with per-flow ACL policy gives a small business most of ZTNA's blast-radius benefit at per-router rather than per-user pricing.

What is the middle ground between ZTNA and VPN?

Modern mesh VPNs — Tailscale, NetBird, MeshWG — are the middle ground. Architecturally they're networks (like a VPN), so they handle site-to-site and device-to-device connectivity. But they add per-flow ACL policy, outbound-only handshakes (no exposed inbound ports), and identity integration — properties that pull them toward ZTNA's security posture. They don't gate per-resource the way pure ZTNA does, but for most organisations below enterprise scale, the mesh-VPN-with-ACLs middle ground delivers the right balance of security, simplicity, and cost.