Branch Office Connectivity: From MPLS to SD-WAN and SASE

Executive Summary

For any organization with more than one location — retail stores, clinics, regional offices, warehouses, or franchises — the network that ties those sites together is the difference between a coherent business and a set of disconnected islands. Branch office connectivity is the discipline of linking remote sites to headquarters, to data centers, to the cloud, and to each other, reliably and securely. It sounds like a solved problem, and for a long time it was solved the same way everywhere: an expensive private circuit, usually MPLS, running from each branch back to a central hub, with all traffic funneled through headquarters. That model was dependable, and it made sense when the applications people used lived in the company’s own data center.

Then the applications moved to the cloud. Email, files, collaboration, and line-of-business systems increasingly run as services on the internet rather than on servers at headquarters, and that single shift broke the old design. Sending a branch’s cloud traffic all the way to headquarters and back out to the internet — a detour often called “trombone routing” — wastes bandwidth, adds latency, and overloads the central link, all to reach an application that is nowhere near headquarters. Meanwhile, the cost of private circuits stayed high while ordinary broadband and cellular became fast and cheap. The result is a rethinking of branch connectivity around software: SD-WAN, which pools multiple inexpensive links and steers each application over the best path, and SASE, which delivers the security those direct connections now require from the cloud.

This vendor-neutral guide walks through modern branch connectivity end to end. It compares the WAN transport options and their trade-offs, explains why cloud adoption made local breakout necessary, shows how SD-WAN makes cheap links behave like a private WAN, sets out how to design branches for resilience, and describes how SASE converges connectivity and security into one cloud-delivered model. Grounded in the industry’s WAN standards and definitions, the goal is branch connectivity that is faster, more resilient, more secure, and dramatically cheaper to run than the private-circuit era it replaces.

The Transport Options

Every branch connection starts with a physical transport, and no single one wins on cost, performance, and reliability all at once — which is precisely why modern designs combine several.

The ways to connect a branch — each a different trade-off

MPLS is the traditional private WAN: carrier-managed, with a guaranteed service level and low jitter that made it rock-solid for voice, but expensive and slow to provision. Broadband internet is cheap, high-bandwidth, and available almost everywhere, though on its own it carries no end-to-end guarantee — ideal for bulk traffic and cloud access. Dedicated fiber or a leased line offers symmetric, high-capacity, dependable connectivity at higher cost, well suited as the primary link at larger sites. Cellular 4G and 5G deploy in minutes with no cabling, making them excellent as backup, and 5G fixed wireless can even serve as a primary link. Satellite reaches remote sites that have no other option, historically at the cost of higher latency, though low-earth-orbit services are improving that. The modern approach is to combine two or more of these into a hybrid WAN per site, balancing resilience, cost, and performance — which is exactly the foundation that SD-WAN is built to exploit.

Why Cloud Broke Hub-and-Spoke

The defining change in branch networking is not a new technology but a change in where traffic goes, and understanding it explains everything that follows.

Stop trombolining cloud traffic through headquarters

In the old hub-and-spoke model, every branch sent all its traffic over a private link back to headquarters, where a central firewall inspected it before it went anywhere else. When the applications lived in the data center at headquarters, that was efficient. But when the application lives in the cloud, the traffic now travels from the branch to headquarters, back out to the cloud, and all the way back again — the “trombone” detour that wastes bandwidth, adds latency, and saturates the central link. The modern answer is local breakout: the branch sends cloud and internet traffic straight out to its destination, while only genuinely internal traffic goes to headquarters or the data center. This is faster and far cheaper, but it comes with a catch that shapes the rest of branch design — if traffic no longer passes through the central firewall, then security can no longer live only at headquarters; it has to follow the traffic to the branch or into the cloud. That single realization is the main reason branch networking moved to SD-WAN and, ultimately, to SASE.

How SD-WAN Works

SD-WAN is the technology that lets an organization build a high-performance WAN out of ordinary, inexpensive links. Rather than depending on a single expensive circuit, it pools multiple connections and uses software to steer each application over the best available path.

How SD-WAN makes cheap links behave like a private WAN

At each branch, an SD-WAN edge appliance connects to whatever transports are available — MPLS, broadband, 5G — and classifies each application flow as it leaves the site. It then applies policy: latency-sensitive voice and video are sent over the lowest-latency link with priority; SaaS and cloud traffic break out locally, straight to the internet; and bulk or backup traffic takes the cheapest best-effort link. Dynamic path selection measures each link in real time and steers traffic around loss, jitter, or outages, failing over automatically and encrypting everything with IPsec. Crucially, the whole estate is managed from a central orchestrator — one console to push policy to every site — and new sites come online through zero-touch provisioning, where the appliance is shipped to the branch and configures itself with no engineer on site. These capabilities map directly to the four essentials the industry uses to define SD-WAN: support for multiple transport types, dynamic path selection for load sharing and resilience, simple centralized management, and integration of VPNs and security services.

Designing for Resilience

A branch that depends on a single link has a single point of failure: when that link drops, the entire site stops working. For any location where downtime has a real cost, resilience is not optional.

A branch with one link has a single point of failure

The foundation is a dual-transport design — two links from different providers and ideally different media types, such as a fiber primary paired with a 5G or broadband backup, following diverse physical paths so that one outage cannot take down both. How those links are used depends on need: in an active/passive design the backup sits idle and takes over on failure, while in an active/active design both carry traffic and share the load, with SD-WAN detecting loss or degradation and rerouting in seconds to keep voice calls and sessions alive. But resilience is more than a second link. A complete design also plans for power protection with a UPS at the branch, redundant edge hardware at critical sites, out-of-band management to reach a site when its primary connectivity is down, and regular failover testing — because an untested backup path is only an assumption. The investment should match the site: a flagship store or a clinic warrants far more redundancy than a two-person satellite office.

Converging Connectivity and Security with SASE

Once branches break out to the cloud directly, the security that used to sit at headquarters has to be reimagined, and the industry’s answer is SASE — Secure Access Service Edge — which converges networking and security into a single cloud-delivered service.

SASE — connectivity and security, converged

SASE combines SD-WAN’s intelligent connectivity — multi-link path selection, local breakout, and resilience — with a stack of cloud-delivered security services: a secure web gateway, cloud access security broker, Zero Trust Network Access, firewall-as-a-service, and data loss prevention, all applied wherever the users and traffic are. The appeal for branch environments is direct: every site, and every remote worker, receives consistent security from the cloud without needing a full security appliance stack installed and maintained in each location. Instead of shipping and managing firewalls to dozens of branches, the organization applies one consistent policy from a cloud service that protects traffic no matter where it originates or where it is headed. This is why analysts expect the majority of SD-WAN deployments to be delivered as part of a SASE offering — the two problems, connecting branches and securing them, are increasingly solved together.

Branch Connectivity Checklist

• Inventory each site’s needs: users, applications, criticality, and acceptable downtime.
• Use a hybrid mix of transports rather than relying on a single expensive circuit.
• Provide at least two diverse links at any site where downtime has real cost.
• Adopt SD-WAN to pool links, route applications intelligently, and fail over automatically.
• Enable local breakout so cloud and SaaS traffic exits directly instead of trombolining through HQ.
• Apply security that follows the traffic — at the branch or via the cloud — not only at headquarters.
• Prioritize voice and video with QoS across the WAN.
• Use zero-touch provisioning to stand up and change sites without dispatching engineers.
• Manage all sites from a central orchestrator with consistent policy.
• Plan branch power (UPS), redundant hardware at critical sites, and out-of-band management.
• Test failover regularly; an untested backup link is only an assumption.
• Consider SASE to converge connectivity and cloud-delivered security into one model.

Best Practices

Design around where the traffic actually goes. Most traffic now heads to the cloud, so stop routing it through headquarters. Enable local breakout and let each site reach cloud services directly, applying security along the way.

Combine transports, don’t bet on one. Pair links of different types and providers so no single failure isolates a site, and let SD-WAN blend them for both resilience and cost efficiency. Cheap internet plus smart software replaces much of what private circuits once did.

Let software do the routing. Application-aware, dynamic path selection sends real-time traffic over the best link and reroutes around problems automatically — far better than static routes over a single circuit.

Match resilience to the site. Not every location needs dual fiber and redundant hardware. Assess the cost of downtime per site and invest accordingly, from a simple cellular backup to full active/active redundancy.

Centralize management and go zero-touch. Managing every branch individually does not scale. A central orchestrator with zero-touch provisioning lets a small team run many sites and stand up new ones in hours, not weeks.

Converge security with connectivity. Once traffic breaks out locally, security must follow it. Deliver consistent protection from the cloud through a SASE model rather than shipping and maintaining separate security appliances at every branch.

Common Mistakes

Backhauling cloud traffic to headquarters. Forcing SaaS and internet traffic through a central site wastes bandwidth, adds latency, and overloads the HQ link. Break out locally instead.

Relying on a single link. A branch with one connection goes fully offline the moment that link fails. Provide diverse, redundant transports wherever downtime matters.

Sticking with MPLS out of habit. Private circuits remain useful for specific latency-critical needs, but paying premium prices to carry cloud traffic that could ride cheap broadband is money wasted. Re-evaluate the mix.

Leaving security at HQ after enabling breakout. Local breakout without local or cloud-delivered security opens each branch directly to the internet unprotected. Security must move with the traffic.

Configuring each site by hand. Manual, per-site management is slow, error-prone, and does not scale. Use central orchestration and zero-touch provisioning.

Never testing failover. A backup link that has never been exercised may not work when the primary fails. Test failover on a schedule so resilience is real, not theoretical.

Frequently Asked Questions

What is the difference between MPLS and SD-WAN? MPLS is a private carrier circuit with a guaranteed service level; SD-WAN is a software overlay that runs across multiple links — including cheap broadband and cellular — steering traffic intelligently. SD-WAN can use MPLS as one of its links, but it lets organizations reduce dependence on expensive private circuits.

Why did cloud adoption change branch networking? Because applications moved off the corporate data center and onto the internet. The old model of routing all branch traffic through headquarters became an inefficient detour for cloud-bound traffic, driving the shift to local breakout and SD-WAN.

Do we still need MPLS? Sometimes. MPLS still offers guaranteed low-latency, low-jitter performance that can be valuable for specific applications, and existing contracts may keep it in place. Many organizations run a hybrid WAN that keeps some MPLS while adding cheaper internet links via SD-WAN.

How does SD-WAN improve resilience? It uses multiple links at once and continuously monitors their health, automatically rerouting traffic around a link that suffers loss, jitter, or an outage — often within seconds — so a single connection failure does not take the site offline.

What is SASE and how does it relate to SD-WAN? SASE (Secure Access Service Edge) converges SD-WAN connectivity with cloud-delivered security services like secure web gateway, CASB, ZTNA, and firewall-as-a-service. SD-WAN handles the connecting; SASE adds consistent security from the cloud, which becomes essential once branches break out to the internet directly.

How do we connect a new branch quickly? With zero-touch provisioning: the SD-WAN appliance is shipped to the site, connected to power and any available internet link, and it automatically downloads its configuration from the central orchestrator — bringing a new site online in hours without dispatching an engineer.

Conclusion

Branch office connectivity has been transformed by a single fact: the applications people use no longer live at headquarters. That shift made the old hub-and-spoke model of expensive private circuits and central backhaul both costly and slow, and it pushed the industry toward a software-defined approach. SD-WAN lets organizations build resilient, high-performance WANs from a mix of inexpensive links, routing each application intelligently, breaking out to the cloud locally, and managing every site from one console with zero-touch provisioning. Designed with diverse links and automatic failover, branches gain resilience that a single circuit could never provide.

The final piece is security. Once traffic breaks out locally, protection must follow it, and SASE answers that by delivering consistent, cloud-based security to every site and remote worker without a rack of appliances in each location. Taken together, SD-WAN and SASE give a multi-site business what it needs: branches that connect faster, cost less, stay online through failures, and are protected as consistently as if they were all part of one network — because, in every way that matters, they are.

References

• SD-WAN — overview and architecture (Wikipedia)
• MEF 70 — SD-WAN Service Attributes and Services (MEF Forum)
• Understanding SD-WAN Managed Services (MEF Forum)
• Secure Access Service Edge (SASE) — concept overview
• NIST SP 800-207 — Zero Trust Architecture
• Multiprotocol Label Switching (MPLS) — overview
• NIST SP 800-113 — Guide to SSL VPNs (WAN security context)