SD-WAN and SASE together

SD-WAN and SASE are usually bought separately, often from different vendors, and frequently at different times. That sequence creates a gap that is easy to miss and difficult to close afterwards.

The gap exists because the two technologies solve halves of the same problem, and splitting them means nobody owns the join.

Why they belong together

SD-WAN changes where traffic goes. Its main benefit at branch sites is direct internet breakout, sending cloud-bound traffic straight out rather than backhauling it to a central data centre.

That is a performance improvement and a security change. Traffic that was previously inspected by the central firewall stack now leaves the branch directly, inspected by whatever is at the branch. Frequently, that is much less.

SASE is the answer to the question SD-WAN creates. It provides the security inspection (web filtering, threat prevention, data loss prevention, access control) delivered from cloud points of presence rather than from appliances in your data centre, so it can be applied wherever the traffic actually leaves.

Deploy SD-WAN without SASE and you have improved performance by removing inspection. Deploy SASE without SD-WAN and you have inspection, but the traffic still takes a poor path to reach it.

What the split creates

Two policy models

The SD-WAN vendor has a policy engine for path selection and traffic steering. The SASE vendor has one for security inspection. Both describe traffic, using different vocabularies and different grouping concepts.

Keeping them consistent is manual work that nobody is assigned. Over time they diverge, and the divergence is where traffic escapes inspection. A path rule sends a category of traffic somewhere the security policy does not cover.

Ambiguity about what is inspected

With one system, you can answer what happens to a given flow. With two, the answer depends on how the steering policy and the security policy interact, and reconstructing that requires reading both.

The specific failure is traffic that the SD-WAN sends direct while the security policy assumes it is being backhauled. It works, it is fast, and it is uninspected. Nothing alerts, because from each system's own perspective everything is behaving correctly.

Troubleshooting across a boundary

A user reports a slow application. Is it path selection or security inspection? Two consoles, two support relationships, and a strong tendency for each vendor to attribute the problem to the other.

This is a daily operational cost rather than a security risk, and it is the one teams complain about most.

Failure modes nobody designed

What happens when the SASE service is unreachable from a branch? Two options: fail open, and traffic flows uninspected; or fail closed, and the site loses internet access.

Both are defensible. Neither should be discovered during an incident. When the two systems come from one vendor, this behaviour is usually a documented configuration choice. When they are separate, it is often an emergent property nobody chose.

If you are buying both

Buy them together, or at least design them together. Even if procurement is separate, the design should be one design. Decide the traffic categories once and express them in both systems from the same source.

Establish the enforcement point per traffic type explicitly. For each category (internal applications, sanctioned cloud services, general web, guest traffic), write down where it goes and what inspects it. This table is the artefact that prevents the gap, and it is a page long.

Define the failure behaviour deliberately. Per site if necessary. Write it down and test it.

Insist on integration evidence, not integration claims. Most vendors claim to work with most others. Ask specifically: does policy synchronise, or is it maintained twice? Is there shared visibility, or two dashboards? Can a single flow be traced end to end?

If you already have SD-WAN and are adding SASE

This is the common position, and the work is mostly reconciliation.

Audit what is currently breaking out directly. Not what the policy says, but what is actually happening. Export the traffic distribution per site and compare against what you believe is inspected. The gap is usually larger than expected and it is the reason to do this first.

Map the existing security policy onto the new enforcement points. Rules written for a central firewall do not always translate cleanly to distributed inspection. Some depend on source addresses that no longer mean the same thing.

Migrate a site at a time. Start with one that is representative but not critical. Compare user experience and inspection coverage before and after.

Reduce the policy sources to one. Wherever the tooling allows it, drive both systems from a single definition. Where it does not, at least keep one authoritative document and a review that checks the two systems against it.

The question worth asking first

Before either purchase, ask what happens to traffic from a branch when it is destined for a cloud application.

If the answer involves the words "it depends", find out what it depends on. That is where the gap lives, and it is much cheaper to find in a design discussion than in a post-incident review.