Lessons from replacing a legacy VPN with Zero Trust Network Access

Start with the reasons for change, not the replacement product

The original problem was broader than an ageing VPN client. Three pressures made the existing remote-access model increasingly difficult to sustain:

• Hybrid work increased dependency on remote access. Capacity and resilience mattered more once remote access became a normal operating model rather than an exception.
• Global expansion exposed the limits of backhauling. Sending international users through a UK-based concentrator introduced unnecessary latency before traffic continued to cloud-hosted services.
• Broad network access was no longer sufficient. We needed policy decisions based on identity, device posture, and the specific resource being requested rather than a one-time connection to a large network segment.

Cost became part of the discussion too, but the architecture case was stronger when framed around user experience, control, resilience, and the ability to support a distributed organisation.

Build identity and device-management foundations first

Our first attempt to evaluate Zero Trust products exposed a more fundamental issue: the organisation was not yet ready to make consistent access decisions. Before the vendor evaluation could be meaningful, we needed three foundations:

1. A unified cloud identity that covered the workforce.
2. Device-management coverage across Windows, macOS, and Linux.
3. A clearer understanding of which users needed access to which resources.

This changed the sequence of the programme. Product selection was paused while those dependencies were strengthened. When the evaluation resumed, the proof of concept could test real identity, posture, access, operational, and security requirements rather than a simplified laboratory scenario.

A ZTNA platform cannot compensate for fragmented identity, unmanaged devices, or unknown access requirements. Those are programme prerequisites, not details to resolve after deployment.

Evaluate the operating model as well as the feature list

We started with a broad vendor pool, gathered input from technical teams, Information Security, Finance, and the business, and then used an RFI and a weighted scoring model to narrow the options. The final candidates were tested in proofs of concept against the requirements that mattered to us.

Technical capability was only one part of the decision. We also evaluated the roadmap, the quality of engagement, the willingness to collaborate, support, and whether the platform could evolve with the programme. A polished demo is useful, but the long-term relationship matters more when a deployment will uncover edge cases over several years.

Begin with a controlled replacement, then reduce access

Starting with the strictest possible Zero Trust policy would have created too much friction and too many unknowns at once. Instead, the first objective was a recognisable replacement for the corporate VPN, with more control than the existing service but enough initial coverage for people to work.

Historical VPN and network logs helped us understand common patterns. We built user personas, mapped those personas to groups and policies, and allowed broad low-risk access where appropriate. Higher-risk services, including Active Directory and direct RDP patterns, started from no access and were enabled only for justified use cases.

Treat policy as code from day one

Access policies, lists, and device-posture configuration were managed through automated pipelines rather than edited manually in the administrative portal. That decision provided:

• reviewable and auditable changes;
• repeatable deployment between environments;
• clear ownership and change history;
• detection of configuration drift;
• a reliable way to revert an unwanted change.

Automation was not added later as an optimisation. It was part of the operating model. That made the service easier to scale because policy changes followed an established engineering workflow rather than depending on individual portal administrators.

Separate ordinary access from difficult legacy use cases

Most traffic can fit a user-initiated, proxy-oriented model. The final portion of a VPN migration often cannot. Older softphones, server-initiated connections, overlapping address spaces, specialised protocols, and applications that assume broad network adjacency require different treatment.

The mistake would be to let those exceptions define the architecture for every user. We kept the remaining legacy service for the small number of dependencies that genuinely required it, while application owners moved suitable workloads to SaaS, web-based access, or alternative internal services.

This is why VPN retirement is a portfolio exercise. Every residual dependency needs an owner, a reason, and an exit path. Without that discipline, the final legacy service can remain indefinitely because nobody owns the last few use cases.

Use performance and support data to prove the change

Security was not the only measurable outcome. Moving users away from a central UK VPN path allowed them to connect to a nearby Cloudflare point of presence, with private connectivity continuing closer to the destination. In the public webinar, I described some global access paths as being approximately five to six times faster than the previous route.

We tracked progress using a combination of adoption and experience indicators:

1,000

Initial user deployment goal

80%

Year-two migration target

~95%

Users migrated by the time of the public webinar

• user satisfaction surveys;
• support tickets and recurring issue categories;
• requests for additional application access;
• latency and user-experience feedback;
• the percentage of users still dependent on the legacy VPN.

These measures helped show whether the service was becoming an ordinary, dependable part of working life rather than merely reaching a technical deployment milestone.

Treat change management as part of the architecture

The largest unexpected barrier was often cultural rather than technical. A VPN gives users a familiar sense of broad connectivity. ZTNA deliberately changes that model, so tasks such as remote desktop access may work through a different path and with fewer underlying network permissions.

Executive sponsorship was essential because the transition changed established ways of working and occasionally created friction. A bottom-up technical project can stall as soon as the first influential group asks for the previous experience to be restored. Leadership needs to support the security objective, the phased plan, and the removal of unsafe fallback patterns.

The communication also needs to be practical. Users care about what is changing, when it will happen, what they need to do differently, and where to get help. They do not need a lecture on Zero Trust terminology.

Be pragmatic, but record the security debt you accept

TLS inspection created significant friction for development workflows, particularly around containers and certificate trust. The pragmatic decision at the time was to disable inspection rather than block the wider migration.

In hindsight, this is the area I would challenge more strongly. Disabling a control may unblock adoption, but it also limits malware inspection, data-loss prevention, and other policy options. When a control is deferred, the decision should be explicit, risk-assessed, time-bound, and paired with a plan to change the affected engineering workflow rather than allowing the exception to become permanent by default.

The lessons I would carry into another programme

It is not as simple as swapping in a new solution. Zero Trust is a marathon, not a sprint.