Support Library

ZTNA vs VPN for Remote Access

A remote-access VPN connects a device to the internal network and then relies on firewall rules to limit it. Zero Trust Network Access (ZTNA) never puts the device on the network: it checks the user and device for each application and connects them to that application only.

Author
CategoryZero Trust & Network Access
Length7 minute read
UpdatedOctober 24, 2026

The short answer

Both technologies give remote staff access to private applications. The difference is the unit of access. A VPN grants access to a network, and everything that network can reach becomes reachable from the user's laptop unless a firewall rule says otherwise. ZTNA grants access to an application, after a policy check of who the user is and what state their device is in, and everything else stays invisible.

  • VPN: authenticate once, get an internal IP address, then reach whatever the network allows.
  • ZTNA: ask for a specific application, pass identity and device checks, get a brokered connection to that application, and be checked again as conditions change.

ZTNA is the remote-access piece of a Zero Trust architecture. It matches the software-defined perimeter approach described in NIST SP 800-207.

What each one exposes

Remote-access VPN compared with Zero Trust Network Access On the left, a remote user connects to a VPN gateway that has a public IP and an open port. The device joins the internal network, and App A, App B, files, the admin console, a database and printers are all reachable, so an attacker on a compromised laptop can move between them. On the right, the remote user connects to a ZTNA broker, which checks the user, the device and policy. A connector inside the network makes an outbound-only connection to the broker. Only App A, which policy allows, is reachable; the other systems are hidden. Apps have no inbound port of their own and access is checked per session. Remote-access VPN Remote user Signs in once VPN gateway Public IP, open port Device gets an internal IP Internal network App A App B Files Admin Database Printers Every system is reachable The device is placed on the network Reach is as broad as the firewall rules The gateway is exposed to the internet Malware can move sideways Zero Trust Network Access Remote user Asks for App A ZTNA broker Checks user, device Internal network App B Files App A Admin Database Printers Connector outbound Only the allowed app Access to one app, decided by policy Checked per session, with device state Apps have no inbound port of their own Other systems stay hidden Remote-access VPN compared with Zero Trust Network Access With a VPN, the remote user connects to a gateway with a public IP and open port, the device joins the internal network, and every internal system is reachable, so malware can move sideways. With ZTNA, the user connects to a broker that checks the user and device, a connector inside the network makes an outbound-only connection, and only the allowed app is reachable while other systems stay hidden. Remote-access VPN Remote user Signs in once VPN gateway Public, open port Internal network: all reachable App A App B Files Admin Database Printers The device is placed on the network Reach is as broad as firewall rules The gateway is exposed to the internet Malware can move sideways Zero Trust Network Access Remote user Asks for App A ZTNA broker Checks user, device Connector dials out; one app shown App B Files App A Admin Database Printers Access to one app, decided by policy Checked per session, with device state Apps have no inbound port of their own Other systems stay hidden
With a VPN the internal network decides what a remote device can reach. With ZTNA a broker connects each user to the applications policy allows, through connectors that only make outbound connections.

The connector is what makes ZTNA "inside-out". It runs next to the applications and dials out to the broker, so the applications and the connector need no open inbound port. The broker is the only internet-facing part, and it is usually a cloud service run by the ZTNA vendor rather than an appliance in your data center.

Side by side

Remote-access VPNZTNA
Unit of accessA network or subnetOne application or service
When trust is decidedAt connection time, usually onceFor each application session, and again when conditions change
Device healthOptional posture check at connect, if configuredUsually part of every policy decision
Internet exposureA gateway with an open port, often in your own data centerThe vendor's broker; applications and connectors accept no inbound connections
Lateral movementPossible wherever firewall rules allowLimited to the applications the user is entitled to
ProtocolsAnything that runs over IPWeb apps always; other TCP and UDP apps depending on the product, usually with an agent
LoggingConnection and IP-level flowsPer user, per device, per application

How ZTNA connects a user

  1. The user opens an internal application, for example wiki.corp.example.com. For web apps this can go through an identity-aware proxy in the browser; for other apps an agent on the device intercepts the connection.
  2. The broker sends the user to the identity provider for single sign-on and MFA, and collects device signals from the agent or the device management platform: whether the device is managed, encrypted and up to date, and whether it has a valid device certificate.
  3. The policy engine decides whether this user, on this device, may reach this application now.
  4. If allowed, the broker stitches the user's connection to the outbound connection from the connector next to the application. The user never gets a route to the rest of the network.
  5. The session is re-evaluated. If the device falls out of compliance or the user's risk changes, the broker can end it.

Why organizations are moving off VPNs

Internet-facing VPN appliances have been among the most exploited systems in recent years. They sit on the internet, run complex code, and give an attacker who breaks in a position on the internal network. CISA's Known Exploited Vulnerabilities catalog lists many VPN and remote-access products, and in January 2024 CISA issued Emergency Directive 24-01 ordering federal agencies to act on actively exploited flaws in one widely used VPN product.

The bigger issue is design, not any single vendor. A VPN user who is phished, or whose laptop is infected, brings the attacker onto the network with them. ZTNA limits what that compromised session can reach to the applications that user was entitled to, and makes the device check part of every decision.

When a VPN still makes sense

  • Site-to-site links between offices and clouds are a different use case; IPsec tunnels remain normal there.
  • Network administration. Engineers who manage routers and switches often need broad network reach, though a separate, tightly controlled admin path is better than giving it to everyone.
  • Protocols a ZTNA product does not support, such as some voice, multicast or server-initiated traffic.
  • Small environments where a modern, patched VPN with MFA, device checks and narrow per-group access rules gets most of the benefit at lower cost.

Many organizations run both for a while, moving applications to ZTNA one at a time and shrinking the VPN to the cases that still need it.

A migration plan

  1. Inventory applications and users. VPN logs and firewall flows show who actually uses what.
  2. Start with web applications behind an identity-aware proxy. They are the easiest to move and usually the most used.
  3. Add private TCP applications with the agent, group by group, starting with the most sensitive systems.
  4. Require device signals once enrollment is complete, so unmanaged devices are limited to browser-only access or blocked.
  5. Shrink the VPN. Remove access groups as applications move, then keep the VPN only for the exceptions, or retire it.

DNS considerations

Remote access depends heavily on name resolution. ZTNA agents usually resolve internal names such as wiki.corp.example.com through the broker or a private resolver, so internal names do not need to be published in public DNS. If you use a split view instead, the trade-offs in Split-Brain DNS apply.

During a migration it is common to find internal hostnames that were published publicly years ago, or that leaked through public TLS certificates. Scan your domain with Domain Visualizer to see what its public records reveal, and use Certificate Transparency to find names that appeared in certificates. Remove anything that points at systems that are now meant to be reachable only through the broker, and watch for dangling records left behind by retired VPN gateways.

FAQ

Is ZTNA a replacement for a VPN?

For user access to applications, usually yes, and that is the most common reason to adopt it. VPNs remain normal for site-to-site links and are sometimes kept for network administration or protocols a ZTNA product does not support.

Does ZTNA work for applications that are not websites?

Many products support any TCP application, and some support UDP, through an agent installed on the device. Agentless access through a browser is usually limited to web applications and sometimes browser-based remote desktop or SSH.

What is the difference between ZTNA, SSE and SASE?

ZTNA is private application access. Security Service Edge (SSE) is an industry term for a cloud service that bundles ZTNA with a secure web gateway and a cloud access security broker. SASE adds wide-area networking, such as SD-WAN, to SSE.

Is ZTNA safe if the broker is a cloud service?

The broker becomes a critical dependency, so evaluate the vendor's security, availability and data handling as you would any identity provider. The benefit is that your own applications no longer accept inbound connections from the internet, which removes a large attack surface you previously had to defend yourself.

Sources and further reading

Related support articles

Zero Trust Networking ExplainedCertificate-Based AuthenticationSplit-Brain DNSCertificate Transparency for DNS DiscoveryCommon TCP and UDP Ports Explained802.1X Explained