Zero trust network access (ZTNA) grants a user access to a specific application after checking who they are and the state of their device, instead of placing them on the whole network the way a traditional VPN does. Each request is evaluated against policy, so a stolen login or compromised laptop reaches less.
What is the idea behind it?
NIST SP 800-207 defines zero trust architecture. Its abstract model has a subject that wants a resource, and access is granted through a policy decision point and a policy enforcement point. The decision looks at the subject, the device and context, and it is made per request instead of once at the network edge. ZTNA is the common name for products that apply this to remote access to applications.
How does it differ from a VPN?
A classic VPN authenticates you and then connects you to a network segment. Once inside, you can often reach anything routed there, so one compromised account can scan and move sideways.
With ZTNA, an application is published behind a broker. The user authenticates, the device is checked, policy is evaluated, and only then a connection to that one application is made. The application's address may not even be visible to the user.
What does a decision use?
- Identity: who the user is and how strongly they authenticated.
- Device: whether it is managed, patched and encrypted.
- Application: which one, and what action.
- Context: location, time and risk signals.
A constructed example
A contractor needs a reporting dashboard for a project. Under the VPN, they receive a network address on the internal range and can in principle reach file servers. Under ZTNA, they sign in with MFA from an unmanaged laptop and policy says the dashboard is allowed from unmanaged devices in browser only, with no download. The file servers do not exist for that session. Later, the contractor's laptop is infected. The attacker has a session to one dashboard, not a foothold in the network.
What are the limits?
- It protects the path to an application, not the application. A flawed web app is still flawed.
- Policy is only as good as the signals. Device checks done once at sign in miss changes during the session.
- Legacy apps that open connections back to clients, or use many dynamic ports, may need work.
- The broker is a critical component. Plan for its failure.
- The CISA Zero Trust Maturity Model reminds readers that zero trust is a journey across identity, devices, networks, applications and data, not one product.
What does a rollout usually run into?
Applications that were never documented. Users reach them by habit, and the first ZTNA policy breaks something nobody remembered. Run in monitor mode first, collect which applications people actually use, and write policy from that evidence. Plan for service accounts and scheduled jobs too, since they cannot answer an MFA prompt and need a different kind of identity.
Communicate with users before each cutover and keep the old path available until the new one is proven.
How to check or apply this
- List applications by who needs them and from what devices.
- Start with a few web applications and one group of users.
- Require MFA and set a device posture rule.
- Write one policy per application with a named owner.
- Test negative cases: unmanaged device, disabled user, unusual location.
- Send ZTNA logs to your monitoring and review denials.
- Keep a break glass path and test it.
- Retire the broad VPN rules only after each application works through ZTNA.
Quick check
Does ZTNA replace a VPN completely?
For many web and common protocol applications, yes. Some legacy or network level uses may still need a VPN or another approach during transition.
Is ZTNA the same as zero trust?
No. Zero trust is a strategy across the whole environment. ZTNA is one technology that supports its access piece.
Sources
Last reviewed: 18 October 2026.
