Zero trust network access (ZTNA) is a remote and internal access model that connects a verified user on a verified device to one specific application at a time, instead of placing that user on a trusted network segment. In network security, ZTNA is the practical implementation of the zero trust principle never trust, always verify: no request is trusted because of where it comes from, and every session is authorized against identity, device posture and policy.
ZTNA is often described as the successor to the traditional remote access VPN. A VPN extends the network to the user; ZTNA brokers access to applications and keeps the network itself invisible to anyone who has not been authorized.
How zero trust network access works
A ZTNA system separates the control plane, which decides whether access is allowed, from the data plane, which carries the traffic. The central component is a policy decision point that evaluates each request, and the enforcement happens in a broker or gateway that stitches the user’s session to the application only after approval.
A typical session follows a fixed sequence. The user authenticates with an identity provider, usually with multi-factor authentication. The ZTNA client or browser session reports device signals such as operating system version, disk encryption and endpoint protection status. The policy engine combines these with context, for example location and time, and grants access to a named application, not a subnet. Applications sit behind outbound-only connectors, so they need no inbound firewall ports and do not appear in internet scans.
Authorization is not a one-time event. Mature ZTNA products re-evaluate sessions continuously and can terminate access when the device falls out of compliance or the risk score of the user changes during the session.
Building blocks of a ZTNA deployment
ZTNA relies on several components that must work together. Weakness in any of them, especially identity, undermines the whole model. The table lists the core parts and their roles.
| Component | Role | Typical inputs or outputs |
|---|---|---|
| Identity provider | Authenticates users and issues assertions | SAML or OpenID Connect, MFA results |
| Device posture check | Verifies that the endpoint meets requirements | Patch level, encryption, EDR status |
| Policy engine | Decides allow, deny or step-up authentication | User groups, device state, context |
| Access broker | Connects the approved session to the application | Encrypted tunnel or reverse proxy |
| App connector | Publishes private apps without inbound ports | Outbound TLS to the broker |
| Logging and analytics | Records each access decision | Per-application audit trail |
Because every decision is logged per application, ZTNA also gives security teams much finer visibility than VPN logs, which often show only that a user connected to the network.
Agent-based and agentless ZTNA
ZTNA comes in two delivery models that suit different users and applications. Agent-based ZTNA installs a client on the device, which can check posture and tunnel almost any protocol. Agentless ZTNA works through the browser via a reverse proxy, which is convenient for contractors and unmanaged devices but limited mostly to web applications.
| Aspect | Agent-based | Agentless |
|---|---|---|
| Supported applications | Web, SSH, RDP, databases, custom TCP or UDP | Mainly HTTPS web applications |
| Device posture visibility | Detailed from the local agent | Limited to browser signals |
| Typical users | Employees on managed devices | Contractors, partners, personal devices |
| Deployment effort | Client rollout and updates | Minimal on the endpoint side |
ZTNA can also be cloud-delivered as part of a SASE service or self-hosted on the organization’s own gateways. Cloud delivery simplifies scaling, while self-hosting keeps traffic and keys under direct control.
ZTNA compared with VPN and related controls
ZTNA is easiest to understand next to the controls it complements or replaces. The decisive difference is the scope of what a user can reach after authentication.
| Control | Scope of access | Trust basis | Main limitation |
|---|---|---|---|
| Remote access VPN | Whole network segments | Successful login to the VPN | Broad lateral movement after compromise |
| ZTNA | Individual applications | Identity, device and context per request | Requires an application inventory and policies |
| Network access control | Admission to the local network | 802.1X and device checks at connection | Little control after admission |
| Microsegmentation | Workload-to-workload traffic | Policies between servers | Covers east-west, not user access |
| SASE | Combined network and security service | Includes ZTNA as one component | Broader scope, larger migration |
These controls are not mutually exclusive. Many organizations use ZTNA for user-to-application access, microsegmentation inside the data center and network access control on campus ports, which together implement zero trust at several layers.
Adopting ZTNA and avoiding common mistakes
A successful ZTNA rollout starts with an inventory of applications and who needs them, because policies are written per application. Most organizations migrate in phases, beginning with web applications and contractors and keeping the VPN for legacy protocols until they are covered.
- Overly broad policies, such as granting access to an entire IP range, recreate the VPN problem under a new name.
- Weak identity, without phishing-resistant MFA, lets an attacker pass every subsequent check.
- Ignoring device posture turns ZTNA into little more than an authenticated proxy.
- Leaving old inbound ports open after migration keeps the original attack surface alive.
- Unsupported legacy protocols may need separate handling or remain on a restricted VPN.
ZTNA also introduces new dependencies: the identity provider and the broker become critical services, so their availability and latency need the same attention as the applications behind them.
The idea in brief
Zero trust network access lets people use only the specific applications they need, and only after checking who they are and whether their device is safe. It does not give them a key to the whole building.
A VPN is like a badge that opens the front door, after which you can wander every corridor. ZTNA is more like an escort who checks your badge and takes you straight to one room, and checks again if anything about you changes.
A practical scenario
An engineering firm with 400 employees and about 60 external contractors replaces its remote access VPN for contractors with ZTNA. Each contractor group receives access only to its project management web application and one file share, published through outbound connectors in the data center. Access requires MFA and, for company laptops, current patches and active disk encryption.
A few months later, a contractor’s password is stolen in a phishing attack. The attacker passes the password check but fails the MFA step and would have reached only two applications anyway, not the internal network. The security team sees the denied attempts in the per-application logs, resets the credentials the same day and confirms that no other systems were exposed.