SASE explained: why it's hitting a tipping point in 2026

01.What SASE actually is

The name is clumsy, but the idea is simple. Instead of routing every user through your own appliances, you connect them to a cloud edge close to them. That edge applies your security and network policy, then forwards the traffic to its destination.

A SASE service usually bundles several functions:

• Secure web gateway: filters internet traffic and blocks dangerous sites and downloads.
• Zero trust network access (ZTNA): connects users to specific apps rather than to a whole network.
• Firewall-as-a-service: network firewalling delivered from the cloud.
• SD-WAN: links branch sites over ordinary internet connections, with traffic steering.
• Cloud access controls and data protection, depending on the vendor.

The point is one policy, one console and one place to look when something goes wrong.

02.Why now

• Work and apps are outside the office. Staff work from home, from client sites and from airports. The apps they use are mostly in the cloud. The office is no longer the centre of the network.
• VPN backhaul slows everyone down. When a remote user must tunnel into head office to reach a cloud app that sits on the internet, traffic takes a long detour. Video calls suffer, files load slowly and users find ways around the VPN.
• Too many point tools to manage. Each tool has its own policy, console and renewal. Gaps and conflicts creep in. Each one needs a person who knows it.
• Zero trust needs identity-based access. The idea of trusting anyone inside the network no longer works. Access should depend on who the user is, the state of their device and what they are asking for. SASE is a practical way to enforce that.

03.What it looks like before and after

Before: a remote user starts a VPN client and connects to a concentrator in head office. All traffic goes through it. The user can reach most of the internal network. A set of appliances inspects traffic at the data centre. Branch sites have their own firewalls and links.

After: the user connects to a nearby cloud edge. Internet traffic is inspected there and goes straight to its destination. Internal apps are reached through ZTNA, one app at a time. Branch sites link through SD-WAN with the same policy. One team manages one set of rules.

04.How to approach migration

You do not need to switch overnight. A sensible path:

• Assess. List sites, users, apps, links, appliances and contracts. Note which apps depend on fixed IP addresses or old protocols.
• Design. Group users by role. Decide what each group may reach.
• Pilot. Choose a small team and run for a week or two. Fix profile and posture problems.
• Roll out in waves. Move by site or team. Brief users beforehand.
• Stabilise. Tune policy with real traffic, then retire the VPN and appliances you no longer need.

05.Things that catch people out

• Third-party allow-lists. Partners that trust your fixed IP address may block you after the move.
• Legacy apps. Some use protocols that do not suit ZTNA without extra work.
• Policy sprawl. Copying every old rule into the new platform carries old problems with you.
• User communication. People who are not told what is changing will raise tickets.
• Operations. A platform without a team that watches and tunes it drifts quickly.

06.The pieces in more detail

Secure web gateway. Every user's web traffic passes through the same checks, whether they are in the office or at home. It blocks known bad sites, filters categories you choose and scans downloads. The benefit is consistency. The cost is that someone must tune policy so legitimate work is not blocked.

ZTNA. Instead of joining a network, a user is connected to one application. The service checks who they are and the state of their device each time. If a laptop falls out of compliance, access can stop. For internal apps this is a large step away from the VPN model.

Firewall-as-a-service. The firewall moves from a box in the data centre to a cloud service. You lose some direct control over hardware and gain freedom from patching and capacity planning.

SD-WAN. Branch sites connect over ordinary internet links, with traffic steered by application and link quality. It often replaces costly private circuits, though you still need decent links at each site.

07.Build, buy or run it managed

Three routes are common. You can assemble the platform yourself, which gives control but needs skilled staff. You can buy a single vendor platform and run it in house, which cuts tools but still needs a team. Or you can use a managed service, which brings monitoring and policy management from a provider. Smaller IT teams usually choose the third route because 24/7 cover is hard to staff. Whatever you pick, decide who owns policy, who watches alerts and what the escalation path is before you sign.

08.A short pre-migration checklist

• List every site, link and appliance with its contract end date.
• List the apps users reach, and mark which are private and which are on the internet.
• Find anything that depends on a fixed source IP address.
• Group users by role and write down what each group needs.
• Choose a pilot team that includes at least one demanding user.
• Draft the user message and the help desk script.
• Agree rollback steps for each wave.
• Decide who owns policy changes and alert handling after go-live.

09.What to measure

Track tickets about access, time to connect, app response times, blocked threats and the number of VPN sessions still active. A falling VPN count tells you the migration is real. Rising tickets in one wave tells you to pause and look.

10.Is SASE right for everyone?

Not always. A small company with one office and a few cloud apps may need only a good firewall and single sign-on. A firm with heavy on-site systems, such as plant controls, will keep local security for those. SASE pays off most when you have many sites, many remote users and many cloud apps, and when your current tools are costly to run. Be honest about where you sit, and do not buy features you will not use.

11.Common mistakes

• Buying a platform before knowing what traffic you have.
• Migrating everyone at once.
• Leaving the old VPN running indefinitely, "just in case".
• Treating SASE as a network project only. Security, identity and support teams must be involved.
• Ignoring the contract calendar. Plan retirements against renewal dates to save money.

12.What to do next

Start with a traffic and app inventory. It will tell you what a pilot should include, what the awkward cases are and what you could retire. Then pick a pilot group and a first site.

Brandsmashers designs, migrates and runs SASE for mid-market companies. If you want help scoping a migration or checking a plan you already have, a short call is an easy first step.