SD-WAN security, segmentation and SASE
In short: SD-WAN encrypts all overlay traffic with IPsec and separates groups with segments. When branches send internet traffic straight out, each site needs firewall and web protection, either on the edge device or from the cloud. SASE combines SD-WAN networking with cloud-delivered security for every site and user.
Built-in protection
- Encryption: overlay tunnels use IPsec, so traffic is protected even over the public internet. Keys are managed and rotated by the controller.
- Device trust: edges authenticate to the controller with certificates before joining.
- Segmentation: separate virtual networks (VRFs or segments) for staff, guests, payment systems and IoT, kept apart across the whole WAN.
Securing local internet breakout
When branches send internet and SaaS traffic directly out instead of via head office, the head-office firewall no longer sees it. Each site needs equivalent protection:
- A next-generation firewall with intrusion prevention, built into the SD-WAN edge, or
- Cloud security services that branch traffic passes through, or
- A mix: on-box firewall for basic control, cloud services for deep inspection.
Common controls: URL filtering, DNS security, malware scanning, TLS inspection where policy allows, and logging to a central SIEM.
SASE and SSE
SASE (secure access service edge) delivers networking and security together as a cloud service close to users. Its security half is often called SSE (security service edge):
| Service | What it does |
|---|---|
| SWG (secure web gateway) | Filters web traffic and blocks malicious sites and downloads |
| CASB (cloud access security broker) | Controls and monitors use of SaaS applications and data in them |
| ZTNA (zero trust network access) | Gives users access to specific private apps after verification |
| FWaaS (firewall as a service) | Cloud firewall for all sites and users |
The same policy then protects a branch, a home worker and a phone on public Wi-Fi.
Migrating from MPLS to SD-WAN
- Audit sites, links, applications and current costs.
- Choose the architecture: on-box security, SASE, or a mix.
- Build a pilot at two or three sites, keeping MPLS in place.
- Add broadband or 4G links and move non-critical traffic first.
- Roll out in waves, measuring application performance.
- Reduce or retire MPLS circuits when SD-WAN has proven itself.
Common mistakes
- Two internet links from the same provider over the same cable: no real resilience.
- Opening local breakout before branch security is ready.
- Copying old routing complexity into the new overlay instead of simplifying.
- Skipping training for the operations team.
Real-world example: securing local breakout
A fictional charity with 15 regional offices moved to SD-WAN so that each office could reach its cloud email and file storage directly instead of through head office. In the first week a staff member at one office clicked a link to a fake login page, which the old central web filter would have blocked. The office had direct internet access but no web protection of its own. The IT manager quickly enabled the edge devices' built-in firewall and DNS filtering at every site, then moved to a cloud-delivered secure web gateway and zero trust access as part of a wider SASE plan. Head office and branch users now have the same protection.
Practice
Why does local internet breakout need extra security at the branch?
Name the four main services usually found in SSE.
What is the first step of an SD-WAN migration?
Key takeaways
- SD-WAN encrypts the overlay with IPsec and authenticates devices with certificates.
- Segments keep staff, guests, payments and IoT apart across the WAN.
- Local breakout needs branch firewalls or cloud security.
- SASE = SD-WAN + SSE (SWG, CASB, ZTNA, FWaaS) delivered from the cloud.
- Migrate in waves, keeping MPLS until the new design is proven.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.