SD-WAN manages how traffic travels between branches, data centers, and cloud services. SASE combines networking with security services for users, devices, and applications. SD-WAN can therefore be part of SASE; buying SASE does not automatically require replacing a working SD-WAN deployment.
For a branch network, the practical question is what to keep, where to inspect traffic, and which routes should change. Start with application requirements and failure behavior before choosing an appliance or signing a bundled contract.
SD-WAN vs SASE: the difference
| Dimension | SD-WAN | SASE |
|---|---|---|
| Main job | Manage WAN connectivity and application traffic paths | Combine connectivity with access and security policy |
| Typical networking concerns | Routing, link selection, segmentation, quality of service | Those WAN concerns plus paths into security enforcement |
| Security scope | Depends on included features and integrations | Commonly includes SWG, CASB, ZTNA, and cloud firewall services |
| Branch equipment | Physical or virtual WAN edge | Existing edge, vendor appliance, or supported tunnel integration |
| Physical connectivity | Uses underlying circuits | Still requires underlying circuits |
| Buying decision | Does this solve our WAN requirements? | Does the combined design meet networking and security requirements? |
MEF describes SD-WAN as an overlay operating over underlying connectivity services. Its framework includes policies for classifying application flows, forwarding them across transports, and internet breakout. That distinction matters: a new overlay does not create a new last-mile connection. MEF SD-WAN service framework.
SASE broadens the architecture to combine network connectivity and security. Implementation can involve one provider or multiple integrated components; a product label alone does not establish how consistently those components operate. Cloudflare's SASE explanation.
If your question is whether to add cloud security while leaving the WAN intact, read our SSE vs SASE guide. This guide focuses on branch routing and the WAN transition.
Map the traffic before changing the WAN
Build an application inventory with four destinations: internet and SaaS, private data-center applications, cloud workloads, and other branches. Add local services that must remain available during a WAN outage, such as printing or a site-specific controller.
For every important flow, record its source, destination, protocol, identity requirement, current route, and inspection point. Include return traffic. A diagram showing only the outbound tunnel can hide asymmetric routing, changed source addresses, or an unreachable private DNS service.
An example branch might send employee browsing to cloud inspection, reach an ERP system through its existing WAN, and keep guest devices separated from corporate systems. The target design should explain all three flows. Sending employee browsing through a security cloud does not prove that ERP access or guest isolation works.
Keep, integrate, or replace: a branch decision matrix
The following matrix is our planning recommendation, rather than a vendor capability guarantee.
| Current situation | Sensible starting approach | What the pilot must prove |
|---|---|---|
| SD-WAN meets routing and resilience needs | Keep it; add supported cloud security integration | Correct steering, identity, inspection, and recovery |
| Branch equipment is approaching replacement | Compare an integrated SASE edge with SD-WAN plus SSE | Routing parity, appliance capacity, operations, and total cost |
| Small sites mainly use SaaS | Evaluate a simpler edge and cloud security design | Guest isolation, local dependencies, and circuit failover |
| Branches depend on private WAN applications | Preserve required routes during migration | Reachability, return paths, DNS, and application performance |
| Industrial devices require local control | Retain necessary local segmentation and enforcement | Device traffic policy and behavior during disconnection |
| Locations have unreliable last-mile access | Improve connectivity and resilience alongside security | Independent failure paths and usable backup capacity |
A retained SD-WAN can connect to security services through documented integrations. Cisco publishes an IKEv2/IPsec procedure for connecting Catalyst SD-WAN devices to Secure Access, with tunnel groups for redundancy. Its manual procedure also identifies routing and licensing prerequisites. Validate the specific integration and software versions you intend to use. Cisco tunnel documentation.
Cloudflare likewise documents connecting existing IPsec-capable routers, firewalls, and SD-WAN devices to its cloud network. These examples show that equipment reuse is possible in supported designs; they do not establish universal interoperability. Cloudflare SASE reference architecture.
Connectivity requirements that survive a SASE purchase
Keep circuit procurement separate from the platform decision. Check carrier availability, contract dates, repair commitments, public-address requirements, cellular coverage, and whether two links share physical infrastructure. Two invoices do not necessarily mean two independent failure paths.
Size for the complete traffic path. Record busiest-hour bandwidth, encrypted tunnel capacity, application latency, packet loss, and jitter. Evaluate with the security controls you plan to enable. A raw appliance throughput figure is insufficient evidence for inspected application performance.
Specify routing and local behavior. Confirm supported dynamic or static routing, overlapping address handling, IPv6 requirements, segmentation, and connectivity to private clouds. Decide which local services must continue when the security cloud cannot be reached.
Do not equate SASE with removing MPLS. Retain or retire a circuit according to application needs, resilience, geography, and commercial terms. Cato's documented site-to-site design includes its cloud transport alongside internet and MPLS transport options, illustrating that coexistence can be an explicit architecture choice. Cato site-to-site connectivity.
A phased WAN migration
Phase 1: establish the baseline
Select representative branches, including a challenging location. Record real application transactions, voice quality where relevant, routes, DNS behavior, security policies, and recovery from a circuit failure. Agree on acceptance thresholds with application owners before the pilot.
Phase 2: add the security path
Introduce the new service for a limited group or traffic class while keeping rollback available. Verify policy enforcement, identity attribution, certificate deployment, exceptions, and logging. Preserve certificate validation; handle application compatibility through documented policy rather than disabling trust checks.
Phase 3: test failures deliberately
Test loss of a primary link, a tunnel, and the selected cloud inspection path in an approved maintenance window. Confirm whether sessions recover, which applications stop, and whether traffic remains inspected. Document the recovery route and its security controls. Do not silently send sensitive traffic directly to the internet when inspection fails.
Phase 4: expand by branch type
Roll out the successful configuration to similar locations, then test the next branch category. Keep a named rollback owner and configuration backup. Retire legacy appliances and circuits only after their remaining dependencies and contractual obligations are resolved.
Buyer checklist for the proof of concept
Ask every shortlisted supplier to answer the same questions:
- Which existing edge models and software versions are supported?
- Which routing, segmentation, and addressing features remain available?
- What tunnel and inspected-throughput limits apply to our design?
- How are users identified behind a branch tunnel, including shared devices?
- Which traffic receives security enforcement, and which paths require separate controls?
- What happens during circuit, tunnel, cloud-region, and identity-provider failures?
- Can support trace a problem across the circuit, edge, tunnel, and security service?
- What are the costs for appliances, subscriptions, support, deployment, and parallel operation?
Use our SD-WAN and branch comparison and private backbone comparison to assemble requirements. Turn them into supplier questions with the RFP builder. Treat documented support as a starting point for validation in your own network.
Frequently asked questions
Does SASE replace SD-WAN?
It may replace your current product, retain it through integration, or deliver networking through a different service model. Decide based on supported traffic paths and operational requirements. SD-WAN's networking function remains relevant within many SASE architectures.
Can we keep branch firewalls?
Yes, where the target design needs local segmentation, inbound protection, or controls for traffic that never reaches cloud inspection. Document each retained function and its owner before removing equipment.
Will SASE make branch applications faster?
It can change paths and inspection locations, but results depend on connectivity, geography, application behavior, and policy. Compare actual transactions before and after the change. This article provides no measured performance or savings claim.
Should we choose one vendor for networking and security?
Evaluate whether shared policy, troubleshooting, and support improve your operations enough to justify migration. Also evaluate equipment reuse and supported integrations. Use identical acceptance criteria for both approaches.
Research scope
Reviewed October 13, 2026. Definitions and implementation examples use the primary documentation linked above. The migration matrix, pilot sequence, and checklist are SASECompare's planning guidance. We did not perform hands-on product tests for this article; features, licensing, and regional support require confirmation for your proposed deployment.