How Zero Trust Network Access Works
Zero Trust Network Access (ZTNA) is an architectural approach for controlling how users and devices reach applications and other protected resources.
The core idea is straightforward:
Access should be explicitly authorized to the resource being requested instead of being inferred from network location or from the fact that a user has already connected to a private network.
ZTNA is therefore not one protocol, one product architecture, or one deployment model. Different vendors implement it differently.
The ZTNA Decision Flow
A useful logical model is:
The details vary by product, but these responsibilities capture the central ZTNA pattern.
1. Identify the Requester
Before access can be authorized, the system needs to know who—or what—is requesting it.
For a human user, identity may come from:
- an OIDC identity provider
- an enterprise directory
- local identity records
- other authentication systems
Identity is not the same as authorization. Successfully proving who a user is should not automatically grant access to every private resource.
2. Identify the Device
A user can have multiple endpoints, and those endpoints do not necessarily have the same security state.
A ZTNA system may track the device separately from the user through:
- device enrollment
- certificates or device keys
- managed-device identifiers
- MDM signals
- EDR signals
- operating-system or posture checks
The result is a policy decision that can distinguish between, for example, an enrolled corporate laptop and an unknown endpoint belonging to the same user.
3. Collect Context
Identity and device are important, but policy can include additional context:
- requested resource
- role or group
- device posture
- location
- time
- access duration
- previous approval
- required step-up authentication
A product does not need every possible signal to qualify as ZTNA. What matters is that access is explicit and policy-driven rather than automatically granted because the endpoint is “inside.”
4. Make a Policy Decision
The policy engine answers a question such as:
Is this user, on this device, allowed to access this resource under the current conditions?
That decision should be narrow enough to express the intended access relationship directly.
For example:
- developers → development servers
- finance → accounting application
- vendor → one maintenance portal until Friday
- administrator → production console only after approval
This is different from simply admitting an endpoint to a network and relying on downstream controls to narrow access later.
5. Enforce the Decision
ZTNA requires an enforcement point between the requester and the resource.
Common models include:
Client and Gateway / Connector
An endpoint client establishes secure connectivity through a gateway, connector, or similar enforcement component.
This model works well for protocols that need network-level connectivity.
Clientless Proxy
For browser-based applications, an HTTP/HTTPS proxy can authenticate and authorize the user without installing tunnel software on the endpoint.
The proxy becomes the enforcement point between the browser and the protected application.
Peer-Oriented Networking
Some products use coordinated peer-to-peer networking, with central policy distributing the permissions required for peers to communicate.
These are all valid architectural approaches if resource access remains explicitly authorized.
6. Limit Access Scope
The purpose of ZTNA is not merely encryption.
Encrypted transport protects traffic in transit. ZTNA also needs to answer what the authenticated requester is allowed to reach.
A narrow resource policy can reduce unnecessary exposure and lateral movement compared with granting broad network reachability.
This does not remove the need for network segmentation or host-level controls. Those remain useful defense-in-depth measures.
7. Reevaluate Access
Conditions can change after access starts.
For example:
- a temporary access window expires
- an account is disabled
- a device loses acceptable posture
- a role or group assignment changes
- an administrator revokes approval
A ZTNA architecture should be able to react to relevant policy changes instead of assuming that a successful initial connection remains valid indefinitely.
8. Record What Happened
Access decisions are also security events.
Useful records can include:
- identity
- device
- requested resource
- authentication event
- policy result
- access time
- revocation or denial
Those records can support investigations, access reviews, troubleshooting, and integration with SIEM workflows.
ZTNA Is Not Just MFA
Multi-factor authentication strengthens authentication, but authentication alone does not define resource authorization.
A user can pass MFA and still be unauthorized for a particular application.
ZTNA combines authentication with resource policy and other context.
ZTNA Is Not Just a VPN Protocol
WireGuard, IPsec, and TLS can all provide secure transport in different architectures.
A secure tunnel does not know an employee's business role, whether a device is compliant, whether access was approved for 30 minutes, or whether the requested application is outside that user's policy.
Those are authorization concerns handled by the surrounding access system.
Learn how WireGuard fits into ZTNA
Control Plane vs Data Plane
Understanding this distinction helps when comparing ZTNA products.
Control Plane
The control plane typically handles responsibilities such as:
- configuration
- identities and groups
- resource definitions
- policy
- key or authorization coordination
- administrative workflows
Data Plane
The data plane carries or proxies the actual application traffic.
Some vendors operate both layers as a cloud service. Others operate the control plane in the cloud while customers deploy connectors. Some products allow the whole access platform to be self-hosted or operated without a vendor cloud dependency.
The phrase “ZTNA” by itself does not tell you which model a product uses.
Compare self-hosted and cloud-delivered ZTNA
Common ZTNA Deployment Models
Cloud-Delivered
The vendor operates the control service and often provides globally distributed enforcement infrastructure.
Vendor Control Plane + Customer Connectors
The vendor operates policy/coordination services while the customer deploys connectors or gateways near private applications.
Self-Hosted
The customer or MSP operates the core management and enforcement infrastructure.
Standalone / Disconnected
The access system can continue operating without a mandatory vendor-hosted control service and may be deployed permanently inside an isolated environment.
Each model has different operational, availability, data-control, and Internet-dependency tradeoffs.
Where ZTXGate Fits
ZTXGate uses a customer- or MSP-operated access platform.
Its managed access path uses WireGuard-based transport, while licensed clientless access can proxy supported HTTP/HTTPS applications. Identity, device, resource, posture, time, approval state, and additional authentication requirements can contribute to access policy.
ZTXGate can operate standalone without a mandatory CoreZT-hosted cloud control plane, including in air-gapped environments. Connected deployments can optionally use CoreZT-operated ZTXHub for centralized license and software-update management.
Explore the ZTXGate architecture · Explore ZTXGate