What is ZTNA?

Zero Trust Network Access (ZTNA) is a security framework that grants access to individual applications only after continuously verifying user identity, device posture, and context – rather than granting broad network access based on where a connection originates, as a traditional VPN does. ZTNA is the private-application-access pillar of SASE and SSE.

Key takeaways

• ZTNA grants per-application access instead of broad network access like a VPN.
• Access decisions rely on identity, device posture, and context, checked continuously.
• ZTNA replaces implicit trust from network location with explicit verification.
• It is the private-access pillar of SASE and Security Service Edge architectures.
• Versa delivers ZTNA through Secure Private Access (VSPA), managed in Concerto.

On this page: Why it matters · How it works · Types · ZTNA & Versa · FAQ

Why is ZTNA important?

Traditional VPNs place a connecting user onto the corporate network itself, trusting anyone with valid credentials to reach broad swaths of internal infrastructure. That model fits a world where employees and applications sat behind one perimeter. It breaks down once applications move to the cloud and users connect from anywhere, because a single compromised credential or device can move laterally across a flat network – the pattern behind many breaches.

ZTNA matters because it removes that blast radius. Instead of placing a user on the network, it connects them directly to one authorized application at a time, after checking identity, device, and context. Applications stay invisible to anyone not explicitly authorized to reach them, shrinking the attack surface and blocking the reconnaissance and lateral movement flat VPN access enables. Trust is also evaluated continuously, not granted once at login and assumed for the rest of the session.

What is ZTNA?

ZTNA brokers every application request through a policy decision point rather than routing traffic onto a shared network. When a user requests a private application, the broker evaluates identity (via LDAP, SAML, or another identity provider), device posture (patch level, managed-endpoint status, security software), and context (location, time, network type) before creating a direct, encrypted, per-application connection. The application’s network address is never exposed to the device, and no other applications become reachable through that session.

This evaluation is continuous, not a one-time gate: if a device’s posture changes mid-session – a security agent stops reporting, for example – access can be revoked immediately. ZTNA implementations generally fall into two connection models: agent-based, where client software on the endpoint initiates the connection, and clientless, where the application is reverse-proxied through a browser instead.

Types of ZTNA

ZTNA deployments split along how the connection is initiated. Endpoint-initiated (agent-based) ZTNA runs a lightweight client that authenticates and establishes an outbound, per-application tunnel to the broker; it supports the widest range of application types, including non-web protocols, and can report device posture directly. Service-initiated (clientless) ZTNA proxies access through a browser, with a connector on the application side initiating the outbound path – useful for contractors or unmanaged devices, though generally limited to web applications.

A third pattern, on-premises ZTNA, extends the same identity- and context-based enforcement to users physically on a campus or branch network, applying least-privilege, per-application access even when the device is plugged into the corporate LAN.

ZTNA & Versa

Versa delivers ZTNA through Versa Secure Private Access (VSPA), the remote-access component of Versa SSE within Versa Unified SASE. VSPA connects users to private applications hosted on-premises or in the public cloud by enforcing identity-based access instead of the static access lists a VPN concentrator uses, supporting both the Versa SASE Client and clientless connectivity. Sessions move through three stages – registration (LDAP, SAML, RADIUS, or Versa Directory authentication, with MFA), connection (gateway selection and trusted-network detection), and policy enforcement (ZTNA plus SWG-style filtering) – detailed in Concerto SASE end-to-end configuration.

Organizations moving off legacy VPNs can follow Versa’s VPN to ZTNA migration guide, which covers inventorying VPN use cases, migrating one user group at a time, and scaling into production. Versa also extends ZTNA on-premises through Versa Zero Trust – Premises, with ongoing configuration guidance in new articles as the VSPA feature set expands.

Frequently asked questions

What is the difference between ZTNA and a VPN?

A VPN places a connecting device onto the broader corporate network, granting implicit access to anything reachable there. ZTNA instead brokers a direct, per-application connection after verifying identity, device posture, and context – the application stays invisible to everyone else, sharply limiting lateral movement.

Do I need client software to use ZTNA?

It depends on the deployment model. Agent-based ZTNA installs a lightweight client that handles authentication and per-application tunneling, supporting the widest range of application types. Clientless ZTNA proxies access through a browser instead, which suits unmanaged or BYOD devices but generally covers web applications only.

How does ZTNA verify trust continuously?

Rather than granting access once at login, ZTNA re-evaluates signals such as device posture, session behavior, and context throughout the connection. If a signal changes – for example, a device’s security agent stops reporting – the broker can revoke access immediately instead of waiting for the next authentication event.

Is ZTNA part of SASE?

Yes. ZTNA is one of the core services converged into SASE and Security Service Edge architectures, alongside secure web gateway, cloud access security broker, and data loss prevention, all enforced under one policy engine close to the user rather than deployed as separate point products.

Does ZTNA eliminate the need for a firewall?

No. ZTNA governs access to specific private applications; it doesn’t replace broader protections like next-generation firewalling, intrusion prevention, or internet-bound threat inspection. In practice, ZTNA is deployed alongside those controls as one layer of a converged SASE or SSE stack.

More on ZTNA

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about ZTNA, these are worth looking at next.