VPN still has a role, but its broad-access model becomes harder to defend as contractor access, hybrid work, SaaS adoption and identity-led attacks increase. ZTNA changes the access decision from "can this user reach the network?" to "should this user, on this device, reach this application right now?"
The value depends on what sits underneath: centralised identity, Conditional Access, device posture, application inventory, connector placement and clear ownership of access policy. Without that foundation, ZTNA can reproduce the same broad-access decisions through a more modern broker.
ZTNA's value depends on what sits underneath it. Three questions frame the decision: what ZTNA actually is, whether it replaces VPN, and where deployments go wrong.
Identity-aware, per-application access: the user authenticates against an identity provider, the access decision evaluates user, device, location and risk signals, and a broker establishes a session to the specific application that user is allowed to reach.
Sometimes, eventually. VPN and ZTNA usually coexist for an extended period, and the coexistence is the design rather than the failure. ZTNA replaces the broad-access pattern, not necessarily the VPN overnight.
Five recurring failures, all upstream of the broker rather than inside it: identity hygiene, policies lifted from VPN rules, incomplete application inventory, connector placement, and identity-provider availability.
Access is granted to the application, not the network. The difference is not the cryptography — it is the scope and persistence of access, and the trust boundary.
The product layer of ZTNA is mature — the major platform vendors all ship credible offerings. When ZTNA deployments underperform in mid-market environments, the cause is rarely the broker. It is one of five upstream issues the new architecture exposes more visibly than the old one did.
The honest readiness conversation matters because ZTNA is not free, not instant, and not always the priority. Some organisations are ready now and would benefit substantially. Some are better served by closing identity and Conditional Access gaps first, and revisiting ZTNA in twelve months.
Hybrid-work load keeps forcing capacity additions, and the spend recurs.
Third-party access is hard to revoke and inconsistently audited across engagements.
Microsoft 365 and SaaS line-of-business systems are reached through backhauls that hurt performance.
Entra ID with MFA and Conditional Access is in place and operating consistently.
Branches and remote users need the same policy regardless of where they connect from.
The organisation wants to limit lateral movement after a credential compromise.
Not enforced through Conditional Access — ZTNA inherits the weakness rather than fixing it.
Policy design starts from guesses rather than the actual estate.
Personal or unmanaged devices in production use mean device-posture signals will be inaccurate from day one.
Stale accounts, unclear admin privilege, no recurring access reviews.
A wholesale "switch off VPN, switch on ZTNA" rollout is rare and rarely the right design. The successful pattern is phased: remote access first, where identity is the prerequisite and Conditional Access is the policy engine; contractor and third-party access second, often where ZTNA produces the clearest commercial value because contractor access is where VPN's broad-access model is most exposed; and internal lateral movement last — the most ambitious phase, requiring complete application inventory, mature policy design and operational maturity.
The phases run in a particular order because each one exposes readiness for the next.
ZTNA is a strong architectural choice when the identity layer is already well operated and the application estate is understood. The practical question is not "can ZTNA replace VPN?" but which access patterns should move first, what identity controls need to be trusted, which applications are in scope, and what remains on VPN for now. In many environments, VPN and ZTNA coexist while the access model is progressively tightened.
When the identity layer is well operated, the architecture delivers; when it is not, ZTNA inherits the weakness through a more modern access layer.
Treat ZTNA as an identity decision
Close identity and Conditional Access gaps first
Know the application estate
Move access patterns in phases
Commercially, this sits inside the SASE & Zero Trust Access pathway. ZTNA is not a competitor to SASE — it is one of the cloud-delivered security services inside the broader SASE architecture, alongside secure web gateway, cloud access security broker and firewall-as-a-service, and buying ZTNA does not commit an organisation to a full SASE platform. ZTNA readiness is assessed as part of the broader secure-access architecture: identity posture, Conditional Access, application dependencies, contractor access, device trust, connector placement and what remains on VPN during transition.
Review identity, device trust and application access before choosing a ZTNA platform. Identity and application readiness assessed before any broker or platform decision.
Book a ZTNA Readiness Review