ZTNA versus VPN: migrate the access journey, not just the tunnel

A contractor opening one browser application and an engineer repairing a legacy server do not need the same access. Yet both can appear in a VPN replacement programme as a single migration percentage. For the security architect, that simplification hides the difficult work: preserving required connectivity while reducing what each identity can reach.

Zero trust network access, or ZTNA, is worth evaluating where access can be scoped to particular applications and informed by identity or device policy. Retaining a VPN can be a defensible decision for a bounded workflow that the proposed replacement cannot yet support. The commercial test is whether the new design reduces exposure at an acceptable operating cost, including client deployment, application changes and support.

Decide what the connection should permit

NIST’s zero-trust architecture rejects implicit trust based solely on network location or asset ownership and focuses protection on resources. That is an architectural principle, not a product category. Buying a ZTNA-labelled service does not establish that each user has only the access their work requires.

Begin with the successful business action: submit a supplier invoice, administer a server or retrieve a design file. Identify the application destinations, protocols, authentication and device conditions needed to complete it. Then identify what should remain inaccessible. “The user connected successfully” is only half an acceptance test.

The existing VPN configuration deserves the same scrutiny. Inspect its actual routes, authentication and access controls rather than assuming it permits the whole network. Conversely, inspect the new service’s default reachability rather than assuming every route is restricted because the product uses zero-trust language.

This matters in practice. Cloudflare’s non-HTTP application documentation says devices enrolled in an organisation can, by default, access any private route; restrictions require Access policies or Gateway firewall rules. The same page distinguishes client-based access from clientless methods, including browser-rendered terminals. It notes that command logging is not supported for those clientless methods. Those details can change the choice for a privileged support workflow even when both routes establish a connection.

Use three journeys to expose the difficult decisions

The following hypothetical migration illustrates how different requirements produce different answers.

Journey	Candidate design	Evidence needed before migration
A contractor uses one invoice portal from a device the enterprise does not manage.	Application-specific access with a supported browser route.	The full invoice workflow works; other applications remain inaccessible; the required data restrictions work on that device.
An employee uses an installed client that contacts several internal services.	Client-based private application access with explicit destinations.	Authentication, DNS, secondary connections and ordinary long-running work all succeed under the intended policy.
An engineer administers a legacy system during an outage.	A tested privileged access route, with a restricted VPN exception if necessary.	Required protocols and audit evidence are available; access can be recovered when an ordinary dependency fails.

Do not approve the contractor route purely because the login page works. Test file uploads and downloads, embedded content, logout and access after the contract ends. Decide whether an unmanaged device is acceptable for the data involved. If it is not, adding a new access broker does not remove that restriction; the device or delivery model must change.

For the installed client, capture its actual destinations during a representative task. A front-end connection may succeed while a secondary service fails. Resolve that dependency explicitly rather than broadening policy to a large network range merely to clear support tickets.

Microsoft Entra Private Access documents both Quick Access, which groups private destinations, and per-app access for more granular treatment. Its described remote-user route uses the Global Secure Access Client and a private network connector. For an architect, those are deployment and availability dependencies to budget and operate. A product demonstration on a prepared laptop does not establish that the contractor’s device or every operating environment can use the same route.

Test what happens when access should end

A migration test should include an unauthorised user, a user removed from an allowed group and a device that no longer meets policy. Observe both new connections and sessions already in progress. Record when the policy change takes effect in the chosen configuration; do not assume “continuous verification” means every session ends immediately.

Use a safe test environment to distinguish identity-provider failure, connector failure, DNS failure and loss of the access service. For each, observe whether existing work continues, new sessions fail, administrators can diagnose the fault and the helpdesk can tell the difference. These are acceptance questions, not universal predictions about ZTNA or VPN behaviour.

Recovery design is particularly important when the same identity or access path is needed to repair the failed component. A retained VPN is not an independent fallback if it depends on the same unavailable authentication service. Map the dependencies before describing a second route as resilient.

Where emergency access is necessary, make it narrow, attributable and time-limited, with an owner responsible for reviewing its use and closing it afterwards. Include that route in exercises. A permanent broad bypass maintained “just in case” undermines the access boundaries the programme is paying to establish.

Retire access by application, with named exceptions

Count an application as migrated when its owner accepts the normal workflow, denied-access behaviour, support process and recovery route. Record any VPN exception against its precise purpose and a review date. This allows the programme to make useful progress without disguising unsupported workloads as completed migrations.

Include the cost of running both services during transition and the effort needed to remove obsolete routes and accounts. A lower licence quote can be outweighed by maintaining two policy systems indefinitely.

Once the access design is chosen, carry its identity requirements into a phishing-resistant authentication rollout that includes recovery. The access broker and the sign-in process must support the same journey from first connection through to a lost device or locked-out administrator.