The main SD-WAN challenges are security at every branch exit, dependence on a central controller, poor visibility into the internet underlay, application identification errors, and skills for operating a new overlay. Each has a practical fix, but they tend to appear after rollout, so plan for them in the design.
Why do the challenges look different from MPLS?
NIST SP 800-215 describes SD-WAN as removing the tight coupling between the network's control plane and data plane, so policy is specified centrally. Its listed design goals include connectivity over any transport, application awareness that picks the best path by traffic type and load, integration of security and networking functions, and centralized visibility and management.
Each of those goals brings a corresponding burden. Central control means a central point of failure. Application awareness means classification that can be wrong. Multiple transports mean you manage paths you do not own.
What are the common challenges?
1. Security moves to every exit. With local internet breakout, inspection happens at each branch or in a cloud service. SP 800-215 describes secure web gateway functions, firewalls and cloud access controls as pieces that may be embedded in the edge or delivered separately. If the choice is not made, branches go online with no filtering.
2. The controller is a prime target. One console can change policy everywhere. Treat it as critical infrastructure with multi-factor authentication, restricted access and change review.
3. The underlay is a black box. The overlay can look healthy while a broadband provider drops packets. Without underlay monitoring, you chase the wrong fault.
4. Application identification errors. Path selection depends on recognizing applications. Encrypted traffic and frequently changing cloud services can be misclassified, so a video call ends up on the wrong path.
5. Mixed transports behave differently. MPLS, broadband, LTE and 5G differ in latency, jitter, loss and cost. A policy that suits one can hurt on another.
6. Operational skills. Teams used to router command lines now manage templates, orchestration and APIs. Without training, changes go wrong at scale.
7. Interoperability and exit. Overlay features differ between products, so moving off one platform later can mean redesigning policies. Check how configuration can be exported before you commit.
A constructed example
A retailer with 40 stores finds, after rollout, that card payment terminals time out in the evening. The overlay dashboard shows green. The cause is an overloaded cable broadband line in several stores, where a backup process saturates upload bandwidth. Only underlay monitoring plus an application priority policy fix it. No change to the SD-WAN platform alone would have.
How do you handle them?
- Security: decide where inspection lives per traffic class, and test it before each wave of sites.
- Controller: apply multi-factor authentication, role-based access, source network limits and reviewed changes.
- Underlay: monitor each circuit's latency, loss and jitter directly, with alerts per site.
- Classification: test business critical applications on each path, and keep an override list.
- Transports: define per-application policy, such as keeping voice off metered LTE unless needed.
- Skills: train staff and practice a rollback in a lab.
- Exit: keep configuration documented in vendor neutral form.
Which challenge should you tackle first?
Start with the controller and the branch exit, because those are the two places where one mistake affects every site. Next fix visibility: without underlay monitoring you will spend days diagnosing faults that a single graph would explain. Leave fine tuning of path selection for last, since it only pays off once the basics are stable. A useful rule is to run a monthly review of tickets tagged to the WAN and ask which of the seven challenges each one belongs to. After a quarter, the pattern shows where to invest.
How to check or apply this
- List your top ten applications and the path each should take on each transport.
- Confirm where security inspection happens at every site type.
- Harden controller access and put changes under review.
- Add per-circuit monitoring independent of the SD-WAN platform.
- Run a failover test per site type during working hours.
- Document policies so you could rebuild them elsewhere.
Quick check
Does SD-WAN remove the need for a firewall at the branch?
No. Security functions can be built into the edge or delivered from the cloud, but each exit needs some enforcement.
Why monitor the underlay separately?
Because the overlay reports on tunnels, not on the quality of the provider links beneath them. Faults there look like application problems.
Sources
Last reviewed: 18 October 2026.
