In short
SASE vs VPN: a remote access VPN connects users to the office network and often backhauls their internet traffic through the office firewall. SASE replaces that with per-application ZTNA and cloud web and SaaS security at the provider's nearest point of presence. UK organisations usually move group by group, keeping a narrow legacy route until the VPN can close.
Want an impartial recommendation?
Tell us about your users, systems and priorities and we will tell you which option fits, and why.
How a remote access VPN works, and what SASE does instead
A remote access VPN builds an encrypted tunnel from a user's device to a VPN concentrator, usually the office or data centre firewall. Once connected, the user is on the network and can reach whatever the firewall rules allow, which is often a lot of it. To keep web browsing filtered, many organisations send all traffic through the tunnel (full tunnel), so a member of staff in Leeds opening a SaaS app goes to head office first and then out to the internet.
SASE removes the concentrator and the trip to head office. The user's agent or browser connects to the nearest point of presence of a cloud Security Service Edge (SSE). There, two things happen:
- Private applications are reached through ZTNA: a broker checks identity, device and context, then connects the user to that one application through an outbound connector. The network itself is never exposed.
- Web and SaaS traffic goes through the secure web gateway (opens in a new tab), CASB and usually firewall as a service in the same cloud, then straight out to the internet.
Branch offices join the same cloud through SD-WAN or IPsec tunnels, which is what makes it SASE rather than a Security Service Edge (SSE) alone.
SASE vs VPN compared
| Remote access VPN | SASE | |
|---|---|---|
| What the user gets | A connection to the network | Access to named applications, plus protected internet and SaaS use |
| Where traffic is inspected | At the office or data centre firewall, if backhauled | At the provider's nearest point of presence |
| Internet and SaaS traffic | Backhauled (full tunnel) or unprotected (split tunnel) | Inspected in the cloud, then sent directly on |
| Exposure to the internet | A VPN service listening on the firewall | Outbound connectors; no inbound service for private apps |
| Lateral movement after login | Possible across whatever the rules allow | Limited to the applications the policy grants |
| Device and context checks | Usually at connection time only | Per application, and re-evaluated during the session on many platforms |
| Branch offices | Site-to-site VPNs or MPLS, managed separately | SD-WAN or tunnels into the same security cloud |
| Capacity planning | Concentrator size and head-office bandwidth | The provider's cloud; your links at each site |
| Typical licensing | Per appliance or concurrent user, plus support renewals | Per user by component, plus per site for branch connections |
The labels hide some overlap: Cisco, for example, includes a VPN as a service in Cisco Secure Access (opens in a new tab) for applications that are not ready for ZTNA, so a SASE platform can carry legacy access during the move.
Still not sure which way to go? Ask us
Tell us what matters most to you and we will recommend one, with the trade-offs explained.
Why VPN backhaul becomes the problem
Most VPN complaints come from the backhaul rather than the encryption:
- Slow SaaS and video calls, because Microsoft 365, CRM and meeting traffic takes a detour through head office and back out.
- Head-office bandwidth and concentrator capacity, which have to be sized for everyone working remotely at once.
- Split tunnelling as a workaround, which speeds things up by sending internet traffic direct, but leaves that traffic outside the office firewall's filtering.
- Broad access once connected, which the NCSC lists among its ZTNA anti-patterns: VPN access with wide network connectivity is a legacy route that bypasses per-application policy.
SASE answers all four at once, which is why VPN renewals and concentrator end-of-life dates are a common trigger for a SASE project.
When ZTNA alone is enough
Not every VPN replacement needs full SASE. ZTNA on its own fits when:
- Remote users need a handful of internal applications, such as a finance system, a file server or remote desktop.
- Most other work is already in SaaS and protected by your identity provider's conditional access.
- Web filtering for remote users is either already handled on the device or not part of this project.
In that case, a ZTNA product replaces the VPN for private access and internet traffic carries on as before. ztna.org.uk covers that route in detail: ZTNA vs VPN (opens in a new tab) compares the two, and its guide to VPN replacement options (opens in a new tab) walks through the project.
SASE (or a Security Service Edge (SSE) as a first step) is the better fit when web and SaaS traffic is currently filtered by backhauling it through the office, when you need CASB or data controls for SaaS and AI tools, or when branch networking is changing at the same time. See ZTNA vs SASE for the layers side by side.
Weighing up the options?
We can compare them against your own requirements and recommend what fits.
How the platforms we supply replace the VPN
| Platform | Instead of the VPN | Also included |
|---|---|---|
| Cisco SASE | Cisco Secure Access: ZTNA, plus VPN as a service for apps that are not ZTNA-ready | Internet and SaaS protection; Cisco SD-WAN or Meraki SD-WAN (opens in a new tab) for sites |
| Check Point SASE | Private Access | Internet Access, SaaS Security and SD-WAN |
| Barracuda SecureEdge | Zero Trust Network Access with least-privileged access to authorised apps | Firewall as a service, web security and Secure SD-WAN |
| WatchGuard SASE | FireCloud Total Access ZTNA, which WatchGuard positions as replacing traditional VPN set-ups | Firewall as a service and secure web gateway on one agent, managed in WatchGuard Cloud |
| Timus SASE | Always-on, zero-click access that Timus positions as a replacement for legacy VPNs | Dynamic cloud firewall, secure web gateway, dedicated static IPs for SaaS apps |
| Todyl SASE | An agent that tunnels to a regional point of presence of Todyl's Secure Global Network | Secure web gateway, secure DNS, next-generation firewall with SSL inspection |
Sources: Cisco Secure Access (opens in a new tab), Check Point SASE (opens in a new tab), Barracuda SecureEdge (opens in a new tab), WatchGuard's FireCloud Total Access announcement (opens in a new tab), Timus Networks (opens in a new tab) and Todyl SASE (opens in a new tab), checked 9 November 2026. Editions and add-ons vary by platform, so we confirm the exact components at quote.
What about site-to-site VPNs?
"SASE vs VPN" usually means the remote access VPN. Site-to-site VPNs between offices are a different case. In a SASE design, sites still connect over encrypted tunnels, but they run from the SD-WAN edge or site firewall into the security cloud rather than as a mesh of office-to-office VPNs, and the same policy covers sites and remote users.
Some platforms do this automatically: Cisco documents automated IPsec tunnels from Cisco Catalyst SD-WAN into Secure Access. Others accept standard IPsec from the firewall or router you already have. ztna.org.uk explains where ZTNA vs IPsec (opens in a new tab) each fit, and the branch options are on SASE vs SD-WAN.
Moving from VPN to SASE: a migration summary
- List the applications and who uses them. Private apps, SaaS, and anything with hard-coded IP addresses or unusual protocols that may need the legacy route for longer.
- Check identity and devices. SASE policy is only as good as the identity provider, MFA and device management behind it.
- Choose the scope. ZTNA only, Security Service Edge (SSE), or full SASE with SD-WAN, matched to your contract and renewal dates.
- Pilot with one group. Publish a few applications through ZTNA and turn on web protection for a pilot group while the VPN stays available.
- Move group by group. Extend policy, retire VPN profiles as each group moves, and keep a narrowly scoped route for anything legacy.
- Close the inbound VPN service. The NCSC warns that legacy access routes left in place bypass the policy engine, so finish by removing them and tightening any that must stay.
The NCSC's first ZTNA anti-pattern (opens in a new tab) is swapping a VPN for a Security Service Edge (SSE) or SASE while keeping the old access model, so the per-application policy step matters more than the product. The full plan, including phasing and cut-over, is on SASE implementation.
Licensing without the VPN
VPNs are usually licensed per appliance or per concurrent user, with support renewals on the concentrator. SASE platforms are usually licensed per user by component (private access, internet access, CASB or data controls), plus per site for branch connections or SD-WAN. That means you can buy private access first and add the rest later, and the VPN's renewal date is often the natural point to switch.
Subscriptions can be billed monthly, terms confirmed at quote. Pricing depends on users, components, sites and term, so ask us for a quote.
How Forever Systems helps
We supply several SASE and ZTNA platforms, so we can recommend the one that fits your applications, devices and sites rather than one product for every case. We can review your current VPN, firewall and remote access set-up, show whether ZTNA alone covers the need or whether SASE belongs in the same project, run a pilot with a small group where the vendor offers a trial, and plan the cut-over around your renewal dates. Scope and timescales are confirmed at quote. Contact us to talk through your VPN replacement.
How Forever Systems helps with SASE
Forever Systems supplies several SASE and Security Service Edge (SSE) platforms, so we can recommend the one that fits your sites, your people and the network and security kit you already run.
- Assess first: we look at your current VPN, firewalls, WAN links and identity set-up, and the applications people need to reach
- Help you choose: single-vendor or dual-vendor SASE, or Security Service Edge (SSE) first and SD-WAN later, matched to what you need now
- Pilots and phased roll-out: we can help you start with one group of users or one site, then extend policy step by step
- Licensing in one place: subscriptions can be billed monthly, with terms confirmed at quote
We work with businesses, schools, charities and public sector organisations. Pricing depends on users, sites, components and term, so ask us for a quote.
Frequently asked questions
Does SASE replace a VPN?
Yes, for remote access. The ZTNA part of SASE gives users access to named private applications without putting them on the network, and the Security Service Edge (SSE) part protects their web and SaaS use without backhauling it through the office.
Is SASE more secure than a VPN?
It reduces exposure in two ways: there is no inbound VPN service on your firewall for private apps, and users reach only the applications their policy allows. Security still depends on good identity, device checks and removing old access routes.
What is the difference between SASE and a VPN?
A VPN connects a device to a network. SASE connects a user to specific applications and inspects their internet and SaaS traffic in a provider's cloud, with SD-WAN for branch offices under the same policy.
Do I need SASE or is ZTNA enough to replace our VPN?
If remote users only need a few internal applications and web filtering is not part of the project, ZTNA may be enough. If web traffic is currently filtered by backhauling it through the office, a Security Service Edge (SSE) or full SASE fits better.
Can we keep the VPN during the move to SASE?
Yes, and most organisations do. Keep the VPN for groups and applications not yet moved, scope it narrowly, and close the inbound service once everyone has moved.
Still deciding?
Ask us and a member of our team will get back to you.