Zero Trust Network Access (ZTNA): Scope, Limits and Gaps

The Zero Trust Network Access problem

Traditional remote access hands users broad network entry through a virtual private network (VPN) tunnel. Once inside, lateral movement is easy. A single compromised credential can reach far more than it should, expanding the attack surface well beyond what any one access request should allow.

NIST SP 800-207 defines Zero Trust as a shift away from implicit trust granted based on network location and the traditional network perimeter. Zero trust network access (ZTNA) is the architectural model that puts that principle into practice for application access. Instead of connecting users to the network, ZTNA connects verified users to specific applications and nothing more. Access is granted per session, based on identity, device posture, user authentication and context: the same identity and access management signals a single sign-on system already trusts, evaluated continuously instead of once at login. No implicit trust, no lateral movement by default.

The result is a much smaller blast radius. A compromised credential reaches one application, not the entire network segment, which keeps the attack surface small even as the environment grows.

ZTNA versus the legacy VPN model

Virtual private networks (VPNs) were built for a different era. They assume users need inside the network perimeter, grant them a tunnel and let them reach most things. That assumption breaks down in multi-cloud deployments, hybrid and heavily segmented environments where “inside” no longer means safe, and it complicates the user experience for a hybrid workforce that expects fast access from anywhere.

ZTNA replaces it with continuous verification and granular access control. Every access request is evaluated against policy: who is asking, from what device, under what conditions, and against what security posture. Approval is scoped to the application, not the subnet. This is what organizations moving to Zero Trust are actually replacing: trust based on network location, not just the VPN client.

The distinction matters. ZTNA vendors control the access broker layer and decide who reaches which application. They do not define or govern the underlying network paths, firewall policies or segmentation boundaries the rest of your network security depends on.

Limits of ZTNA coverage

ZTNA is precise by design. It controls application-level access for defined user populations, typically remote workers, contractors and cloud workloads, verifying user authentication, device posture and often multi-factor authentication through an identity-aware proxy or agent. That granular access control is the right scope for that problem.

But your network is more than those access paths. You have east-west traffic between workloads. You have firewall rules governing inter-segment communication. You have cloud security groups, routers, switches, SASE policies and microsegmentation controls, often across multiple vendors, all shaping what is actually reachable and what your security posture looks like day to day.

ZTNA does not model that environment. It does not tell you whether a firewall rule opens an unintended path between segments. It does not validate whether your segmentation policy still holds after last week’s change ticket. It does not show what a threat actor could reach through a different entry point if the access broker is bypassed entirely, and it does not extend granular access control to the application layer traffic moving between workloads.

For a full picture of how Zero Trust principles apply across segmentation and network policy, you need visibility into the underlying network fabric, not just the access layer.

The network segmentation gap

Segmentation is the structural enforcement of Zero Trust across the network. The principle is the same, limit reachability and contain lateral movement, but the scope is different. Segmentation governs how workloads, services and network zones communicate at the application layer and below, independent of whether any human user is involved.

Most organizations have segmentation policies on paper. Fewer can prove those policies are actually enforced and still aligned with intent across a multi-vendor environment. Networks change continuously. Rules drift. Cloud configurations update. Without continuous monitoring, none of that drift is visible until something breaks.

Every unreviewed change is a potential gap between your documented segmentation and what is actually reachable. ZTNA does not close that gap. That requires continuous security posture evaluation across the full network: across firewalls, cloud, SASE, routers, policy enforcement points and every other control point protecting your critical systems.

Tufin’s role alongside ZTNA

Tufin is not a ZTNA vendor. It does not broker application access or sit in the identity-verification path at the application layer. That is the job of ZTNA solutions.

Tufin governs what ZTNA depends on: the underlying network connectivity and segmentation policy across your multi-vendor, hybrid environment.

The foundation is the industry’s only Dynamic Network Connectivity Graph, an accurate digital twin of your network that models policies, paths, access controls, segmentation logic and security intent across every vendor in scope. The graph is not a snapshot. It reflects the network continuously.

On top of that graph, Tufin’s control plane gives your team one operational layer to manage and govern firewalls, cloud security groups, routers and switches, SASE and microsegmentation (the policy enforcement points ZTNA depends on) through one system, across many vendors.

What that means in practice:

• You can see what is actually reachable across the full environment, not just the access-broker layer.
• You can validate whether your segmentation policy holds after any change, before an attacker reaches critical systems.
• You can govern change across the environment with customer-proven network automation playbooks, so every modification is reviewed against policy and intent before it goes live, without degrading the user experience for legitimate access.
• Your vendor-agnostic agentic AI reasons across the whole network, not a single product, so that security decisions are grounded in complete connectivity context.

Your ZTNA controls who reaches which application. Tufin keeps the network those decisions depend on accurate, segmented and governed, closing the gap between access policy and network reality.

Conclusion

Zero trust network access (ZTNA) solves the right problem at the application access layer, but it does not govern the multi-vendor network fabric your environment runs on. Validating segmentation, modeling reachability and governing change across firewalls, cloud, SASE and routers requires a different layer of control, one that works across every technology in your stack, not just the access broker. Tufin’s Dynamic Network Connectivity Graph and control plane give your team that foundation: continuous posture, governed change and accurate visibility into what is reachable. To see how it works in your environment, get a demo.

Frequently asked questions

What is Zero Trust Network Access (ZTNA) and how does it differ from a VPN?

Zero trust network access (ZTNA) is an architecture that grants users access to specific applications based on verified identity, device posture and context, not broad network access through a tunnel — functioning as one layer of identity protection alongside device and network controls. Per NIST SP 800-207, ZTNA eliminates the implicit trust tied to network location that VPNs depend on. A VPN connects users to a network segment; ZTNA connects verified users to individual applications for remote work, scoped to exactly what is needed and nothing more.

A strategic guide to Zero Trust implementation covers how to apply these principles across your environment.

How does Zero Trust Network Access (ZTNA) relate to least-privilege access?

Zero trust network access (ZTNA) puts the principle of least privilege into practice at the application layer. Both principles reject standing, broad access, and ZTNA enforces this by evaluating each session request against identity and context before granting scoped application access. Least privilege is the broader design principle, applying to users, workloads, service accounts and network paths; ZTNA is one implementation model for user-to-application connectivity.

A deeper look at Zero Trust versus least privilege explores how the two approaches work together.

How does Zero Trust Network Access (ZTNA) fit into a SASE architecture?

Zero trust network access (ZTNA) is a central component of SASE (Secure Access Service Edge), which bundles network access and security into a cloud-delivered service. In a SASE model, ZTNA handles application access control as one layer of a broader security model, while other elements such as SWG, CASB and SD-WAN handle broader traffic policy and network connectivity. Knowing where ZTNA ends and the network begins matters when governing policy across a hybrid or multi-vendor environment.

A comparison of SASE and Zero Trust breaks down how these architectures relate and where your governance gaps are most likely to appear.