SD-WAN and SASE Explained: The Future of Enterprise Networking

In 2019, I was helping an enterprise client rationalize their WAN architecture. They had 47 branch offices, each connected via MPLS circuits to a central data center. Every bit of internet traffic from every office hairpinned through that data center before going out to the internet. SaaS applications like Office 365 were a disaster: a video call in their Phoenix office went to Chicago, out to the internet, to Microsoft’s servers, back to the internet, back to Chicago, and then down to Phoenix. Latency was absurd. The MPLS contracts were multi-year, expensive, and completely inflexible.

That client is now fully SD-WAN deployed. Their Phoenix office connects directly to the internet with local breakout, the traffic policy enforces what goes where automatically, and they pay a fraction of what they used to for MPLS. The story of the last five years in enterprise networking is largely this story: the move from rigid, expensive MPLS-centric architectures to flexible, cloud-aware SD-WAN and SASE architectures. Let me explain how these technologies actually work.

What Traditional WAN Looks Like and Why It Breaks

A traditional enterprise WAN connects geographically distributed offices using dedicated circuits, typically MPLS from a carrier. MPLS (which I covered in the MPLS deep dive) gives you traffic engineering, quality of service, and reliable private connectivity. In the era when all your applications ran in your data center, this made sense. Traffic went office to data center, data center to office. The hub-and-spoke model matched the application architecture.

Then SaaS happened. Office 365, Salesforce, Workday, Zoom. Suddenly 60-80% of enterprise traffic was destined for the internet, not the data center. But the WAN architecture didn’t change. You still sent all traffic to the data center first, then out to the internet. Security teams argued this was necessary for inspection and policy enforcement. They were right about the requirement but wrong about the solution.

The result: terrible performance for cloud applications, enormous load on data center internet links, and SaaS vendors designing around the latency by caching aggressively and advising customers to break out locally. The architecture was fighting the application reality.

SD-WAN was built to fix this.

How SD-WAN Works

Software-Defined WAN applies the principles of software-defined networking to the WAN. The core idea is separating the control plane (where policy decisions are made) from the data plane (where packets actually flow).

In a traditional WAN router, both happen on the box. The router makes routing decisions locally based on its routing table and static configuration. Changing policy means logging into every router at every site and making changes. With hundreds of sites, this is painful and error-prone.

In SD-WAN, there’s a centralized controller that holds all the routing intelligence and policy. Individual SD-WAN edge devices at each branch site are relatively simple, handling packet forwarding according to policies pushed from the controller. When you want to change traffic policy across all sites, you change it once in the controller and it propagates everywhere.

The edge devices create virtual overlays across whatever physical transport is available: MPLS, broadband internet, 4G/5G LTE, or combinations. The controller monitors the quality of each path continuously, measuring latency, jitter, packet loss, and bandwidth. Traffic is steered to the best path for its type. Video conferencing traffic (sensitive to jitter) gets routed differently than file backup traffic (can tolerate latency). This is application-aware routing, and it works.

Local internet breakout is the other key capability. SD-WAN can identify traffic destined for specific cloud applications (by looking at IP ranges, domain names, or application signatures) and send it directly to the internet from the branch site rather than backhauling it to headquarters. That Phoenix office’s Microsoft Teams calls now go directly to Microsoft’s nearest point of presence, not on a tour through Chicago.

The Security Problem SD-WAN Creates

Here’s the uncomfortable truth the SD-WAN vendors didn’t advertise prominently at first: local internet breakout creates a security problem.

When all traffic went through the central data center, your security stack lived there. Firewalls, web proxies, IDS/IPS, DLP, sandboxing, all centralized. The hairpin was bad for performance but good for consistent policy enforcement.

With local internet breakout, you’ve moved the traffic away from your security stack. Now you have three bad options: put a full security stack at every branch site (expensive and complex), backhaul security-sensitive traffic anyway (defeats the performance purpose), or have no security inspection on local breakout traffic (terrifying).

This is the gap that SASE was designed to fill.

What SASE Actually Is

SASE (Secure Access Service Edge, pronounced “sassy”) is a framework coined by Gartner in 2019. The core idea: converge SD-WAN networking capabilities with network security services into a cloud-delivered service. Instead of putting security boxes at each branch, or backhauling to a central security stack, you route traffic to the nearest cloud-hosted security point of presence (PoP), get it inspected and filtered there, and then send it on its way.

A full SASE stack includes:

Cloud-delivered secure web gateway (SWG): URL filtering, malware scanning, SSL inspection, all happening in the cloud PoP rather than at the branch or data center. Traffic from your Phoenix branch hits a Phoenix-area PoP, gets inspected, and proceeds to the internet with minimal added latency.

Cloud Access Security Broker (CASB): Visibility and control over SaaS applications. Which users are using which apps, what data is being uploaded or downloaded, policy enforcement on sanctioned and unsanctioned applications.

Zero Trust Network Access (ZTNA): Remote access that enforces zero-trust principles. Instead of a traditional VPN that gives remote users broad network access after authenticating, ZTNA grants access only to specific applications based on user identity, device posture, and other context. This connects tightly to the zero trust security model I’ve written about before.

Firewall as a Service (FWaaS): Full Layer 7 firewall capabilities delivered from the cloud, so you get consistent policy enforcement regardless of where the traffic originates.

SD-WAN (the networking layer): Because it’s not just security: you still need the traffic steering, path optimization, and WAN management capabilities.

The promise of SASE is one vendor, one console, consistent policy across all users and locations whether they’re in a branch office, working from home, or in a coffee shop. Whether you get that in practice depends heavily on which vendor you choose and how mature their platform is.

SD-WAN vs. SASE: What’s the Difference

People use these terms interchangeably and they shouldn’t. Here’s how I think about it:

SD-WAN is the networking layer. It handles transport, path selection, QoS, and WAN optimization. Pure SD-WAN solutions (older generation Viptela, Silver Peak before the acquisitions) were networking products that didn’t include security.

SASE is the converged framework. It includes SD-WAN as a component but wraps it with cloud-delivered security services. SASE without SD-WAN is just a cloud security service. SD-WAN without the SASE security layer is just a better WAN.

Most of the industry conversation has moved to SASE because enterprises want the converged approach. The pure SD-WAN vendors either got acquired (Viptela by Cisco, Silver Peak by HP/Aruba) or pivoted to add security (VeloCloud adding Zscaler integrations, then the Broadcom acquisition mess).

The major SASE platforms today are Zscaler (market leader on the security side), Palo Alto Networks Prisma Access, Cisco Secure Access, Fortinet Secure SD-WAN plus FortiSASE, and Cloudflare One. Each has different strengths: Zscaler is best in class for security but weaker on SD-WAN; Fortinet has excellent SD-WAN and is catching up on security; Cloudflare has global edge infrastructure and a strong developer orientation.

The MPLS Replacement Question

The question I get most often from enterprise network architects: “Can we replace MPLS with SD-WAN?”

The short answer is yes, for most use cases. I’ve helped three large enterprises go from full MPLS to SD-WAN over broadband, and the outcomes have been positive. You get better performance for cloud applications, lower cost (broadband is dramatically cheaper than MPLS per Mbps), more flexibility (adding a site takes days instead of months), and better visibility into application performance.

The longer answer: MPLS still has advantages for latency-sensitive applications between sites. If you’re running real-time manufacturing automation or trading systems that need sub-5ms latency between specific locations, broadband-based SD-WAN with its variable latency may not meet your requirements. In those cases, a hybrid approach makes sense: SD-WAN managing both MPLS and broadband paths, using MPLS selectively for the most sensitive flows.

The cost math usually looks like this: MPLS circuits at enterprise scale run $500-2000 per Mbps per month. Broadband runs $1-10 per Mbps per month. You can buy a lot of broadband redundancy with the savings, and SD-WAN’s multi-path capability means you’re not worried about a single circuit failure.

The routing protocols perspective matters here too. MPLS with BGP gives you guaranteed path characteristics. SD-WAN’s application-aware routing gives you adaptive path selection that optimizes in real time. For most application traffic, the SD-WAN approach actually delivers better quality because it reacts to current conditions rather than following static routes.

Implementation Realities

Here’s what the vendor slides don’t tell you.

Migration is hard. Going from MPLS to SD-WAN requires careful planning, usually site-by-site migration with a period of dual connectivity. You need to understand your application traffic patterns before you configure traffic policies, not after. I’ve seen projects where the team configured policies based on assumptions about traffic and then discovered that their ERP system communicated in ways that needed rethinking.

Security integration takes real work. Connecting your SD-WAN to a SASE security layer isn’t plug-and-play even when you’re buying from the same vendor. SSL inspection breaks many applications until you fine-tune bypass policies. Identity integration with your IdP (Azure AD, Okta) needs careful configuration. The zero-trust posture checking (is this device compliant? is it running the right OS version?) requires MDM integration that IT may not have in place.

Visibility is a selling point but requires work. Every SD-WAN vendor shows you beautiful dashboards with application visibility and path quality metrics. Getting that visibility requires accurate application classification, which means the SD-WAN signatures need to match your application portfolio. Custom applications, especially internal ones, often need manual classification.

Dual connectivity periods cost money. During migration, you’re paying for both the old MPLS circuits (you can’t cancel mid-term) and the new SD-WAN infrastructure. Budget for 3-6 months of overlap per region.

Internet diversity matters more now. When you’re relying on broadband for WAN connectivity, carrier diversity is critical. Don’t put two circuits from the same provider into your SD-WAN thinking you have redundancy: a provider outage takes both down. Use two different last-mile providers, ideally with different physical infrastructure.

When to Pursue SASE vs. When to Wait

SASE makes sense when you have significant cloud application usage, distributed branches or remote workers, and a desire to consolidate your security stack. If you’re running mostly legacy on-premises applications through a data center, SASE’s benefits are much smaller.

The multi-cloud strategy angle matters: if you’re using multiple cloud providers and SaaS vendors, consistent security policy across all of them is genuinely hard without a cloud-delivered security layer. SASE solves this well.

For remote access specifically: SASE’s ZTNA component is a compelling replacement for traditional VPN. The always-on, identity-aware access model is more secure and usually performs better than a VPN concentrator that becomes a bottleneck at scale. This is the area where I’d prioritize if I were starting a SASE deployment: replace VPN first, add branch SD-WAN as circuits renew.

The enterprise networking landscape in 2026 is clearly moving toward converged SD-WAN and SASE. The pace of that migration varies, but the direction is not in question. MPLS-only architectures are in maintenance mode, and the organizations that haven’t started the conversation yet are increasingly the exception rather than the rule. Understanding the architecture helps you navigate the vendor landscape and make decisions that will serve you for the next decade.

The key lesson from every deployment I’ve been involved with: treat this as a network re-architecture project, not a technology swap. The technology is mature. The hard part is understanding your traffic, your security requirements, and your operational model, then designing an architecture that serves all three. Get that right, and SD-WAN and SASE deliver everything the vendors promise.