Vendors talk about SD-WAN and SASE security like they're the same purchase decision. They aren't, and that mix-up has real costs. A lot of IT teams assume they've already covered SASE the moment they sign an SD-WAN contract, when they've really only bought one piece of it.

This article clears up two things: what SASE security actually includes, and exactly where SD-WAN sits inside it. You already know what SD-WAN and network security do on their own, so we won't re-explain the basics here. This is a correction, not an introduction.

Start with the part vendors blur together: SASE isn't one product. It's built from two distinct halves.

What Is SASE Security?

SASE, short for secure access service edge, combines networking and security functions into one cloud-delivered model instead of a rack of separate appliances at every location. Instead of backhauling traffic to a data center and then adding firewalls, VPN concentrators, and web filters one at a time, SASE delivers those functions from the cloud, closer to wherever the user actually is. That's the real shift: stacked hardware becomes a converged service.

For security specifically, this changes what “protected” means. Policy follows the user or device, not a fixed office location, so a remote employee, a branch office, and a contractor on a public connection all get evaluated against the same rules.

It's worth being precise here: SASE is a model, not a single product you buy off a shelf. No one box does all of this. Vendors package the pieces differently, which is exactly why the SD-WAN and SASE security terms get blurred together in the first place.

That model is really two halves working together. Here's what's in each one. 

Where SASE Adoption Stands in 2026

The 2023 version of this topic leaned on a single gated report and its own survey data. Three years on, that data is stale, so here's where the market actually stands. Analysts across multiple research firms report continued rapid SASE growth, though the exact size estimates vary by methodology.

MarketsandMarkets puts the market at approximately $19.2 billion in 2026, growing to roughly $68 billion by 2032 at a 28.8% CAGR. Mordor Intelligence estimates a smaller base, about $15.5 billion in 2026 climbing to $39.1 billion by 2031 at a 20.3% CAGR. Those numbers differ because the firms scope the category differently, not because one is wrong.

Here's what matters more than the exact figure for anyone weighing a SASE approach right now:

• Consolidation is accelerating. Gartner projects that by 2026, 60% of new SD-WAN purchases will be bundled into a single-vendor SASE offering, up from just 15% in 2022. That's a shift from piecing together separate tools to buying one converged platform.
• The security half carries real weight. Multi-year forecasts from Dell'Oro Group put SSE, the security side of SASE, at more than half of SASE revenue by 2030, even as SD-WAN revenue continues to grow at a double-digit rate. Either way, SD-WAN is one part of a security-led model, not the whole story. 
• AI is entering the picture. Gartner also forecasts that generative AI will handle about 20% of initial SD-WAN configuration work by 2026, up from close to zero just a few years earlier. Worth a mention, not a deep dive, since this article is scoped to the SASE and SD-WAN relationship.

That's the direction the market's moving. The framework itself is still built from the same two halves.

The SASE Framework: Networking and Security in Two Halves

Every SASE framework you'll see described the same way once you strip out the vendor branding: one half moves traffic, the other half protects it. Networking and security used to be handled by separate tools bought from separate vendors on separate timelines. SASE folds them into one architecture instead.

That doesn't mean one half outranks the other. The two pieces below carry equal weight in the model, and skipping either one means you don't actually have SASE, you have half of it.

SD-WAN Handles the Networking Half

SD-WAN is the networking piece inside SASE: the transport layer that intelligently routes traffic across whatever connections you have available. If you're asking whether SD-WAN and SASE are the same thing, the direct answer is no. SD-WAN is what security gets layered on top of, not a replacement for that layer.

• Traffic routing: Picks the best path across multiple connections in real time, based on current performance rather than a fixed route.
• Multi-site connectivity: Links branch offices and remote users without requiring a dedicated circuit at every location.
• Standalone limitation: Runs fine on its own for connectivity, but without SSE layered on top, it isn't SASE. It's just SD-WAN.

In practice, that routing decision isn't static: the platform continuously checks each connection for loss, latency, and jitter, then shifts individual application traffic to a healthier path in the background rather than waiting for a connection to fail outright. If you want to go deeper on how this piece actually works, it's worth reading up on how Cisco SD-WAN routes traffic across a multi-site network, since that's the platform Hummingbird Networks deploys most often for this half of the model.

SSE Handles the Security Half

SSE, or security service edge, is the half that carries the actual protection: zero trust network access, secure web gateway, cloud access security broker, and firewall-as-a-service. These four pieces work together so that every connection, not just the ones coming through a branch office, gets inspected and controlled.

• ZTNA: Verifies user and device identity before granting access to an application, with no standing trust just because a device is on the network.
• Secure web gateway: Filters and inspects traffic before it reaches the user, wherever that user happens to be working.
• CASB: Extends visibility and control into the cloud apps your team already uses day to day.
• Firewall-as-a-service: Delivers firewall policy from the cloud instead of relying on a physical appliance at each branch.

In practice, that pairing shows up as Meraki access points and security appliances enforcing Cisco Umbrella's DNS-layer policies directly, so web filtering and threat blocking apply across every device on the network without a separate agent to install at each site. It's worth understanding how Meraki networking pairs with cloud-delivered security controls across a multi-site environment, since that's the practical version of the SSE half described above.

That's the model on paper. Here's why it stops being optional once you're running more than one site.

One Perimeter Doesn't Work Across Multiple Sites Anymore

Hybrid work and multi-site operations mean your users and traffic no longer sit behind one perimeter you can point to on a network diagram. A branch office, a home office, and a laptop on hotel Wi-Fi all need the same protection, and none of them are behind the firewall you bought for headquarters five years ago.

The practical risk shows up as inconsistent policy enforcement. One site gets the full security stack, another gets whatever was easiest to configure at the time, and a remote employee gets whatever their laptop happened to have installed. That gap doesn't stay small. It gets harder to close the more sites and the more remote users you add, because every bolt-on fix becomes one more thing to maintain separately.

For an overextended IT manager, that gap tends to surface at the worst possible moment: a cyber-insurance renewal audit flags a branch office that was never actually covered, or a post-incident review turns up a site nobody remembered to fold into the security stack. Cisco Meraki SD-WAN's built-in threat protection closes part of that gap, but it's still only the networking half of the fix.

None of this means ripping out what you already have. Start by checking where you actually stand.

Single-Vendor or Dual-Vendor: How to Choose the Right SASE Model

Once you accept that SASE security needs both halves, the next question is how to buy them. Two broad approaches exist. Single-vendor SASE means one vendor delivers both SD-WAN and SSE from one platform and one console. Dual-vendor, sometimes called best-of-breed, means pairing a preferred SD-WAN vendor with a separate SSE vendor.

Analyst guidance generally points single-vendor toward organizations that want operational simplicity and one console to manage. Dual-vendor tends to fit organizations with meaningful existing investment in a specific SD-WAN or SSE platform already, or a hard requirement for a specialist capability only one vendor provides. Neither path is automatically the “correct” SASE framework. The right one depends on what you're starting from.

• Existing investment: How much runway is left on your current SD-WAN or firewall contracts? A rip-and-replace rarely pencils out mid-contract.
• Team structure: If networking and security are still managed by separate people or teams, one console tends to cut coordination overhead.
• Specialist requirements: A hard requirement for one vendor's specific capability, a particular ZTNA feature or a compliance certification, can tip the decision toward dual-vendor.

For teams already running Cisco SD-WAN, the single-vendor path is usually the more practical starting point since it builds on what's already deployed instead of layering on a second console. That's especially true if Meraki SD-WAN is already routing traffic across your branches: adding Cisco's own SSE layer on top means one login and one support contract, instead of standing up a second vendor's console, licensing, and support process from scratch.

Whichever model fits, the next step is the same: know what you're actually starting from.

Check Your Current Setup Before Adding Anything New

Before you add anything new, audit what you already have for overlap and gaps. Most SMB networks already run some combination of SD-WAN and security tooling, just not tied together under one SASE framework yet. The goal isn't a full-stack replacement. It's finding the highest-risk gap and closing that one first.

• Identity vs. location: Is access control tied to who's actually requesting it, or just to where the request happens to come from?
• Coverage gaps: Does every branch and remote user get the same policy, or does enforcement vary depending on the site?
• Highest-risk first: Which gap causes the most damage if it's left alone? Start there instead of trying to rebuild everything at once.

If you're not sure where to start, it's worth checking how the Cisco Meraki acquisition has changed licensing and platform support for existing gear, since that's often exactly where coverage quietly falls out of sync. Specifically, check whether your current Meraki license tier already includes Cisco's newer SSE add-ons, since older per-appliance licenses purchased before the acquisition sometimes don't, and confirm your existing access points and security appliances are still on a supported firmware track rather than assuming coverage carried over automatically.

Talk to an SD-WAN and Security Specialist

Sorting out where your network stands against the SASE framework doesn't require a full rebuild on day one. It starts with a clear picture of what you're already running and where the highest-risk gap sits.

Contact us for a fast quote on Cisco Meraki SD-WAN and security options built around what you already have.