Why I Tell Clients to Start With SASE — Not SD-WAN

I've had this conversation more times than I can count. A client comes to us having already deployed SD-WAN across their estate, and now they want to layer on cloud security. What should be straightforward always turns into a rework project. Here's how I think about it and how to avoid the same trap.

There's a natural impulse, when modernising a network, to start with the connectivity problem. "Let's fix the WAN first, then we'll sort out security." I understand the logic. SD-WAN is tangible, the performance wins are immediate, and security feels like something you can bolt on later. But that sequencing almost always costs more in the long run. Here's why I almost always recommend leading with SASE instead.

SASE is the architecture; SD-WAN is just one piece of it

SASE (Secure Access Service Edge) is a cloud-delivered framework that brings together networking and security into a single unified model. SD-WAN handles the transport layer. But SASE also includes Secure Web Gateway, CASB, Zero Trust Network Access, and more. It's the whole system, not just the pipes.

When you deploy SD-WAN first, you're solving connectivity. That's valid but you're not designing a security architecture. When you start with SASE, security is baked into the design from day one, and SD-WAN simply becomes the transport mechanism within that framework rather than the foundation everything else has to accommodate.

The rework problem is real. A pattern I see constantly. Deploy SD-WAN appliances everywhere, add cloud security later, discover the two don't integrate cleanly, end up with extra vendors, complex routing policies, and redundant hardware. It's expensive, and it's avoidable.

The issue isn't that SD-WAN is a bad product. It's that SD-WAN vendors and security vendors have different design assumptions, and reconciling them after the fact is messy. Starting with a SASE architecture means you're selecting for tight integration from the outset, and your future migration path stays clean.

Security shouldn't be backhauled to a data centre

Traditional SD-WAN deployments often route traffic back through a central data centre for security inspection. In a world where your users are in coffee shops and your applications live in Azure, that's a recipe for latency, poor SaaS performance and inefficient access (VPN Clients and Multiple identities).

A SASE-first approach puts security in the cloud, distributed close to your users. They connect directly to applications with security enforced at the edge no hairpin routing, no performance penalty.

The modern workforce has outgrown SD-WAN's original design assumptions

SD-WAN was built for branch-to-branch and branch-to-data-centre connectivity. That made perfect sense a decade ago. Today, your environment is remote users on personal devices, SaaS-first applications, and cloud workloads distributed across regions.

SASE treats users, devices, and locations as first-class citizens equally. Whether someone is in the office, at home, or in an airport lounge, the same security policies apply consistently. SD-WAN alone doesn't give you that.

Fewer vendors, less operational drag

One of the most underrated benefits of SASE is what it does to your vendor landscape. SD-WAN-first deployments tend to accumulate: one vendor for the WAN, another for VPN, another for CASB, another for firewall. Each has its own console, its own support contract, its own renewal cycle.

SASE consolidates this into a single policy framework. Your team spends less time managing integrations and more time on things that actually matter.

It aligns naturally with Zero Trust

If Zero Trust is on your roadmap (and it should be) SASE is the natural path there. It natively supports Zero Trust Network Access: every connection is verified, every time, based on identity and context rather than network location. SD-WAN alone still leans heavily on network-based trust models — IP addresses, location assumptions. That's increasingly the wrong model for how threats actually move. Anyone seeking to achieve compliance to the NCSC CAF and it’s Zero Trust Architecture principles: https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles - needs to be taking this approach.

When SD-WAN-first still makes sense

There maybe situations where leading with SD-WAN is the right call: you have an urgent WAN performance problem that needs solving now, your existing security stack is already strong and well-integrated, or budget and organisational structure genuinely separate networking and security into different programmes with different timelines. Those are real constraints. But go into it knowing the integration work that lies ahead and plan for it.

To COnCLUDE

SD-WAN first is a myopic "Let's fix the pipes" approach. SASE first "Let's design the whole system; pipes, locks, rules and future". Starting with SASE means your SD-WAN deployment fits into a future-ready architecture from the start and you won't be paying to redesign it in two years' time.

SD-WAN first

Solves connectivity quickly

Security added later

Integration rework likely

Vendor sprawl grows

Backhaul still common

SASE first

Secure connectivity by design

SD-WAN as built-in transport

Future-proof and tackles the identity (AI) challenge.

Tight integration from day one

Single policy framework

Cloud-native, no backhaul

Enquire Now

One of our experts will be in touch shortly to better understand your requirements and challenges.