ZTNA implementation: rollout phases, network prerequisites and failure points

The ZTNA implementation sequence

Zero Trust network access (ZTNA) replaces broad network-level remote access with per-application access. A broker’s access control engine verifies identity and device posture on every request, then connects the user to one application over a secure connection. Nothing else on the network is visible to that session. ZTNA is sometimes described as a software-defined perimeter: the perimeter moves with the user instead of sitting at a fixed network edge. The model follows the trust principles defined in NIST SP 800-207: trust nothing by location, verify every request, grant least privilege, and revisit trust assumptions continuously as risk changes, not just at login. 

ZTNA differs from earlier security models such as legacy Network Access Control (NAC) in one important way: NAC grants a device broad admission to the network once it passes inspection, while ZTNA grants access to a single application and nothing else. That narrower grant is what makes Zero Trust Access a smaller attack surface than either a VPN or NAC on its own.

A ZTNA implementation is the project of moving remote access from network-level virtual private network (VPN) connectivity to per-application access, then retiring what it replaced. It typically runs in five phases.

Application inventory. List every application remote users reach today, including the ones that only show up in VPN logs and firewall rule hit counts. Shadow applications missed at this stage become outages at cutover.

Access mapping. For each application, document who needs it, from where and under what device conditions. That evidence already sits in your firewall rule bases, cloud security groups, route tables and existing access control policies, alongside the data flows already crossing your network. NIST SP 1800-35, builds its 19 example deployments, drawn from both public- and private-sector entities, on exactly this discovery work.

Identity and access foundations. ZTNA depends on identity as much as it depends on the network. Device posture checks and multi-factor authentication only work if your identity providers, whether Active Directory, Entra ID or another platform, hand the broker consistent, current data. Device posture checks often rely on certificates issued through your public key infrastructure, so confirm that infrastructure is current before you lean on it for access decisions. 

Weak identity management upstream produces broken access control policies downstream, no matter how well the broker is configured. An identity protection solution can harden authentication, but it doesn’t tell you what a session can reach once access is granted; that’s still a network question. Confirm your identity security posture and consolidate identity and access platforms before migration begins, not after.

Broker deployment. Stand up the ZTNA service, self-hosted or delivered as part of a Secure Access Service Edge (SASE) cloud security service, and place connectors in front of application groups. Two access architectures cover most deployments: an inline proxy architecture that routes traffic through the vendor’s cloud, and gateway-based ZTNA solutions that place a connector in front of each application and dial out to meet it. 

Both act as policy enforcement points; the difference is which side initiates the connection. A mature Zero Trust Architecture typically ends up with several of these enforcement points, one per broker or SASE edge, so they need to agree with each other, not just with the network behind them. Zero Trust is the security model; the SASE architecture is what delivers it at scale.

Phased migration. Move applications in cohorts, starting with low-risk web applications. Run ZTNA alongside the VPN, encryption tunnels and all, only as long as the migration requires, so user experience doesn’t regress mid-project. A cohort is done when its VPN group policy is disabled and the firewall rules that served it are removed, not when the last user stops using it.

VPN decommissioning. Retire the concentrators, the encryption tunnels they terminate, and the firewall rules that served them. This is the phase teams skip most often. It is also the one attackers count on.

Network prerequisites for a ZTNA rollout

ZTNA governs user-to-application access. It decides whether a user gets a connection to a given application. What happens after that connection lands is decided by your network: firewall rules, cloud security groups and segmentation zones. No single security solution covers both halves of that equation; the broker and the network behind it are governed separately, and both must hold. 

If the workload behind the broker can reach the rest of the data center, one compromised session still turns into lateral movement. The broker cannot fix that; Zero Trust network access only reduces exposure when the network behind it is under control.

Four prerequisites decide whether the rollout holds.

Flow knowledge. You cannot write least-privilege access policy without knowing who can talk to whom right now. Teams that guess produce one of two outcomes: broken applications or permissive policies that replicate the VPN they were replacing.

Segmentation that holds. Network segmentation limits what a compromised session can reach. Policies work best when they’re granular and context-based, weighing device, identity and location together rather than IP address alone. Validate that the boundaries between zones (production and development, regulated and unregulated, cloud and on-premises) actually hold before you migrate applications behind the broker, not after an incident proves they do not. Treat that check as an ongoing validation process, not a one-time step before cutover.

Identity you can trust. The identity foundations from the access-mapping phase have to keep holding after go-live. If identity management drifts, so does every access decision downstream of it.

Clean, current firewall policy. Rules that survive the migration are paths the broker never sees. Firewalls remain policy enforcement points even after the broker goes live, so a stale rule base undermines Zero Trust security as much as a misconfigured broker does. Before you cut over, know which rules still carry live traffic, which were built to serve the VPN and which predate the project.

ZTNA implementation failure points

The network is entering the agentic era. Changes land at machine speed, and attackers use AI to find drift faster than review cycles close it. Four patterns account for most stalled or hollow rollouts.

The parallel VPN that never gets retired. Concentrators kept “temporarily” for legacy applications stay reachable for years. The same Verizon report found only about 54% of edge device vulnerabilities were fully remediated during the year, at a median of 32 days. An aging concentrator behind a forgotten firewall rule is precisely the target class attackers exploit in these cyber attacks.

Allow-all policy migration. Porting VPN group rules straight into the broker preserves the old exposure under a new name. Per-application least privilege is the point of the project. Losing it at migration means you replaced the access method and carried the old exposure across unchanged.

Policy drift across vendors. The broker policy is one layer. Firewalls, cloud platforms, routers and SASE each carry their own rule bases, each changing daily. A rule added under incident pressure in one layer can open a path the broker never sees. Manual review cannot keep pace, and intrusion detection systems that perform deep, ongoing inspection of what’s already inside the network won’t catch a permissive rule the broker never routes through. A quarterly cycle will not find that path first.

No continuous validation. A point-in-time audit at go-live proves posture on that day. Zero Trust assumes the environment changes constantly, so posture has to be evaluated on an ongoing basis. Configuration analyzers and risk-based scoring engines catch drift by re-checking every policy change against the intended baseline, not just the ones a ticket flags. 

Feed the results to security operations alongside your existing security information and event management and endpoint security tools, and current threat intelligence turns a quarterly audit into continuous monitoring. Behavioral analytics that flag anomalous user behavior add another layer, but they still depend on clean policy data underneath. A rollout without continuous validation starts drifting out of policy the day it goes live.

Tufin’s approach to ZTNA implementation

Tufin is not a ZTNA broker and does not sit in the user-to-application path. As a policy management solution, Tufin governs the network security policy a ZTNA implementation depends on: firewall rules, cloud security groups, SASE policy and microsegmentation workloads, across the vendors in your hybrid network. That’s the network access layer a mature Zero Trust Architecture still needs, no matter which broker sits in front of it.

Tufin is built on the industry’s only Dynamic Network Connectivity Graph, a continuously updated model of every device, policy, route and connection across your environment. That graph spans on-premises firewalls and the security groups behind a multi-cloud environment, so multicloud configurations across AWS, Azure and GCP get the same scrutiny as cloud workloads running cloud-based applications your teams deployed directly. 

The graph answers the questions each rollout phase raises: who can talk to whom today (access mapping), what is actually reachable behind the broker (segmentation validation) and which VPN-era rules are now dead (decommissioning). Instead of assembling that picture from exports and interviews, you query a live model.

Tufin’s control plane sits on top of the graph and governs change across every vendor through one policy management solution. When a firewall or security group change is proposed during migration, it is checked against your Zero Trust policy baseline before it is pushed, not discovered as a violation at the next audit. Tufin governs the firewall, cloud and SASE policy behind any broker, whether that’s Zscaler, Fortinet, or a Next-Generation Firewalls, and pulls posture context from tools like CrowdStrike, Qualys, and Rapid7, amongst others. 

Agentic AI runs across the same graph, accelerating path analysis, rule cleanup and policy review at machine speed. That combination, one graph, one control plane and AI that reasons across every vendor rather than inside one product, is why Tufin is the first and only solution on the market for Multi-Vendor Agentic Network Security. The division of labor after go-live is clear: the broker controls user-to-application access, while Tufin proves the network behind it still matches the Zero Trust security you signed off on.

See how Tufin customers validate segmentation and clean up firewall policy before a ZTNA cutover in their own environments: read Tufin case studies.

Conclusion

A ZTNA implementation succeeds or fails on the network underneath it. The broker handles identity-verified, per-application access. Flow knowledge, clean firewall policy, validated segmentation and continuously evaluated posture determine whether that access actually reduces exposure or just relocates it. 

Tufin’s Dynamic Network Connectivity Graph is the data foundation that shows what your network actually allows behind the broker. The control plane on top of it governs firewall, cloud, SASE, and microsegmentation change against that picture, before, during and after the rollout. If you want to see what is actually reachable behind your broker today, get a demo and see how Tufin works across your environment.

Frequently asked questions

How long does a ZTNA implementation take?

Plan in quarters, not weeks. Application inventory and access mapping usually take longer than broker deployment because most organizations do not know their real application traffic. Migration then proceeds in cohorts, with the VPN retired only after the last application moves. Accurate connectivity data at the start compresses the two longest phases, because mapping becomes a query against current state instead of a manual reconstruction.

Learn how a strategic Zero Trust implementation plan sequences the work.

What are the most common ZTNA implementation challenges?

Three recur: unknown application traffic flows, segmentation boundaries that were never validated and policy drift across firewalls, cloud and SASE. All three trace back to the same gap: teams cannot say who can talk to whom across a multi-vendor environment, so policy design becomes guesswork. Knowing what is actually reachable before you write broker policy makes every later phase cheaper.

See three common Zero Trust implementation challenges and how teams solve them.

Does a ZTNA implementation replace network segmentation?

No. ZTNA controls how users reach applications; segmentation controls what those applications and workloads can reach next. Without enforced boundaries behind the broker, one compromised session can still move laterally toward critical assets. The two controls only work as a pair.

Learn how microsegmentation limits lateral movement behind your ZTNA broker.