What is zero trust network access (ZTNA)?

As the name suggests, ZTNA brings the principles of zero trust architecture to remote network access. Following zero trust’s “never trust, always verify” logic, ZTNA assumes that every user, device and interaction presents a potential security risk. Nothing—and no one—is trusted by default. Every access and data request is evaluated against established security policies before it reaches an application, regardless of where the request originates,

Traditional perimeter-based remote access tools, such as virtual private networks (VPNs), typically authenticate once, place the user or device inside the network and permit wide-ranging movement thereafter. Network location stands in for trust. Just being on a corporate local area network (LAN) or VPN implies permission.

On the other hand, ZTNA technologies do not give authenticated users access to the whole network. Instead, they create one-to-one, least-privilege connections between users and the specific applications and data they’re requesting. ZTNA also continuously monitors and validates users and devices throughout their connections, which can help catch insider threats and malicious actors pretending to be legitimate users.

In a ZTNA environment, IT and cybersecurity teams create rules that say, “user A, on device with security posture B, in context C, can access application D under E and F conditions.” If—and only if—a user adheres to the policy, they are permitted to access the network. The ZTNA platform then establishes a brokered, encrypted connection to the specific internal resources the device is allowed to use, while keeping all other resources hidden and inaccessible.

As a result, ZTNA enables enterprises to shrink their attack surfaces by limiting the lateral movement of users and devices while helping authorized users securely connect to enterprise resources. ZTNA also helps make access control models portable across on-premises data centers, cloud environments and software as a service (SaaS) applications.  

ZTNA tools and configurations can vary widely between enterprises, but most designs employ three fundamental zero trust principles.

ZTNA treats every single access request as untrusted until it is explicitly evaluated against policy. The evaluation process goes far beyond asking “did the user log in?” It also asks questions such as “given who this user is—the device state, location, time and recent behavior—is this specific request to this specific application allowed right now?”

To achieve this explicit verification, ZTNA uses strong authentication methods, such as multifactor authentication (MFA). It also uses continuous session checks, feeding context signals (device posture, risk score, geolocation) into a policy engine for every access request—not just at login time.

The principle of least privilege states that users should have only the minimum necessary access to do their jobs, scoped to the narrowest possible level.

In a least-privilege environment, the default answer to any access request is “no.” “Yes” answers apply only to a small, well-defined set of app-level permissions.

For example, instead of “device is on 10.0.0.0/16, let them roam,” a least-privilege access policy might say “this device can reach the human resources web application over HTTPS, but cannot access the HR database directly, cannot use Secure Shell protocol (SSH) to access anything and can only perform HR staff roles inside the app.”

Least-privileged access is enforced through fine-grained access policies tied to identity and resource classification. It is often deployed alongside just-in-time access (which grants users and devices access only when they actually need it and only for a short time), role-based access controls and periodic access reviews, so privileged access does not accumulate over time.

“Assume breach” means designing policies and controls as if an attacker is already on the network. So, ZTNA systems focus on limiting movement (and the impact of that movement) within the network, not just preventing initial entry.

ZTNA frameworks implement mandatory encryption on all data paths, continuous monitoring of device and user behavior and dynamic access policies that can downgrade or revoke access when something looks off.

Network segmentation is another key aspect of ZTNA and zero trust more broadly. Even if an app or identity is compromised, segmentation prevents the issue from turning into a full-network compromise.

From an enterprise perspective, ZTNA helps secure sprawling, distributed IT environments. However, it is just one building block of a zero trust architecture, not the entire story.

ZTNA addresses the question “how do users and workloads securely reach applications?” It does not replace the need for endpoint protection, internal microsegmentation between workloads and data protection controls.

In a mature zero trust architecture, an enterprise might have ZTNA governing application access while microsegmentation controls east-west traffic between services. Endpoint security tools watch device behavior, and data security tools help ensure that sensitive information is protected and used appropriately. Together, these layers assume that compromise is possible at every step and work to limit what an attacker can do if any one control fails.

ZTNA solutions—the platforms responsible for enforcing security policies and brokering remote connections—tend to share a set of foundational architectural traits. 

With ZTNA, access decisions are made at the application layer (layer 7) of the Open Systems Interconnection (OSI) networking model, instead of at the raw network layer (layer 3). That means policies talk in terms of “this web app at this URL” or “this API with this path,” not “10.0.12.0/24 on port 443.”

Because the control point understands applications and URLs, it can grant access to just one specific app instead of to the entire network. It can even grant access to specific functions inside the app—for example, “allow user A to access the reports page but not the admin page.” 

“Dark” applications are internal applications that do not show up as open listening endpoints to anyone who is not explicitly authorized. These applications are effectively invisible because ZTNA gateways will not even acknowledge them unless the request comes from an authenticated, authorized identity for that specific app.

According to the IBM X-Force 2026 Threat Intelligence Index, enterprises saw a 44% year-over-year increase in the exploitation of public-facing applications last year. Dark applications help teams keep their applications hidden from the public internet, creating a powerful microsegmentation effect. Even if the underlying network is flat, each app or small group of apps is exposed only through narrow, app-specific access paths.

If an application programming interface (API) endpoint or account is compromised, the attacker cannot scan the network and laterally move across internal IP space. The compromised identity can see only the small set of apps that ZTNA policies allow.

ZTNA typically uses a “central brain, local muscles” approach to network and application security. A central controller or policy engine defines all the rules: who can access which application, under what conditions, with which device posture and so on.

Then, these policies are enforced by distributed components. Connectors in a data center or virtual private cloud (VPC), agents on API endpoints, and gateways at the edge of the network can all handle policy enforcement in their respective environments.

This way, policies stay consistent and auditable, and security enforcement happens as close to the data traffic as possible. This separation of policies and enforcement helps zero trust security models adapt to hybrid and multicloud environments.

ZTNA relies heavily on identity and security telemetry rather than simple IP-based rules.

ZTNA services integrate with identity providers (IdPs)—systems that store user identities, authenticate users and communicate the details to applications—to gather rich identity data (user, group, role and sometimes workload identity).

They also frequently integrate with device management systems, endpoint detection and response tools, and security analytics platforms such as security information and event management (SIEM) systems.  

These integrations enable ZTNA policy engines to account for device health, known threats, behavioral anomalies and risk scores when deciding whether to allow a request, request extra authentication or block it outright.

When a device or user makes an access request through a ZTNA system, the request usually follows the same general path.

Say a billing microservice needs to call an internal payments gateway API to charge customers’ credit cards for monthly subscriptions. The microservice runs in a Kubernetes cluster and has a workload identity that is already known to the organization’s IdP.

When the billing pod starts, a sidecar or agent fetches a short-lived token from the IdP, representing the billing service’s identity and attributes. Attributes might include the service name (“billing-service”), environment (production) and allowed roles (“payments_caller”).

The microservice needs to charge a customer’s card, so it sends an HTTPS request to the payments API’s URL. Instead of sending traffic directly to the payments service IP address, the agent routes the request through a ZTNA connector or gateway that fronts the payments API. The request includes the billing service’s token in an HTTP header, so the ZTNA layer can see which identity is calling.

A ZTNA controller receives the request and validates the token with the IdP, checking the signature, expiration time and audience. It then evaluates the established security policy. The policy might say, “only the ‘billing-service’ in the prod cluster, with role ‘payments_caller,’ can call the payments gateway API, and only on the ‘charge’ and ‘refund’ paths, not ‘admin’ or ‘config.’”

If the identity in the token does not match these conditions or is flagged as risky or compromised, the ZTNA policy denies the request to prevent unauthorized access. The request never reaches the payments API.

If the policy allows the request, the ZTNA connector establishes a secure, authenticated connection from the billing microservice to the payments API—and only for the ‘charge’ and ‘refund’ paths. The billing microservice sees only the payments API. All other private apps remain dark.

Even though the IdP “knows” the billing microservice, ZTNA tools keep checking token validity and policy compliance on subsequent requests to the payments API. If security tools later mark the billing workload as compromised, or if its role or permissions are changed or revoked in the IdP, subsequent requests are denied immediately.

ZTNA solutions and architectures can be grouped into five broad categories.

Agent-based ZTNA installs a small software agent on each endpoint device (laptop, mobile phone, desktop). The agent continuously reports identity, device posture and context to the ZTNA controller, which uses this information to decide whether to grant access.

Agents typically intercept traffic destined for protected applications and establish an encrypted tunnel directly to a ZTNA gateway or cloud edge, so the user never connects to the internal network directly.

Agent-based approaches are useful for situations where IT and security teams fully manage all the endpoints because they can enforce strict device health checks and granular per-app policies before permitting any connection. They are less suitable for working with contractors, unmanaged bring-your-own-device (BYOD) setups or partner devices where teams can’t install or manage security agents.  

Server-based ZTNA—also called agentless ZTNA—avoids installing software on endpoints and instead uses a browser or standard client protocols (such as HTTPS) to mediate access. Users authenticate through a web portal or IdP. The ZTNA service proxies traffic to internal web applications, often over outbound-only connections from a connector inside the network.

Agentless ZTNA uses HTTP- and HTTPS-driven, browser-only setups, so it’s well-suited for granting external users and unmanaged devices access to web and SaaS applications. However, it can see traffic only through the browser proxy and doesn’t live on the endpoint.  Server-based ZTNA struggles with non-web applications and cannot provide the same depth of insights or level of control as an agent-based system.

Gateway-based ZTNA uses on-premises or virtual gateways (called appliances) that sit in front of applications or network segments to manage access control policies. Users connect to a ZTNA gateway (often though an agent) that applies identity- and context-aware policies and then proxies traffic to the protected application.

This model can be attractive for enterprises with many on-premises or legacy applications because teams can deploy gateways close to existing infrastructure and keep traffic local. However, if remote users are geographically distributed, concentrating access enforcement in a few data centers can introduce latency and complexity, especially compared to cloud-delivered ZTNA solutions.

Cloud-delivered ZTNA runs the policy engine and enforcement points in a provider’s cloud environment, often at many points of presence located across the globe. User traffic, whether from an agent or browser, is routed to the nearest cloud edge. There, identity, device posture and context are checked before a per-application connection is established to the target resource.

Cloud-based ZTNA solutions can easily scale to accommodate distributed and remote workforces because users connect to nearby cloud edges instead of accessing resources through a central data center. They also align with secure access service edge (SASE) architectures, where ZTNA is integrated with other cloud-delivered services—such as software-defined wide area networks (SD-WAN) and next-generation firewalls (NGFW)—to centralize policy and security checks.

These integrations help ensure that teams don’t end up with fragmented, conflicting controls in different parts of the network

Some ZTNA vendors offer a type of ZTNA that focuses explicitly on secure application access rather than general network access. With this model, each application (or small group of applications) is treated as its own microperimeter. Devices are dynamically connected only to the specific app that they request and don’t interact with the network layer at all.

This approach greatly limits lateral movement because compromised accounts or devices can reach only a narrow set of resources.

Instead of IP addresses or subnets, policies are often expressed in terms that align with how the business thinks (people, roles, apps). Polices are therefore easier to adjust when users move teams, apps move to the cloud or IP addressing changes.

ZTNAs and VPNs are both used to establish secure remote access, but they handle access in different ways. VPNs authenticate a user once and then grant them broad, network-level access. ZTNAs authenticate every access request and grant users access to only a set of specific resources.

ZTNA and VPNs both represent an evolution of software-defined perimeters (SDPs), software-based network boundaries that become visible and reachable only to authenticated, authorized users and devices.

VPNs have a classic “castle-and-moat” network perimeter model. When a user authenticates to a VPN, they are placed logically “inside” the corporate network and trusted for the duration of their session.

VPNs use point-to-point communication, routing all user traffic through a centralized VPN gateway. This dynamic can lead to backhauling (sending traffic from a remote location back to a central site for processing instead of sending it directly to the destination) and add latency, especially for cloud apps.

Furthermore, because VPNs place users on the internal network, a compromised VPN account can allow lateral movement to other systems, dramatically expanding the attack surface. Networks become more vulnerable to malware and data breaches.

ZTNA reduces this risk by exposing only the necessary applications behind a default-deny model. Attackers have fewer paths and less visibility, even if they do gain credentials. Many ZTNA solutions are also cloud-native, so they can route users to the closest cloud point of presence, which sends traffic straight to the application.

Both ZTNA and secure access service edge (SASE) help improve on traditional perimeter security approaches. The core difference is where they sit in the IT environment: ZTNA is primarily an access control tool, whereas SASE is primarily a secure networking tool.

ZTNA brokers connections between authenticated identities and individual apps or services, but it does not redesign how the overall network routes traffic. It simply decides whether to allow a particular user‑to‑app connection and then establishes a secure path for that connection.

SASE is a cloud-native architecture that combines networking with multiple different security services, which collectively form the security service edge (SSE), to deliver a single, globally distributed security platform. SASE functions span routing, traffic steering and connectivity along with multiple inline threat prevention services, such as secure web gateways, cloud access security brokers (CASB), firewall as a service (FWaaS) and ZTNA.

In a sense, SASE is a full edge-networking and security fabric, while ZTNA is a specialized capability living inside or alongside that architecture.

From a security model standpoint, ZTNA implements zero trust specifically for application access, while SASE extends zero trust principles across all edges and traffic types. ZTNA policies create granular access controls, enabling app- and user-level least-privilege controls. SASE emphasizes global, consistent policies across locations, users and traffic, with per-app refinements enforced through the ZTNA component.

• Better visibility and control. ZTNA gives enterprises granular, policy-based control over who can access which app, from which device and under what conditions.
  
  
• Reduced attack surface. ZTNA allows users to see only specific applications, which makes it harder for attackers to scan or move through an environment, even if a credential is compromised.
  
  
• Greater scalability and cloud readiness. Because policies follow users and apps instead of being fixed at the network level, ZTNA architectures scale more easily with cloud and SaaS adoption than traditional, perimeter-based security.
  
  
• Improved user experience. ZTNA improves the end user experience by making access faster, more seamless and less clunky than VPNs.
  
  
• Better support for hybrid and remote work. ZTNA provides secure, direct-to-application access for remote users and hybrid workforces without backhauling all the network traffic through a central VPN.