Zero Trust Network Access for UK Businesses: A Practical Guide to Replacing VPNs with ZTNA in 2026

Zero Trust Network Access changes one specific thing about remote working, and that one thing is the reason it has moved from architecture diagram to procurement queue across the UK mid-market. A VPN authenticates a person once and then places their device on your network. ZTNA authenticates the person, interrogates the device, and then brokers a connection to one named application — and nothing else. The difference sounds academic until an employee’s credentials are phished on a Tuesday evening, and the question becomes: what could the attacker actually reach with them?

This guide answers that question in practical terms for UK businesses planning a 2026 migration. It covers what ZTNA is and how the broker-and-connector model works, why the VPN blast radius problem is structural rather than a configuration error, what the products actually cost in pounds per user per month, how the main vendors differ where it matters, how to score your own readiness before you shortlist anything, and how to run a phased VPN-to-ZTNA rollout that does not strand your remote and hybrid workers halfway through. It ends with the mistakes that cost projects their credibility, a decision framework for whether to move now or harden what you have, and the metrics that tell you the migration actually worked.

What Zero Trust Network Access actually is — and what it is not

Zero Trust Network Access is a remote access model in which no user, device or network location is trusted by default, and every individual connection to an application is authorised at the moment it is requested. The user connects to a broker, not to your network. The broker checks who they are, what device they are on, and whether that combination is permitted to reach the specific resource being requested. If the answer is yes, an outbound tunnel from a lightweight connector sitting next to the application is stitched to the user’s session. If the answer is no, the application is not merely blocked — it is invisible. There is no port to scan, no login page to brute-force, and no network to enumerate.

The architecture is deliberately inverted compared with a VPN. In a VPN design, you publish a concentrator on a public IP, users dial in, and once the tunnel is established the user’s device is issued an address on your internal network. Everything from that point is a firewall rule problem. In a ZTNA design, nothing is published. The connector — a small piece of software or a virtual appliance in your data centre, your Azure VNet or your AWS VPC — makes an outbound connection to the broker and holds it open. Inbound firewall rules for remote access are, in the mature end state, deleted. That single structural change is what removes the externally reachable attack surface that has driven so many remote access incidents.

The conceptual roots are older than the marketing. The Software Defined Perimeter work published by the Cloud Security Alliance, Google’s BeyondCorp programme, and later NIST Special Publication 800-207 on Zero Trust Architecture all describe the same shift: from an implicit trust zone bounded by a firewall to per-request authorisation based on identity, device state and context. In the UK, the NCSC’s zero trust architecture design principles are the reference most boards and auditors recognise, and they are worth reading before a shortlist rather than after one — they set out the expectation that you know your architecture, authenticate everywhere, and evaluate device health as a condition of access.

It is equally important to be precise about what ZTNA is not. It is not a firewall replacement: you still need egress control, segmentation between workloads, and inspection of the traffic that leaves your estate. It is not a full SASE platform on its own — ZTNA is the private-application access component, usually sold alongside a secure web gateway, CASB and DLP in a wider bundle. It is not a substitute for endpoint protection, because a compromised managed device with a valid posture signature is still a compromised device. And it is not, by itself, zero trust. Zero trust is a strategy that spans identity, devices, networks, applications and data. ZTNA is the network access control plane that makes the strategy enforceable for private applications. Buying the product does not deliver the strategy, and the organisations that treat the purchase as the finish line get the licence cost without the risk reduction.

The UK remote access picture in 2026 — where the estate actually sits

Six years on from the emergency remote-working build-out, the UK mid-market runs a remote access estate that nobody would design deliberately. The typical 80–250 seat organisation we assess has a VPN concentrator built in 2020, extended twice under pressure, with a rule base that has grown by accretion and a client that half the workforce avoids because it slows their laptop. Alongside it sit two or three exceptions: a legacy RDP gateway for the finance system, a published web portal for a supplier, and a remote support tool with its own account model that nobody has reviewed since the person who deployed it left.

The numbers below reflect what we see in Cloudswitched assessments across that segment. They are indicative of the mid-market rather than universal, but the shape is consistent enough to plan against.

That last figure is the one that changes project plans. Leadership teams assume a ZTNA migration means onboarding every internal system before anyone can switch. In practice, a small number of applications — the file server or SharePoint estate, the line-of-business system, the accounts package and one or two internal web tools — account for the overwhelming majority of connections. Onboard those, move the users who only need them, and you have already removed a large share of VPN sessions in the first month. The long tail of rarely-used systems can be migrated at a civilised pace, and a residual VPN can be kept alive for a shrinking group of edge cases without undermining the security case, provided it is scoped down aggressively as you go.

The second observation from assessments is that the blocker is rarely the network. It is identity. Organisations with a clean Microsoft Entra ID tenant, consistent MFA, and device compliance signals flowing from Intune can stand up a working ZTNA pilot in days. Organisations still running a fragmented directory, shared service accounts, and a mix of unmanaged personal devices need to fix those first, because ZTNA policy is written in the language of identity and device state. If those signals are unreliable, the policy is unreliable. We cover this dependency in detail further down, and it is the reason the readiness scoring section comes before the rollout timeline rather than after it.

Why UK businesses are retiring VPNs — the drivers, ranked

Very few ZTNA projects start with an architect reading NIST SP 800-207. They start with a specific piece of pain, and the pain is usually operational before it is strategic. When we ask decision-makers what actually triggered the review, the answers cluster into a small set of drivers. The chart below ranks how frequently each one is cited as a primary or strong contributing reason in the conversations we have with UK organisations of 50–500 staff.

Blast radius leads because it is the one risk that survives every mitigation you can apply to a VPN. You can enforce MFA, and attackers use session-token theft or MFA fatigue to get past it. You can patch diligently, and a zero-day in an edge appliance still exists for the window before a fix ships. You can restrict by IP, and remote workers on mobile broadband make that unworkable. What you cannot do, inside the VPN model, is stop a valid session from being a network-layer session. Once the device holds an internal address, lateral movement is a routing question rather than an authorisation question, and your defence falls back on internal segmentation that most SMEs have never built.

Third-party access is the second driver and often the fastest to deliver value. Contractors, outsourced developers, a bookkeeper, an EPOS vendor, a maintenance engineer who needs the BMS — each traditionally received a VPN account and, with it, a seat on your network. ZTNA lets you grant a named external person browser-based access to exactly one internal web application, with no client software, no network address, session recording where the platform supports it, and an expiry date. Organisations frequently pilot on this population precisely because the risk reduction is obvious, the user count is small, and no internal change management is required.

The insurance and supply-chain driver is the one that turns a technical preference into a funded project. Renewal questionnaires and client due-diligence packs have become markedly more specific about remote access: whether administrative interfaces are exposed, whether MFA is enforced on all remote access, whether access is application-scoped, and whether third parties have network-level access. A ZTNA deployment converts several awkward answers into clean ones. If you are already working through the Cyber Essentials certification process, the overlap is substantial — particularly around removing internet-exposed services and enforcing multi-factor authentication on every remote entry point.

Appliance vulnerability pressure deserves its own note. Internet-facing remote access appliances have been among the most reliably targeted assets in enterprise IT for several years running, and the pattern is consistent: a critical vulnerability is disclosed, exploitation follows within days, and organisations that could not patch inside the window suffer. The structural fix is not faster patching — it is removing the inbound listener entirely. That is exactly what the outbound-connector model achieves, and it is the argument that resonates most with technical stakeholders who have lived through an emergency patch weekend.

What ZTNA costs in the UK — licensing, deployment and total cost

ZTNA is sold per user per month, usually annually committed, and almost always discounted from list at mid-market volumes. The table below gives indicative UK list bands for the tiers a 50–500 seat organisation would realistically buy at the time of writing. Treat them as planning figures for a business case, not as quotes: pricing moves, bundles change, and the discount at 200 seats is materially different from the discount at 50.

Three cost points are routinely missed in the first business case. The first is that ZTNA licensing is rarely additive for long — it displaces the VPN concentrator support contract, often a chunk of remote access firewall licensing, and sometimes a separate MFA or remote support product. A 150-seat organisation paying around £7 per user per month is spending roughly £12,600 a year, against which a £4,000–6,000 annual appliance support and maintenance line, plus the deferred capital cost of a refresh, offsets a meaningful share.

The second is that the professional services line is driven almost entirely by legacy applications, not by user count. Onboarding a modern internal web application takes minutes. Onboarding a thick client that hard-codes NetBIOS names, requires dynamic RPC port ranges, or expects the user to be on the same broadcast domain as a licence server takes a day of investigation and sometimes a design compromise. Count your legacy applications honestly during discovery, because they are the single largest variable in the quote you receive.

The third is bandwidth and egress. In a ZTNA model, traffic to internal applications flows through the vendor’s edge and then over your connector’s outbound connection. If your line-of-business system lives in a server room on a 200 Mbps asymmetric connection with a 20 Mbps upload, every remote user’s traffic is now competing for that upload. This is a genuine constraint and a common cause of a disappointing pilot. Review your circuit before you review your vendor shortlist — our guide to business broadband failover and redundancy covers the diversity and capacity questions that matter here, and the answer for many organisations is that the connector belongs in Azure alongside the application rather than in the office.

VPN vs ZTNA — a like-for-like comparison

The two models are frequently compared on features when the meaningful differences are architectural. The comparison below is deliberately framed around what happens to a compromised session, because that is the scenario the investment is intended to address. Both columns assume a competent deployment; a badly configured ZTNA rollout with over-broad policies can reproduce most of the VPN’s weaknesses, which is why the policy design phase matters more than the product choice.

The row that matters most is lateral movement. With a VPN, preventing an attacker with a valid session from reaching the backup server is a segmentation problem — it requires internal firewalls, VLAN design and a maintained rule base, which is exactly the work that gets deferred in resource-constrained IT teams. With ZTNA, the same outcome is a default: the backup console was never in the user’s policy, so there is no route to it and no listener to discover. You have moved the control from a network configuration you must actively maintain to an authorisation decision that fails closed.

The audit row is the one that surprises people in a good way. VPN logs tell you that a user connected at 08:42 and disconnected at 17:15. ZTNA logs tell you that the user reached the finance application eleven times, the HR system twice, and attempted to reach a file share they are not entitled to at 23:40 from a device that failed its posture check. That is a materially better evidence base for an investigation, for an ICO-relevant incident assessment under UK GDPR Article 32, and for the routine access reviews that client due-diligence increasingly demands. It also makes the eventual VPN decommission defensible, because you can prove which applications are still being reached and by whom.

Where the VPN still wins is a narrow but real set of cases: an engineer who genuinely needs broad network access for troubleshooting, a legacy protocol that resists brokering, or a site-to-site link between offices that was never a user access problem in the first place. Good ZTNA deployments do not pretend these do not exist. They shrink the VPN down to a small, heavily monitored, MFA-enforced, jump-host-mediated capability used by a named handful of administrators, rather than removing it and quietly leaving a wide-open replacement in its place.

ZTNA readiness scoring — where most UK businesses actually sit

ZTNA policy is written in the language of identity, device state and application inventory. If any of those three is unreliable, the policy you write will be either too permissive to be useful or too brittle to survive contact with real users. The scoring below reflects the prerequisites we assess before recommending a migration date, grouped into the three domains that determine whether a project runs to plan or stalls in week five. Rate yourself honestly against each row; a high-risk marking in the identity card is a reason to sequence work differently, not a reason to abandon the project.

The pattern in these assessments is consistent. Endpoint tooling is usually in reasonable shape — most organisations have EDR and most have MFA on Microsoft 365. What is missing is the connective tissue: the device compliance signal that the access broker can consume, and the application inventory that policy has to be written against. Neither is difficult work, but both take calendar time and both need someone to own them. A project plan that assumes these exist and discovers in week three that they do not is a project plan that slips by a month.

The contractor and third-party row is worth dwelling on because it is where the highest risk and the fastest win coincide. In a large proportion of the estates we review, external parties hold VPN credentials that were issued for a specific project and never revoked, sometimes years earlier, occasionally shared between several people at the supplier. Those accounts are network-level access held by an organisation whose security posture you do not control and cannot audit. Migrating exactly this population to browser-based, single-application, time-boxed ZTNA access is often the strongest phase-one scope available, and it produces evidence you can hand straight to an insurer or a client’s due-diligence team.

Application inventory scores worst almost universally, and the reason is structural rather than negligent: nobody has ever been required to produce one. VPNs do not need an inventory to work — they grant a subnet and let discovery happen naturally. ZTNA needs an inventory by design, because you cannot broker access to an application you have not defined. This is the hidden benefit that survives long after the migration: for the first time, the organisation has a documented, owned, reviewed list of what its internal applications are, who uses them and from where. Several clients have found that inventory more valuable for licensing, disaster recovery planning and due diligence than for the access project that produced it.

The VPN-to-ZTNA migration timeline — a phased 16-week rollout

The migration below is the shape we use for a 100–250 seat organisation with a mixed on-premises and Azure estate. It is deliberately phased so that no group of users experiences a hard cutover, and so that the VPN is retired by attrition rather than by a big-bang switch on a Friday night. Compress it for a cloud-only estate with 40 staff; extend it where there are manufacturing systems, clinical applications or a heavy legacy client footprint.

Two scheduling notes matter more than the rest. First, align the end of the migration with your VPN support renewal or hardware refresh date; that is where the offsetting saving lives and it makes the finance conversation straightforward. Second, do not schedule the departmental waves across a year-end, an audit or a peak trading period. The technical risk in a ZTNA wave is low, but the tolerance for any disruption during those windows is lower still, and a single bad week in finance will cost you the goodwill you need for the remaining waves.

The 48-hour rollback in each wave is not a sign of weak confidence — it is what makes the waves fast. Users who know they can be put back on the old system tomorrow raise issues calmly instead of escalating them. In practice the rollback is used for a small fraction of users in the first two waves and almost never after that, but its existence is what keeps the project moving at a weekly cadence.

ZTNA benchmarks and KPIs — what to measure before, during and after

A migration without measurement becomes an opinion. The metrics below are the ones we baseline in week one and re-measure at the 30, 90 and 180-day reviews. They are chosen because each maps to something a board, an insurer or an auditor will ask about, and because each is obtainable from tooling you will already have. The percentages shown are the typical maturity scores we record at the start of a migration for a UK mid-market organisation — the gap between these and where you need to be is the actual scope of work.

Read that list from the bottom rather than the top. The controls that score highest are the ones with a product attached: buy EDR, deploy it, the number goes up. The controls that score lowest are the ones that require a documented process and a named owner — inventories, reviews, least-privilege design. ZTNA does not fix those by itself, but it does something more useful: it makes their absence immediately visible, because you cannot write a policy without them. Several organisations have described the migration as the first project that forced them to answer questions they had been deferring for years.

For the migration itself, track five operational KPIs weekly and put them on one slide. Active VPN sessions per week is the headline — it should fall monotonically from the pilot onward, and any plateau tells you exactly which group or application has not moved. Applications onboarded against the inventory shows delivery progress and exposes the long tail early. Median time-to-access — how long from opening a laptop to being productive in the line-of-business system — is the metric that wins user support, because it usually improves noticeably. Access-related helpdesk tickets per 100 users should spike modestly in the first wave and then fall below the VPN baseline. And policy exceptions granted is your early warning system: a growing exception register means policies are too rigid or the inventory was incomplete, and both are much cheaper to fix in week six than in month six.

At the 90-day review, add two security metrics that only become measurable after migration: the count of denied access attempts by policy reason, and the number of distinct applications reachable by the average user account. The second is your blast radius expressed as a number, and watching it fall from “every system on three subnets” to “four named applications” is the clearest possible articulation of what the project bought. Pair it with the evidence from your last penetration test — if you are commissioning one, our comparison of CREST versus standard penetration testing covers how to scope a test that actually exercises the new access model rather than the perimeter you have just removed.

The identity foundation — why ZTNA fails without it

Every ZTNA access decision is a function of three inputs: who the user is, what state their device is in, and what they are asking to reach. Two of those three come from identity and endpoint management, which is why the quality of your Entra ID tenant or equivalent directory determines the quality of your ZTNA deployment far more than the vendor you choose. In assessments across UK mid-market estates, the proportion of organisations with all the identity prerequisites genuinely in place before they start — single directory, named accounts throughout, MFA everywhere, conditional access enforcing rather than reporting, and a device compliance signal the broker can read — is smaller than most people expect.

The other seventy-one percent are not blocked — they simply have two to four weeks of preparatory work that belongs at the front of the plan rather than discovered halfway through it. The most common items are consistent. Shared accounts used interactively, typically for a reception PC, a warehouse terminal or a finance system that predates named licensing, have to become named accounts because a policy cannot be written for “whoever is sitting there”. Contractor accounts created in a local directory or as unmanaged guests need to be brought into the authoritative tenant so their access can be governed and expired. And device compliance needs to move from “we have Intune” to “Intune compliance state is a published signal that the access broker evaluates on every request”, which is a configuration step people assume is automatic and is not.

Conditional access deserves particular attention because it is where ZTNA and identity overlap most directly. If you are a Microsoft-centric organisation, a significant portion of what ZTNA vendors sell is already available to you through Entra ID conditional access combined with Entra Private Access, and the integration effort is lower. If you are multi-cloud, or have substantial non-Microsoft SaaS, or need granular per-application controls across a heterogeneous estate, a dedicated ZTNA or SSE platform will generally give you a cleaner policy model. Neither answer is universally right, and the honest evaluation is done against your application inventory rather than against a vendor comparison chart.

One warning about token theft, because it is the failure mode that defeats naive zero trust designs. Modern attacks against cloud identity increasingly bypass MFA entirely by stealing a valid session token from a compromised browser or endpoint. A ZTNA platform that authenticates once at session establishment and then trusts the session for eight hours has reproduced the VPN’s core weakness in a new place. Ask any vendor you shortlist how they handle continuous evaluation: whether they re-evaluate device posture mid-session, how quickly a revoked account or a device that falls out of compliance loses access, and whether token binding or proof-of-possession is supported. The same discipline that protects your mailboxes applies here — the techniques in our guide to Microsoft 365 email security against phishing and BEC are the front half of the same attack chain that ZTNA is meant to contain.

The ZTNA migration checklist — the 12-point essentials

This is the checklist we work through with clients, in order. It is deliberately weighted towards the preparation phases, because that is where projects succeed or fail; the cutover itself is comparatively mechanical once the first eight points are genuinely complete.

1. Document the current blast radius. List every system, port and management interface reachable from an authenticated VPN session today. Include the backup console, the hypervisor, the switch and firewall management addresses, and every printer. Get it signed off by whoever owns risk — this single document justifies the project better than any vendor deck.
2. Build the application inventory. Name, owner, hosting location, protocol and ports, user population, and whether it is a web application, a thick client or a management interface. Two weeks of VPN flow data will find the systems nobody remembered.
3. Consolidate identity. One authoritative directory, named accounts for every human including contractors, no interactive use of shared or service accounts, and a joiner-mover-leaver process that is actually executed rather than documented.
4. Enforce MFA on every access path. Not just the VPN and Microsoft 365 — the remote support tool, the published portal, the RDP gateway and the hosting control panel too. Phishing-resistant methods for administrators as a minimum.
5. Publish the device compliance signal. Confirm your MDM or EDR compliance state is available to the access broker as an evaluated condition, and decide in advance what happens to a device that falls out of compliance mid-session.
6. Define access tiers before choosing a vendor. Typically four: standard staff, privileged administrators, third parties, and unmanaged or personal devices. Each gets a different combination of application scope, device requirement and session duration.
7. Test the awkward applications in a trial. The thick client with dynamic ports, the system that requires a fixed source IP, the application with certificate pinning, the supplier who cannot install an agent. Prove these work before you sign, not after.
8. Check circuit capacity at the connector. Confirm the upload bandwidth where your connectors will sit, and move connectors to the cloud alongside the application where the office circuit cannot support the load. Deploy connectors in pairs for resilience.
9. Confirm data residency and logging. Where access logs are stored, for how long, whether UK or EU residency is contractually available, and how logs reach your SIEM. Record the answers in your UK GDPR processing documentation.
10. Run a genuine pilot with rollback. Ten to fifteen technical users, both systems available in parallel, a documented 48-hour rollback, and a logged issue list that becomes the helpdesk knowledge base for the waves that follow.
11. Migrate third parties before staff. Highest risk reduction, lowest change management, and immediate evidence for insurers and clients. Revoke the old accounts the same day they are replaced.
12. Shrink, then decommission, then verify externally. Reduce VPN scope wave by wave, remove the inbound rules, and confirm from an external vantage point that nothing answers. Update the network diagram, asset register and continuity plan, then schedule 30, 90 and 180-day policy reviews.

Decision framework — move to ZTNA now, or harden the VPN first?

Not every organisation should start a ZTNA migration this quarter, and pretending otherwise does clients a disservice. The honest answer depends on where your remote access risk actually concentrates and on whether the identity foundations are close enough to build on. The gauge below shows the composite readiness score we typically calculate for a UK mid-market organisation at first assessment, weighted across identity maturity, device management, application inventory quality and the exposure of the current remote access design.

A score in the low forties is not a reason to delay — it is a description of the preparatory work. The distribution behind it is uneven in a predictable way: identity and endpoint tooling pull the score up, while application inventory, least-privilege design and access review discipline pull it down. Because the low-scoring components are precisely the ones ZTNA forces you to address, organisations at this level usually find the migration improves several controls that were never in its stated scope.

Use these thresholds when deciding sequence. Below 30, do not start a platform procurement. Spend a quarter on identity consolidation, MDM enrolment and the application inventory first; buying ZTNA into that environment produces a policy set nobody trusts and an exception register that grows every week. Between 30 and 55 — where most organisations sit — run the two-to-four week readiness workstream at the front of the project and proceed. This is the normal path and the 16-week timeline is built for it. Above 55, you can move directly to a pilot, and a cloud-first organisation with a clean tenant may well be piloting within a fortnight of the decision.

There are three situations that override the score and argue for moving now regardless. First, if your VPN appliance is out of support or approaching end-of-life, you are about to spend capital on a design you intend to retire — redirect it. Second, if third parties hold network-level access, that risk is live today and the third-party phase can be delivered independently of everything else. Third, if an insurer, a major client or a certification body has asked a question you cannot answer honestly, the commercial clock is already running. Conversely, if your remote access is already limited to a handful of staff reaching Microsoft 365 only, with no on-premises applications at all, you may not need ZTNA so much as better conditional access — and it is worth saying so before anybody signs a three-year term.

Common ZTNA mistakes to avoid

The failure modes below account for most of the disappointing ZTNA deployments we are asked to review. None of them is a product defect. Every one is a decision made early, under time pressure, that quietly removed the benefit the project was funded to deliver.

• Recreating the VPN inside ZTNA. The single most common failure. Under pressure to migrate quickly, someone defines a policy granting an entire internal subnet to the “All Staff” group. Access works instantly, nobody complains, and the blast radius is unchanged — now with a monthly subscription attached. Once the shortcut is in production it is almost never tightened, because doing so means breaking access for people who have grown used to it.
• Buying before the application inventory exists. Vendor selection made against a feature matrix rather than your real application list means discovering in week five that the thick client everybody depends on needs a design compromise the chosen platform handles badly. The inventory is the requirements document; a shortlist assembled without it is guesswork.
• Treating device posture as optional. Identity-only ZTNA stops the credential-theft scenario at the network layer but permits a compromised or unmanaged endpoint with valid credentials to reach applications. If device compliance is not an enforced condition, you have implemented half the model and are carrying the licence cost of the other half.
• Leaving the VPN running “just in case”. A parallel-run period is correct and necessary. A permanent parallel run is not. If the concentrator is still published six months later with its original rule base, the exposure the project was meant to remove is still there, and every argument you made in the business case is now false.
• Ignoring administrative access. Standard staff are migrated to per-application access while administrators keep a broad legacy path to management interfaces — hypervisor, firewall, backup console, domain controllers. Those are the highest-value targets in the estate. Privileged access needs the tightest policy and the strongest authentication, not an exemption.
• Forgetting the office. ZTNA is deployed for remote workers while everyone in the building keeps unrestricted network access to everything. An attacker who gains a foothold on an office endpoint faces none of the controls the project installed. Mature deployments apply the same brokered access on-premises, which also removes the awkward behavioural difference between working from home and working from a desk.
• Underestimating the connector circuit. Connectors placed in an office whose upload bandwidth was sized for browsing become the bottleneck for every remote user of the applications behind them. The pilot feels sluggish, the platform gets the blame, and the actual fix — moving the connector next to the workload or upgrading the circuit — is identified far too late.
• No exception governance. Exceptions are inevitable during a migration. Exceptions without an owner, a business justification and an expiry date become permanent within weeks. An exception register that only grows is the clearest early indicator that a deployment is drifting back towards implicit trust.

Real-world example — a 90-person professional services firm in Leeds

A Leeds-based professional services firm of roughly ninety staff, with a second office in Manchester and a practice management system hosted on two virtual machines in Azure, came to the question the way most organisations do: not through architecture, but through a client questionnaire. A major account had asked, in writing, whether third parties had network-level access to systems holding their data, and whether remote access was scoped to individual applications. The honest answers were “yes” and “no”. The firm had eleven active VPN accounts belonging to external parties, including two at a supplier engagement that had concluded fourteen months earlier.

Discovery mapped an internal estate of twenty-three applications, of which six accounted for the overwhelming majority of remote sessions. Blast radius mapping produced the document that unlocked the budget: an authenticated VPN session could reach the practice management database directly on its SQL port, the backup appliance web console, the hypervisor management interface at the Leeds office, both domain controllers, and every networked printer at both sites. None of this was misconfiguration in the ordinary sense — it was the accumulated result of five years of individually sensible firewall changes, each one approved, none of them ever reviewed together.

Preparation took three weeks, slightly longer than planned, almost entirely because of identity work: two shared logins on reception and in the post room, four contractors authenticating against a local directory rather than the tenant, and Intune compliance state that existed but was not published as a signal the broker could evaluate. The third-party migration completed in week eight and revoked all eleven external VPN accounts on the same day, replacing them with browser-based access to a single application each, expiring after ninety days. Departmental waves ran weekly at twenty-five users. The concentrator was scoped down to two legacy systems and four named administrators in week fourteen, and its public listener was removed in week seventeen — one week beyond plan, delayed by a licence server that turned out to require a fixed source address.

At the ninety-day review, the number of distinct internal systems reachable by an average staff account had fallen from “everything on three subnets” to five named applications. Access-related helpdesk tickets, which rose by about a third during the first two waves, settled roughly a fifth below the pre-migration baseline once the always-on agent removed the daily manual connect. The application inventory built during discovery was subsequently reused for the firm’s business continuity documentation and for its Azure disaster recovery and failover planning, which the IT manager described as the second-most useful output of a project that had been sold on access control.

The blast radius document was what changed the conversation. Nobody in the leadership team wanted to discuss network architecture, but everyone understood a single page listing what a stolen password could reach by nine the next morning. The budget was approved at the meeting after that one.

Two lessons transfer to most organisations. The first is that the client questionnaire, not the security team, was the trigger — commercial pressure moves faster than internal risk registers, and framing the business case in the language of client assurance and insurance renewal is usually more effective than framing it in the language of architecture. The second is that the schedule slipped for a reason nobody could have avoided by working harder: a legacy licence server with an assumption baked into it a decade ago. Plan for one of those. Every estate has at least one.

ZTNA at a glance — the summary table

The reference table below condenses the planning facts from this guide into a single view for a business case appendix or a project kick-off pack.

How Cloudswitched delivers Zero Trust Network Access

Cloudswitched designs and delivers cloud networking for UK businesses, including VPN-to-ZTNA migrations of the kind described in this guide. The work starts with discovery and blast radius mapping rather than with a product recommendation, because the application inventory and the identity readiness assessment determine which platform is the right fit and how long the migration will realistically take. We deploy and run connectors, design least-privilege policy against your real application list, run the pilot and the departmental waves, and take the concentrator through scope reduction to decommission with the evidence pack your insurer and your clients will ask for. Where the assessment shows that better conditional access would serve you more cheaply than a new platform, we say so.

Frequently Asked Questions

What is Zero Trust Network Access in simple terms?

Zero Trust Network Access is a way of giving people remote access to individual applications rather than to your network. Instead of connecting to a VPN and receiving an internal network address, the user connects to a broker that checks their identity, their device’s security state and the specific resource they are requesting, then stitches together a connection to just that one application. Everything they are not entitled to reach is not merely blocked — it is invisible, because there is no network path to it and no public listener to discover. The practical effect is that a stolen password or hijacked session gives an attacker access to a named application rather than a foothold on your internal network.

How is ZTNA different from a VPN?

A VPN authenticates once and then places the device on your network, so access is controlled by firewall rules and routing. ZTNA authorises every request individually against identity, device posture and application, so access is controlled by policy. The architectural difference is that a VPN requires a publicly reachable listener, while ZTNA uses an outbound connector that dials out to the broker — meaning there is nothing exposed to the internet for an attacker to scan or exploit. The operational difference is granularity: VPN logs show that someone connected, while ZTNA logs show precisely which applications they reached, when, from what device, and what was denied.

How much does ZTNA cost for a UK business?

Indicative UK list pricing at the time of writing runs from around £4–7 per user per month for entry-level single-vendor ZTNA, £8–12 where it is bundled with an identity suite, £9–16 for a mid-market security service edge bundle that also includes web filtering and CASB, and £15–28 for a full SASE platform including SD-WAN. Mid-market volumes attract meaningful discounts from list. Add a one-off professional services cost of roughly £4,000–18,000 for a phased migration, driven mainly by how many legacy applications need investigation rather than by user count. Offset the total against your VPN appliance support contract and any deferred hardware refresh.

Do we have to switch off our VPN straight away?

No, and you should not. The reliable approach is a parallel run in which ZTNA is introduced alongside the VPN, users are migrated in waves with a documented 48-hour rollback, and the VPN is then shrunk rather than switched off — removing migrated user groups, cutting the accessible subnets down to residual legacy systems, and tightening what remains. Only when session counts have fallen to a small, understood set of exceptions do you remove the inbound firewall rules and retire the public listener. The one thing to avoid is an indefinite parallel run: if the original concentrator is still published with its original rule base six months later, the exposure the project was funded to remove is still there.

Does ZTNA work with legacy applications and thick clients?

Usually, but it is the part of the project that needs proving before you sign a contract rather than after. Modern internal web applications onboard in minutes. Thick clients are more variable: applications using dynamic RPC port ranges, hard-coded NetBIOS names, licence servers that expect a fixed source address, or protocols that assume the client and server share a broadcast domain all need testing in a trial tenant against your shortlisted platforms. Most cases have a workable answer, sometimes involving a small design compromise such as brokering access to a jump host. Test your two or three most awkward applications during evaluation — they will tell you more about vendor fit than any feature matrix.

Is ZTNA required for Cyber Essentials certification?

No. Cyber Essentials does not mandate any particular remote access technology. It does ask searching questions about services exposed to the internet, about multi-factor authentication on remote access and cloud services, and about restricting administrative privilege — and a ZTNA deployment makes several of those answers considerably easier to give, because the outbound-connector model removes the internet-facing listener entirely. Treat ZTNA as something that supports certification and the wider due-diligence conversation rather than as a requirement of it. Our step-by-step Cyber Essentials guide covers what the assessment actually asks.

How long does a VPN-to-ZTNA migration take?

For a typical UK organisation of 100–250 staff with a mixed on-premises and Azure estate, plan for 12–16 weeks from kick-off to VPN decommission. Roughly 60–70% of that is preparation with no user-facing change: discovery, identity consolidation, device compliance signals, connector deployment and policy design. A cloud-first organisation under 50 seats with a clean identity tenant can complete the same journey in four to six weeks. Estates with substantial legacy applications, clinical or manufacturing systems, or multiple sites with their own network history should plan for longer and sequence the legacy work as a separate stream.

What happens to remote access if our internet connection fails?

ZTNA depends on connectivity at both ends, so the same resilience questions apply as with any cloud-delivered service — with one important difference. If your connectors sit in an office and that office loses its line, remote users lose access to the applications behind those connectors. If the connectors sit in Azure alongside the workloads, an office outage affects only the people in that office. This is a strong argument for placing connectors next to the application rather than in the building, and for reviewing circuit diversity at any site that must host them. Our guide to business broadband failover and redundancy covers how to design that properly.

Can ZTNA give access to contractors and suppliers without giving them a laptop?

Yes, and it is usually the strongest phase-one use case. Most platforms support browser-based access to internal web applications with no agent installed on the external party’s device, scoped to a single named application, with a defined expiry date, per-request logging and in some products session recording. That replaces the common pattern of issuing a supplier a VPN account — which gives an organisation whose security posture you cannot audit a seat on your internal network, frequently long after the engagement has ended. Migrating third parties first delivers a large risk reduction with almost no internal change management.

Does ZTNA protect against stolen session tokens?

Only if the platform is configured to evaluate continuously, and this is a question worth putting to every vendor on your shortlist. Attacks against cloud identity increasingly bypass multi-factor authentication by stealing a valid session token from a compromised browser or endpoint. A ZTNA product that authenticates once at session establishment and then trusts that session for the rest of the day has reproduced the VPN’s central weakness. Ask specifically how often device posture is re-evaluated mid-session, how quickly a revoked account or a device that falls out of compliance loses access, and whether token binding or proof-of-possession is supported.

Do we still need internal network segmentation if we deploy ZTNA?

Yes, for two reasons. ZTNA controls how users reach applications; it does not control how servers and services talk to each other, and lateral movement between workloads remains a real risk after a compromise. Second, most organisations keep some on-premises access — office endpoints, unbrokered legacy protocols, administrative paths — and segmentation is what limits the damage there. The practical position is that ZTNA substantially reduces the urgency of user-facing segmentation while leaving east-west segmentation between server tiers exactly as important as it was before.

Should we choose a dedicated ZTNA vendor or use what our identity platform already offers?

It depends on your application inventory rather than on vendor marketing. If you are a Microsoft-centric organisation already licensed for Entra ID P1 or P2, with most internal applications either in Azure or web-based, the identity-suite route often gives you a cleaner integration, one policy engine and a lower incremental cost. If you have significant non-Microsoft SaaS, multi-cloud workloads, a large legacy thick-client footprint, or a need for web filtering and CASB in the same bundle, a dedicated ZTNA or SSE platform will generally give you a better policy model and better handling of awkward protocols. Evaluate both against your real application list, in a trial tenant, before committing to a multi-year term.

What is the first thing we should do if we are only at the thinking stage?

Write the blast radius document. Spend an afternoon listing every system, service and management interface an authenticated VPN session can reach today — file servers, databases on their native ports, the backup console, the hypervisor, firewall and switch management addresses, printers. Do not editorialise; just list it. That single page tells you how urgent the project is, gives you the scope for phase one, and is consistently the artefact that moves a leadership team from interest to funding. Everything else in this guide follows from it.

Related reading

These guides cover the identity, resilience and assurance work that sits either side of a ZTNA migration for UK businesses.

• Cyber Essentials Certification for UK Businesses: A Step-by-Step Guide
• Microsoft 365 Email Security: Defending Against Phishing and BEC
• CREST vs Standard Penetration Testing: What UK Businesses Need to Know
• Business Broadband Failover and Redundancy: A UK Guide
• Azure Disaster Recovery and Failover Planning for UK Businesses