What Is ZTNA (Zero Trust Network Access)?

Zero Trust Network Access (ZTNA) is a way of giving users access to specific private applications, such as an internal web app, a file server or an admin console, without connecting them to the network those applications sit on. Access is granted by policy based on the user’s identity and whatever other context the product can check, such as device posture, before a connection to that one application is set up. Where a traditional remote-access VPN hands the user a path into the network, ZTNA hands them a path to an app.

At a glance

• ZTNA grants access per application, not per network, so a compromised account or device reaches less.
• Access is decided by policy using identity from your identity provider, usually with MFA; device posture checks and re-evaluation during a session vary by product and access mode, and agentless access may have little device evidence.
• Applications can be kept off the public internet: connectors near the apps make outbound connections, so many designs need no inbound firewall openings.
• It is commonly bought as a cloud service, alone or as part of SSE or SASE.
• It usually replaces remote-access VPN for user-to-app needs, not site-to-site VPNs.

What problem it solves

Remote-access VPNs were built to extend the office network to a laptop. Once connected, a user is often able to reach whole subnets, far more than their job needs. If that user’s password is phished or their device is infected, an attacker inherits the same broad reach and can use it for lateral movement toward servers and data. VPN concentrators also sit on the internet waiting for connections, which makes them a frequent target, and backhauling every remote user through one data center can make performance poor.

ZTNA narrows access to the specific apps each user or group is allowed to use, can check device health where an agent or integration provides it, and can hide applications from the internet altogether. Contractors, acquired teams and other third parties can be given one or two apps without ever touching the wider network.

How it works

1. Request. A user opens an application, either through an agent on their device or through a browser portal.
2. Verify. The ZTNA service confirms identity through the identity provider, usually with MFA, and, where the product and access mode support it, checks device posture such as operating system version, disk encryption and whether endpoint security is running; agentless access usually provides much less device information. Some products also weigh context such as location or risk signals.
3. Decide. Policy determines whether this user, in this context, may reach this app. Policies are written per application and group rather than as network address ranges.
4. Broker. If allowed, the service connects the user to that application only, typically through a connector installed near the app in the data center or cloud that makes an outbound connection to the service.
5. Re-check and log. Many products re-evaluate during the session, for example ending it if the device falls out of compliance, and decisions are logged for investigation and audit.

ZTNA comes in two main forms: cloud-delivered, where the provider runs the brokers in its points of presence, and self-hosted, where you run the gateway. Agent-based access generally supports more protocols; agentless browser access is easier for third parties but often limited to web applications.

When it matters for buyers

• When your remote-access VPN is up for renewal or hardware refresh. That is a natural point to compare ZTNA for user access.
• When contractors, vendors or acquired staff need access. Per-app access avoids putting outsiders on your network; ZTNA is a common way to give day-one access after an acquisition.
• When cyber insurers or auditors ask about remote access. Questions about MFA, exposed VPNs and least-privilege access often lead here.
• When you’re evaluating SSE or SASE. ZTNA is usually the private-app part of those bundles, so compare it alongside web and SaaS security.
• When moving apps over. Migration is app by app, and each old VPN path should be closed as its app moves.

Questions to ask vendors

• Which protocols do you support in agent and agentless modes, including SSH, RDP, database connections and UDP?
• Which device posture checks can you enforce, and which endpoint and device management tools do you integrate with?
• Where are your points of presence, and how will traffic from our users reach our data centers and cloud apps?
• Do you re-check sessions continuously, and what happens when a device falls out of compliance mid-session?
• How do we give contractors access on unmanaged devices, and what controls apply to them?
• What logs do we get, and can they be sent to our SIEM?
• What happens to user access if your service has an outage?

How it differs from VPN

A virtual private network (VPN) creates an encrypted tunnel that puts a user’s device, or a whole site, onto a private network; what the user can reach is then limited by routes and firewall rules on that network, which are often broad. ZTNA connects a user to individual applications based on identity and other available context, such as device posture, rather than placing the user on the network. Both encrypt traffic. VPN still fits site-to-site links and some legacy needs; ZTNA fits user-to-app access. Software-defined perimeter (SDP) describes largely the same idea as ZTNA and the terms are often used interchangeably. For how ZTNA fits a broader rollout, see our Security Service Edge (SSE) overview and why ZTNA suits the branch office.