ZTNA: What It Replaces, What It Doesn't
Zero trust network access is a better VPN, but it is not a firewall replacement. Here is the clean mental model.
Zero trust network access gets marketed as a firewall replacement, a VPN killer, and occasionally a full security platform. None of those descriptions are accurate. ZTNA solves one well-defined problem extremely well: granting remote users access to specific applications without putting them on the corporate network. Once you understand that boundary, the rest of the architecture decisions get much easier.
This primer gives you the mental model, explains precisely what ZTNA does and does not replace, walks through how it works at a functional level, and helps you decide when it makes sense to adopt it. We will skip the vendor marketing and focus on what matters operationally.
The Core Mental Model
A VPN connects you to a network. ZTNA connects you to a specific application, per session, only after verifying both your identity and your device’s security posture. With a VPN, once you authenticate, you are effectively “inside” and implicitly trusted to reach whatever the network allows. With ZTNA, there is no inside. Every request is brokered and authorized individually, and access to one application grants no visibility into anything else.
That distinction is not semantic. It is the architectural property that eliminates an entire class of attacker behavior: lateral movement. When there is no network to be “on,” a compromised session cannot be pivoted into a reconnaissance sweep of internal systems, a ransomware detonation across file shares, or a credential-stuffing run against adjacent services.
What ZTNA Replaces
Legacy VPN Remote Access
Traditional IPsec and SSL VPNs were designed for an era when the corporate perimeter was a real boundary and remote workers were a small exception to the rule. They authenticate a user once and then hand them a network-layer address inside the corporate subnet. ZTNA replaces this model directly: instead of a tunnel to the network, the user gets brokered, per-app sessions that expire and re-authorize continuously.
The Flat, Implicitly-Trusted Corporate Network
Most organizations that grew up before zero trust have network architectures built on implicit trust, once you are on the LAN or the VPN, your traffic is treated as legitimate. ZTNA enforces least-privilege access at the application layer, which means even legitimate users can only reach the applications they are authorized for, regardless of which network segment they are on. This is a direct replacement for the trust model, not just the technology.
Broad Lateral Movement Opportunity
When an attacker obtains VPN credentials, through phishing, credential stuffing, or buying them on a breach forum, they step into the same flat network your employees use. With ZTNA, a compromised set of credentials grants access only to the applications that user is authorized for, and only from devices that pass posture checks. There is no network to sweep, no adjacent subnets to probe.
Exposed VPN Concentrators as an Attack Surface
VPN concentrators are internet-facing infrastructure. They have CVEs. They get scanned, probed, and exploited, the 2021 Pulse Secure and Fortinet vulnerabilities were mass-exploited before patches could be applied at scale. ZTNA brokers expose no listening port on the internet; the connector reaches out to the broker, not the other way around. There is nothing for an attacker to discover or exploit from outside.
What ZTNA Does NOT Replace
This is the section that vendor materials skip. Be skeptical of any ZTNA pitch that does not address these boundaries directly.
Your Next-Generation Firewall
ZTNA does not inspect traffic, enforce egress policy, filter DNS, block inbound threats, or control east-west traffic between servers and workloads. Your NGFW still handles all of those functions. Removing your firewall because you deployed ZTNA would leave your internal network and cloud workloads without segmentation, inbound protection, or traffic inspection. The two technologies address different threat vectors and operate at different layers, they are complementary, not competitive.
A Secure Web Gateway or CASB
ZTNA governs access from users to your private applications. A secure web gateway (SWG) governs access from users to the public internet, filtering malicious sites, enforcing acceptable use policy, and inspecting web traffic for threats. A Cloud Access Security Broker (CASB) governs access to SaaS applications and enforces data controls: who can download what from Salesforce, whether sensitive files can be shared externally from SharePoint, and so on. ZTNA does none of those things. If you replace your web proxy with ZTNA, your users browse the internet without controls.
Endpoint Protection
ZTNA can query device posture, whether a device has an active EDR agent, whether the OS is patched, whether disk encryption is enabled, but it cannot remediate a compromised endpoint, detect behavioral anomalies, or respond to active threats on the device. EDR is still required. ZTNA and EDR actually work well together: the posture signal from your EDR platform feeds into the ZTNA policy engine to gate access dynamically. A device flagged by EDR can have its ZTNA sessions revoked automatically.
A Complete SASE Architecture
Secure Access Service Edge (SASE) is an architecture, not a product. ZTNA is one component of SASE, specifically the private-application access component. A complete SASE stack also includes a secure web gateway, a CASB, cloud-delivered firewall-as-a-service (FWaaS), and SD-WAN. Deploying ZTNA alone gives you the remote access piece. The other SASE components handle internet access security, SaaS data governance, and branch-to-branch connectivity. Vendors often conflate these; the architecture does not.
The complementary layers principle
ZTNA, your NGFW, and EDR are complementary security layers, not substitutes for each other. ZTNA removes lateral movement opportunity. The firewall enforces traffic policy and inspects for threats at the network boundary. EDR detects and responds to threats on the endpoint. Replacing your firewall with ZTNA is like replacing a deadbolt with a video doorbell: you have added a useful layer but removed a necessary one.
How ZTNA Works
The implementation details vary by vendor, but the functional components are consistent across the major platforms:
Identity Provider Integration
ZTNA connects to your identity provider, Entra ID, Okta, Google Workspace, to authenticate users and pull group memberships. Access policy is defined in terms of identity attributes: this group gets access to this application, that contractor gets access only to the ticketing system, and so on. Multi-factor authentication is enforced at the broker, not as an optional layer.
Device Posture Check
Before a session is granted, the ZTNA client queries the device for posture signals: EDR agent status, OS patch level, disk encryption state, screen lock policy, firewall status. Devices that fail posture requirements are denied access or redirected to a remediation flow. This is what makes the “never trust, always verify” principle operational rather than aspirational.
The Broker and Connector Model
The application never exposes a port to the internet. Instead, a lightweight connector, installed in your data center or cloud environment, establishes an outbound connection to the ZTNA broker (typically a cloud service). When an authorized user requests access, the broker stitches together the user-side session and the connector-side session. The application sees only internal traffic from the connector. Attackers scanning the internet see nothing.
Least-Privilege Per-App Access
Access is granted at the application level, not the network level. A user authorized for the ERP application can reach the ERP application. They cannot reach the internal wiki, the development environment, or anything else, even if those systems sit on the same subnet. Policy is enforced per resource, per session.
Continuous Evaluation
Unlike a VPN, which authenticates once and maintains a persistent tunnel, ZTNA evaluates sessions continuously. A device that passes posture at login but is subsequently flagged by the EDR can have its session terminated mid-stream. A user who logs out of the identity provider loses their ZTNA sessions immediately. Access is dynamic, not static.
VPN vs. ZTNA: A Direct Comparison
| Dimension | VPN | ZTNA |
|---|---|---|
| Access scope | Network-level; user reaches any system the network allows | Application-level; user reaches only authorized apps |
| Trust model | Implicit trust after authentication; inside = trusted | No implicit trust; every session brokered and authorized |
| Lateral movement | High risk; compromised credentials yield broad network access | Minimal; no network to traverse, no adjacent systems visible |
| Attack surface | Internet-facing concentrator with CVE exposure | No listening port exposed; connector reaches out to broker |
| Device posture | Rarely enforced; most VPNs authenticate the user, not the device | Posture check required before each session is granted |
| User experience | Full tunnel; often slow, route conflicts, split-tunnel complexity | Per-app, transparent; no tunnel overhead for unrelated traffic |
When to Adopt ZTNA
ZTNA makes operational sense in several specific scenarios. If none of these apply, your existing VPN may be adequate with proper hardening.
Remote and Hybrid Workforce
If a significant portion of your workforce connects remotely on a daily basis, the VPN model creates both performance and security drag. ZTNA eliminates split-tunnel complexity, removes the concentrator as a target, and gives you per-app policy without full-network exposure. For organizations that went fully remote and never rationalized the architecture, ZTNA is often the cleanest path forward.
Contractors and Third-Party Access
Giving a contractor or vendor VPN access has always been uncomfortable: they end up with more access than they need, and revoking it cleanly is operationally messy. ZTNA was practically designed for this use case, define a policy that grants access to exactly the systems the contractor needs, enforce posture on their device, and set a session expiry. No lingering access, no lateral movement risk.
Mergers and Acquisitions
Integrating two network environments after an acquisition is a substantial project with real security risk during the transition. ZTNA lets you grant the acquired company’s employees access to the applications they need across the network boundary without merging the networks, establishing complex firewall rules, or accepting the trust implications of site-to-site VPN between environments with different security postures.
Reducing VPN Attack Surface Before It Becomes a Headline
If you are running an end-of-life or unpatched VPN concentrator, or if you have had a VPN-related incident, replacing it with ZTNA is a straightforward risk reduction. The concentrator is the target; removing it from the internet removes the exposure.
Moving Toward a Zero Trust Architecture
ZTNA is the natural starting point for a broader zero trust program. It produces immediate, measurable risk reduction, has clear ROI in reduced lateral movement risk, and builds the identity and device posture infrastructure that the rest of a zero trust architecture depends on. Organizations that start with ZTNA are better positioned to layer in microsegmentation, SWG, CASB, and FWaaS over time.
Working with us on ZTNA
We design and deploy ZTNA as part of a layered architecture that keeps your firewall, network, and identity layers working together, not as a replacement for any of them. Our engineers handle the connector deployment, routing, and NGFW integration, then wire in the identity provider, EDR posture signals, and continuous monitoring. The result is a ZTNA rollout that reduces your attack surface without creating new gaps. Talk to our team about what a ZTNA or SASE transition looks like for your environment.