VPN replacement: moving from VPN to zero trust access

Why organisations replace their VPN

A remote access VPN does one job well: it puts a remote device on the internal network. That was the point when it was installed, and it is also the problem now. The common reasons for starting a VPN replacement project are:

• An exposed appliance: a VPN gateway has to accept connections from anywhere on the internet, so every vulnerability in it is reachable by anyone who finds it, and patching becomes urgent work rather than routine work
• Broad access: once connected, a user (or an attacker using their account) can often reach far more than their job needs, because the rules behind the VPN were written for convenience
• Insurance and audit questions: cyber insurers and customers often ask how remote access is protected, whether MFA is enforced on it and who can reach what
• End-of-life hardware and clients: firewalls and VPN concentrators reach end of support, and the renewal is a natural point to rethink the design rather than buy the same thing again
• Cloud applications: when most work happens in SaaS, sending all remote traffic back through head office adds delay without adding much protection
• Contractors and personal devices: giving a supplier a VPN account usually means giving them a slice of the network, which is hard to restrict and harder to audit

The alternative is zero trust network access (ZTNA), which grants access to one application at a time after checking the user, the device and the context. If you want the side-by-side detail first, read ZTNA vs VPN; for the vendor-neutral definition, see ZTNA on our cloud security site.

VPN replacement options compared

Most real projects combine two or three of these. A typical pattern is ZTNA for most users and applications, an RDP broker or browser-based sessions for administrators and remote desktops, clientless access for contractors, and a small VPN-as-a-service policy for the one or two legacy systems that cannot move yet. The VPN alternatives for business page walks through each approach in more depth.

Before you start: what to inventory

The NCSC's ZTNA guidance is clear that some groundwork comes first. Its section on what to do before building a ZTNA architecture covers organisational readiness (knowing your users, devices, applications and data flows, and updating your threat model) and the identity and device prerequisites a ZTNA design relies on. In practice that means collecting four lists before choosing a product:

1. Users and groups: staff, administrators, contractors and suppliers, and which of them use the VPN today.
2. Devices: which are company-managed, which are personal, and what operating systems they run. The NCSC expects centralised device management and visibility of device health.
3. Applications: every system reached over the VPN, with its protocol (web, RDP, SSH, SMB file shares, thick-client databases), where it is hosted and who uses it.
4. Identity: your identity provider, whether MFA is enforced for everyone (the NCSC asks for phishing-resistant authentication such as FIDO2 credentials), single sign-on coverage, and how joiners and leavers are handled.

The VPN logs are the most honest source for the application list. Users rarely remember the old reporting server they open once a quarter, but the logs do. Gaps in identity are worth fixing first, because ZTNA decisions are only as good as the sign-in that precedes them; see ZTNA vs IAM.

A migration plan aligned with the NCSC guidance

1. Inventory and classify. Group applications by how they can be reached: browser-based web apps, remote desktops, file shares and thick clients, and anything server-initiated or legacy that needs network-level access.
2. Fix identity and device foundations. Enforce MFA for every remote user, clean up stale accounts and bring company devices under management so posture can be checked. This supports the NCSC design requirement to use multiple signals to inform access decisions.
3. Choose the access method per application. Client-based ZTNA for most staff apps, clientless or enterprise-browser access for contractors and BYOD, brokered RDP for desktops, and VPN as a service only for what cannot move yet.
4. Pilot with a small group. Pick a team that uses a representative mix of applications, run ZTNA alongside the VPN and fix rules and performance issues before widening the rollout.
5. Migrate app by app. Move each application behind the policy engine, confirm users can work, then remove that application from the VPN rules. Avoid copying the old VPN rules into the new platform wholesale.
6. Close inbound ports. Once nothing depends on it, turn off the VPN service and close its internet-facing ports, along with any port-forwarded RDP or web services found during the inventory.
7. Remove legacy routes. The NCSC lists maintaining legacy access routes that bypass the policy engine as one of its four ZTNA anti-patterns. Old site-to-site tunnels, forgotten firewall rules and shared admin accounts all count.
8. Monitor and re-evaluate. Review access logs, tighten broad rules and recheck the design as applications and teams change.

Our guide on how to implement zero trust network access covers each phase in more detail, and the NCSC ZTNA guidance page summarises the eight design requirements and four anti-patterns the plan is built around.

What changes for users and for IT

For most users the change is a small one. They install (or are given) a new client, sign in once with their usual work account and MFA, and their applications open as before. Many ZTNA clients connect automatically, so there is no connect-and-wait step and no reminder emails about starting the VPN. Contractors may not need to install anything at all if they are given browser-based access.

For IT, more changes:

• Policy is written per application and per group, not per subnet, so it is clearer who can reach what
• Device posture becomes part of the decision, which means device management needs to be in good shape
• Logs show allowed and denied requests per application, which helps with investigations and audits
• There is one less internet-facing appliance to patch, once the old VPN is switched off

Expect a period of tuning. Some applications use hard-coded IP addresses, unusual ports or server-initiated connections that need a different access method. That is normal, and it is why the old route should stay available, tightly restricted, until each application has been tested. The NCSC also recommends testing access policies before enforcing them and planning a break-glass route for emergencies.

Common mistakes in VPN replacement

The NCSC's anti-patterns describe the main ways a VPN replacement can disappoint:

• Recreating the walled garden: dropping an SSE or SASE platform in as a like-for-like VPN replacement with an unchanged access model. Broad "all users to all apps" rules on a new platform give the same exposure as before.
• Trusting network location: treating office IP ranges or VPN address pools as trusted, so anyone on them skips the checks.
• Exposing private applications: publishing internal apps directly to the internet as a shortcut instead of placing them behind the policy engine.
• Leaving legacy routes open: the old VPN, port forwards or tunnels stay in place "just in case" and become the path an attacker uses.

Two practical mistakes are also common: skipping the pilot, and choosing a product before the application inventory is done. Both lead to surprises in week one.

How we help with a VPN replacement project

Forever Systems supplies the ZTNA, SSE, SASE and remote desktop platforms on this site, so we can compare them on fit for your users, devices and applications rather than steer you to one. We can review your current VPN and the applications behind it, recommend an approach (often a combination), run a pilot, and help migrate users and applications in stages. Timescales and scope depend on how many applications and sites are involved, and we confirm them at quote.

If cyber insurance or Cyber Essentials is driving the project, we can help you document how remote access is protected; certification and insurance decisions still depend on your wider controls. Compare platforms on ZTNA providers, then contact us to talk through your plans.