What ZTNA is, in one sentence
ZTNA — Zero Trust Network Access — is a security model where every request to reach a resource is authenticated and authorised explicitly, with no implicit trust granted by network location. "Zero trust" means exactly that: being inside the corporate network, or connected to the VPN, grants you nothing. Each access is verified on its own.
The problem ZTNA solves
The traditional security model is a perimeter: a firewall around the corporate network, a VPN to let remote users inside that perimeter. Once you're inside — physically in the office, or connected through the VPN — you're trusted. You can reach the file server, the internal admin panels, the databases, the printers, often everything.
The problem: a single compromised credential or device breaches the entire perimeter. A stolen VPN password gives an attacker the same broad access a legitimate employee has. Lateral movement — an attacker hopping from one internal system to the next — is easy once they're "inside," because inside means trusted.
ZTNA removes the concept of "inside." There is no perimeter to breach because there is no perimeter. Every request — from the office, from home, from a coffee shop — is authenticated and authorised the same way: explicitly, per-resource, every time.
How ZTNA works
A ZTNA deployment has three moving parts:
- The connector. A small software component runs next to each protected resource (an application, a server, a database). The connector establishes an outbound connection to the ZTNA control plane — crucially, the resource itself never has an inbound port open to the internet.
- The policy engine. The control plane evaluates every access request against policy: is this user, on this device, in this posture, authorised to reach this specific resource right now? Policies can incorporate identity (via SSO), device posture (is the OS patched, is disk encryption on), time, location, and more.
- The client. The user's device runs an agent (or, for web apps, just uses a browser) that brokers each request through the policy engine. The user never gets "network access" — they get authorised access to specific resources.
The result: the user reaches exactly the resources policy permits, and nothing else. There's no network to scan, no lateral movement, no implicit trust to exploit.
ZTNA and NIST 800-207
The authoritative reference for zero trust is NIST Special Publication 800-207, "Zero Trust Architecture," published 2020. It defines zero trust broadly — covering identity, devices, applications, data, and network — across seven tenets. The core principle: "never trust, always verify."
ZTNA is specifically the network access slice of NIST 800-207. A full zero trust architecture also addresses identity governance, device management, data classification, and workload security. ZTNA products handle the "how does a user reach a resource" question; they're a component of zero trust, not the whole of it.
For organisations being audited against a zero trust framework, this distinction matters: deploying a ZTNA product is necessary but not sufficient for "we have zero trust." It's one pillar of several.
ZTNA vs VPN vs mesh VPN
The three models, honestly compared:
| Aspect | Traditional VPN | Mesh VPN (Tailscale, MeshWG) | Pure ZTNA (Twingate, Zscaler) |
|---|---|---|---|
| Trust model | Implicit after connect | Per-flow ACL on a network | Per-resource, per-request |
| Unit of access | "on the network" | device-to-device, ACL-gated | user-to-resource |
| Lateral movement risk | High | Limited by ACLs | Minimal by design |
| Inbound ports on resources | VPN concentrator exposed | None (outbound handshake) | None (connector outbound) |
| Operational complexity | Low | Low-medium | Medium-high |
| Cost | Low | Low-medium | High ($7-15/user/month) |
| Best for | Simple single-site remote access | Multi-site / branch connectivity | Many internal apps, compliance mandate |
The honest middle ground: mesh VPN with strong ACL policy gives most of ZTNA's blast-radius reduction (no implicit broad trust, no exposed inbound ports, per-flow policy) without the operational cost of a per-resource connector model. For organisations that aren't large enterprises with a compliance mandate, that middle ground is often the right answer.
ZTNA products in 2026
- Twingate — gateway-based ZTNA, strong per-resource model, $10/user/month. See alternatives.
- Cloudflare Access — part of Cloudflare One / Zero Trust; free up to 50 users. See alternatives.
- Zscaler Private Access (ZPA) — enterprise-scale, the category's biggest vendor, priced for large organisations.
- Palo Alto Prisma Access — enterprise SASE platform with ZTNA as a component.
- Pomerium — open-source (Apache 2.0) gateway ZTNA, self-hostable.
- Mesh VPN with ACLs — Tailscale, NetBird, MeshWG implement per-flow policy that covers many of the same threats without a per-resource connector model.
Do you actually need ZTNA?
An honest decision framework:
- You probably need full ZTNA if: you're a mid-to-large enterprise, you have dozens of internal applications with differentiated access requirements, you're being audited against a zero trust mandate (compliance, government, regulated industry), or you have a workforce large enough that per-user device posture checks materially reduce risk.
- You probably need a good mesh VPN instead if: you're an SMB connecting a handful of sites, your "internal applications" are a file server and a few back-office systems, you want reliable connectivity with sensible policy, and ZTNA's $7-15/user/month pricing is hard to justify against the actual risk reduction for your size.
MeshWG is in the second category: a managed mesh VPN for SMB multi-branch, with per-flow policy (allow / deny by source, destination, protocol, port) that covers the practical blast-radius concerns without the operational weight of a per-resource ZTNA deployment. For genuine enterprise ZTNA needs, the pure-play products above are the right tools — and we'll say so.
Frequently asked questions
What is ZTNA in simple terms?
ZTNA (Zero Trust Network Access) is a security model where no user or device is trusted by default — every request to reach a resource is authenticated and authorised explicitly, regardless of whether the request comes from inside or outside the corporate network. It contrasts with the traditional VPN model, where connecting to the VPN places you 'on the network' and grants broad implicit access. ZTNA's principle: there is no inside; every access is verified per-request.
What does ZTNA stand for?
ZTNA stands for Zero Trust Network Access. It's a category of security product that implements the 'zero trust' principle for network access specifically. The broader 'zero trust' concept (covering identity, devices, data, and workloads, not just network access) is formalised in NIST Special Publication 800-207. ZTNA is the network-access slice of that model.
What is the difference between ZTNA and VPN?
A traditional VPN authenticates you once at connection time, then places you on a network where you can reach many resources — implicit trust after the initial check. ZTNA authenticates and authorises every request to every resource individually — there is no network to be 'on,' just per-resource access grants. Practical implication: if a VPN credential is stolen, the attacker reaches everything the VPN reaches; if a ZTNA credential is stolen, the attacker reaches only the specific resources that identity was explicitly granted. Modern mesh VPNs (Tailscale, MeshWG) sit between the two — network connectivity like a VPN, but with per-flow ACL policy that approaches ZTNA's granularity.
Is ZTNA better than a VPN?
For large enterprises with many internal applications and a compliance mandate, ZTNA's per-resource model is genuinely better — it limits blast radius and maps cleanly to audit frameworks. For small businesses connecting a few branch offices, a managed VPN with good policy controls is usually simpler, cheaper, and sufficient — the per-resource granularity of full ZTNA is operational overhead they don't need. 'Better' depends entirely on organisation size, compliance requirements, and the number of resources being protected.
What are examples of ZTNA products?
Pure-play ZTNA products include Twingate, Cloudflare Access (part of Cloudflare One / Zero Trust), Zscaler Private Access, Palo Alto Prisma Access, and Pomerium (open-source). Mesh VPN products like Tailscale and NetBird implement ZTNA-adjacent policy (per-flow ACLs) but are architecturally mesh networks rather than per-resource gateways. The distinction matters: pure ZTNA gates per-resource; mesh VPN with ACLs gates per-flow on a network.
Do small businesses need ZTNA?
Most small businesses need good access control, not necessarily full ZTNA. The pure-ZTNA model — every resource behind a connector, every request individually authorised — solves a problem that large enterprises with hundreds of internal applications have. A 5-branch retail business connecting its point-of-sale systems and back-office network needs reliable connectivity with sensible policy, which a managed mesh VPN delivers at a fraction of ZTNA pricing. Adopt full ZTNA when a compliance framework requires it or when you genuinely have many internal applications with differentiated access needs.
Next steps
If you're an SMB weighing ZTNA against a managed mesh VPN, start with the honest decision guide for your size — or try MeshWG's free tier (2 routers, no card).