SD-WAN replaces rigid, hardware-bound networking with software-controlled connectivity that routes traffic based on real-time conditions and business priority. For organisations running multiple sites, cloud applications, and hybrid teams, it has become the default approach to wide area networking. This guide covers how SD-WAN architecture works, how it handles traffic, why application awareness matters, and how it fits within a broader SASE security stack. Written for IT managers and CIOs at European mid-market organisations who need reliable, secure connectivity without operational overhead.
Featured snippet: what is SD-WAN?
SD-WAN (Software-Defined Wide Area Networking) is a network architecture that separates the control logic from the physical transport layer. This allows organisations to:
- Route traffic dynamically across multiple connection types, including broadband, MPLS, and mobile links.
- Apply policies centrally from a single management console instead of configuring each device individually.
- Prioritise business-critical applications over less important traffic automatically.
- Encrypt all site-to-site and user-to-cloud connections by default.
- Reduce dependency on expensive MPLS circuits by using cheaper internet links where appropriate.
- Deploy new sites in days rather than weeks, using zero-touch provisioning.
What is SD-WAN and why does it matter?
A traditional Wide Area Network connects office locations through dedicated circuits, typically MPLS lines leased from a telecom provider. The hardware at each site, usually a router, follows static routing rules configured manually by a network engineer. Adding a new site means ordering a circuit, waiting weeks for provisioning, sending someone on-site to configure the router, and hoping everything works on the first attempt. Changing a routing policy means logging into each device separately.
SD-WAN changes this by abstracting the network intelligence into software. Instead of managing individual routers, you manage the entire network from a central controller. That controller pushes policies to lightweight edge devices at each location. Those edge devices can use any available transport, broadband internet, MPLS, 4G/5G mobile, or a combination, and switch between them dynamically based on performance and policy.
The practical result for IT teams: faster site deployments, lower transport costs, better application performance, and a single place to manage it all. For organisations with 5 sites or 50, the operational difference is significant.
The market reflects this shift. The global SD-WAN market is projected to grow from roughly USD 7.9 billion in 2025 to over USD 21 billion by 2030. Gartner estimates that by 2026, 60% of new SD-WAN purchases will be part of a single-vendor SASE offering, up from 15% in 2022. The technology has moved well past the early-adopter phase into mainstream deployment.
How SD-WAN architecture works
SD-WAN architecture separates two things that traditional networking bundles together: the control plane and the data plane.
The control plane
The control plane is where decisions are made. A centralised controller, typically cloud-hosted, holds the complete picture of your network topology, policies, and performance metrics. When you define a policy that says “route video conferencing traffic over the lowest-latency link,” that instruction lives in the control plane and gets pushed to every edge device in the network.
This centralisation is what makes SD-WAN manageable. Instead of SSH-ing into 30 routers to make a change, you adjust it once in the controller and it propagates everywhere.
The data plane
The data plane is where packets actually move. Edge devices at each site handle the physical work of forwarding traffic across your available connections. They build encrypted overlay tunnels between sites, measure link quality in real time, and execute the routing decisions that the control plane dictates.
Edge devices
SD-WAN edge devices sit at branch offices, data centres, or cloud environments. They can be physical appliances, virtual machines, or cloud-hosted instances. Most support zero-touch provisioning, which means a device shipped to a new office can automatically pull its configuration from the cloud controller the moment it connects to the internet. No engineer needs to travel to the site.
The orchestration layer
On top of the control and data planes sits the orchestration layer, the management interface that IT teams interact with daily. This is typically a cloud-hosted dashboard that provides visibility into link health, application performance, user activity, and policy status across all sites. It is also where you configure new policies, onboard sites, and generate reports.
| Component | Role | Where it runs |
|---|---|---|
| Control plane | Policy definition, routing decisions, network-wide orchestration | Cloud controller |
| Data plane | Packet forwarding, tunnel management, link quality measurement | Edge devices at each site |
| Edge devices | Physical or virtual appliances at branch, data centre, or cloud | On-premises or cloud |
| Orchestration layer | Dashboard for visibility, configuration, and reporting | Cloud-hosted console |
How SD-WAN handles traffic routing
Traditional WANs use static routing. Traffic follows the same path regardless of whether that path is congested, experiencing packet loss, or outright failing. SD-WAN replaces this with dynamic path selection.
Dynamic path selection
Every SD-WAN edge device continuously monitors the performance of each available link. It measures latency, jitter, and packet loss in real time. When a policy says an application needs certain performance thresholds, the edge device picks the link that meets those requirements. If conditions change, traffic shifts to a better path automatically, often before users notice any degradation.
For example, your finance team runs an ERP system that requires low latency and zero packet loss. SD-WAN can route that ERP traffic over your most reliable MPLS link while sending general web browsing over a cheaper broadband connection. If the MPLS link degrades, the edge device reroutes ERP traffic to the next best link within seconds.
Transport independence
SD-WAN is transport-agnostic. It can use broadband internet, dedicated MPLS, 4G/5G mobile connections, or even satellite links. The overlay tunnels between sites are encrypted regardless of the underlying transport, so a packet travelling over public internet is protected to the same standard as one on a private circuit.
This transport independence is what enables the cost savings organisations see when adopting SD-WAN. Many replace some or all of their MPLS circuits with business-grade broadband, which can reduce WAN transport costs by 30% to 50% depending on the environment.
Direct cloud access
In a traditional hub-and-spoke WAN, all traffic from branch offices routes through a central data centre for inspection before reaching the internet or cloud applications. This “hairpinning” adds latency and creates a bottleneck at headquarters. When a user in a branch office accesses Microsoft 365 hosted 20 kilometres away, their traffic might travel hundreds of kilometres through the data centre first.
SD-WAN enables direct-to-cloud breakout at each site. Traffic destined for trusted cloud applications can leave the branch directly over a local internet connection, inspected and secured at the edge. This dramatically reduces latency for SaaS applications and removes the data centre as a single point of failure.
Application awareness and quality of service
Application awareness is what separates SD-WAN from a basic internet load balancer. The system does not just route packets; it understands what those packets are and treats them accordingly.
Deep packet inspection
SD-WAN edge devices use deep packet inspection (DPI) to identify applications at the first packet of a session. This means the system knows whether traffic is a Teams video call, SAP transaction, or someone streaming music before it makes a routing decision. Unlike traditional QoS that relies on port numbers (which are increasingly unreliable with cloud applications using port 443 for everything), DPI identifies the actual application.
Policy-based quality of service
Once the system identifies an application, it applies the policies you have defined. These policies control three things:
Priority. Which applications get first access to available bandwidth. A video conference between your CEO and a client takes precedence over a background file sync.
Path selection. Which transport link an application should use. Latency-sensitive applications get the lowest-latency path. Bulk transfers use whatever link has the most available bandwidth.
Failover behaviour. What happens when the preferred path becomes unavailable. Critical applications might fail over to a 4G/5G backup, while lower-priority traffic simply waits for capacity to free up.
Real-time adaptation
These decisions are not static. SD-WAN recalculates them continuously. If your primary broadband link starts dropping packets during peak hours, the system detects this within seconds and shifts sensitive traffic to an alternative path. When conditions improve, traffic returns to its preferred route. This happens without manual intervention and, in most cases, without users noticing.
SD-WAN vs traditional WAN: a practical comparison
| Aspect | Traditional WAN | SD-WAN |
|---|---|---|
| Transport | Primarily MPLS, single path per site | Multi-transport: broadband, MPLS, 4G/5G, satellite |
| Routing | Static rules, manually configured per device | Dynamic path selection based on real-time conditions |
| Application awareness | Limited or none; routing by port/protocol | Deep packet inspection identifies apps at first packet |
| Site deployment | Weeks to months (circuit provisioning, on-site configuration) | Days (zero-touch provisioning, cloud-managed) |
| Management | Per-device CLI configuration | Centralised cloud console for all sites |
| Cloud access | Hairpinning through data centre | Direct-to-cloud breakout at each site |
| Encryption | Varies; often requires separate VPN configuration | Built-in encryption across all overlay tunnels |
| Cost structure | High fixed cost (MPLS circuits) | Lower variable cost (broadband + selective MPLS) |
| Failover | Manual or slow convergence | Sub-second automated failover across links |
| Scalability | Adding sites requires new circuits and hardware | Adding sites requires shipping an edge device |
Where SD-WAN fits in a SASE security stack
SD-WAN solves the connectivity problem. It makes your network faster, more resilient, and easier to manage. But connectivity without security is incomplete, especially when your users connect from anywhere and your applications live in the cloud.
This is where Secure Access Service Edge (SASE) comes in. SASE converges networking and security into a single cloud-managed platform. SD-WAN provides the networking foundation, and security services layer on top of it.
The SASE security components
Zero Trust Network Access (ZTNA) replaces VPN with identity-based, per-application access. Users authenticate and receive access only to the specific applications they need, not to the full network. This eliminates lateral movement risk.
Secure Web Gateway (SWG) inspects and filters web traffic for threats, enforces acceptable use policies, and provides category-based filtering. Policies follow the user regardless of location.
Firewall-as-a-Service (FWaaS) delivers cloud-based firewall policies for outbound and inter-site traffic, replacing the need for physical firewall appliances at every branch.
Device Posture Checks verify that devices meet security baselines (OS version, disk encryption, endpoint protection) before granting access to sensitive resources.
Why integrated SD-WAN and security matters
When SD-WAN and security live in separate platforms, you manage two consoles, two policy engines, and two sets of logs. Policies can drift out of sync. Troubleshooting becomes a finger-pointing exercise between the networking tool and the security tool.
An integrated SASE approach puts connectivity and security under one policy framework. Traffic routing decisions and security policies are enforced at the same point. A single log stream captures both networking events and security events. For small IT teams, this consolidation is not a luxury; it is a practical necessity.
For organisations operating in sectors with connected equipment, factories, logistics hubs, healthcare facilities, SD-WAN also needs to support devices that cannot run software agents. Printers, cameras, industrial PLCs, and IoT sensors all need secure connectivity. NIAC hardware provides inline isolation for these agentless devices, forming a secure bridge between IT and OT environments without disrupting production systems.
SD-WAN deployment models for mid-market organisations
There is no single way to deploy SD-WAN. The right model depends on your current infrastructure, budget, and internal capacity.
Internet-only SD-WAN
Replace all MPLS circuits with business-grade broadband and 4G/5G backup. Each site gets two or more internet connections with SD-WAN overlay tunnels providing encrypted, resilient connectivity. This model delivers the highest cost savings and works well for organisations where applications are primarily cloud-hosted and latency tolerance is moderate.
Hybrid SD-WAN
Keep MPLS for your most critical sites or applications while using broadband for everything else. SD-WAN manages both transport types, routing sensitive traffic over MPLS and general traffic over internet. This is the most common model for mid-market organisations transitioning away from legacy WAN. It lets you reduce MPLS spend gradually without a full rip-and-replace.
Cloud-first SD-WAN
Deploy SD-WAN edge devices in cloud environments (AWS, Azure, Google Cloud) alongside branch devices. This model treats cloud workloads as “sites” in your network, providing consistent policy enforcement and optimised routing between branches and cloud resources. It is particularly relevant for organisations running hybrid infrastructure with workloads split between on-premises and cloud.
Managed SD-WAN through an MSP
Many mid-market organisations lack the internal capacity to design, deploy, and manage SD-WAN independently. Working with a Managed Service Provider shifts the operational burden to a partner while retaining policy control. The MSP handles day-to-day monitoring, troubleshooting, and change management. For this model to work, the underlying platform needs multi-tenant capabilities that allow the MSP to manage multiple customers efficiently from a single console.
Planning your SD-WAN deployment: a step-by-step approach
Step 1: audit your current WAN
Map every site, its current connectivity (MPLS, broadband, mobile), bandwidth utilisation, and the applications users access. Identify which MPLS contracts are approaching renewal, as these represent natural transition points.
Step 2: classify your applications
Not all applications have the same network requirements. Group them into tiers based on latency sensitivity, bandwidth needs, and business criticality. Your ERP and VoIP systems likely need guaranteed performance. Email and web browsing can tolerate more variation.
Step 3: define your transport strategy
Decide which sites keep MPLS, which move to broadband-only, and which need mobile backup. Factor in local ISP availability and reliability. Sites in areas with poor broadband may need MPLS or 4G/5G as a primary link.
Step 4: start with a pilot group
Pick 3 to 5 representative sites for initial deployment. Include at least one site with legacy connectivity and one with cloud-heavy application usage. Measure baseline performance before deployment and compare after.
Step 5: expand with consistent policies
Once the pilot validates your approach, roll out to remaining sites in waves. Use the central console to apply standardised policies across all sites. Each new site deployment should take days, not weeks, with zero-touch provisioning handling most of the configuration.
Step 6: integrate security and compliance
Layer security services on top of your SD-WAN foundation. Activate Secure Web Gateway for consistent web filtering across all sites. Enable ZTNA for application access. Configure logging and reporting to support NIS2 and GDPR evidence requirements.
Common SD-WAN mistakes and how to avoid them
Treating SD-WAN as just a cheaper WAN.
Cost savings are real, but SD-WAN’s primary value is operational agility and application performance. Organisations that focus only on cutting MPLS spend miss the broader benefits of centralised management and dynamic routing.
Deploying SD-WAN without a security strategy.
SD-WAN improves connectivity but does not, on its own, solve security challenges. Without integrated security controls, you are building a faster network that is equally vulnerable to threats. Plan SD-WAN and security together from the start.
Ignoring agentless devices at branch sites.
Printers, cameras, IoT sensors, and industrial equipment all connect to your network but cannot run SD-WAN agents or security clients. Without a plan for these devices, you create blind spots that attackers can exploit. Inline isolation hardware addresses this gap.
Choosing a standalone SD-WAN that does not integrate with your security stack.
If your SD-WAN vendor and your security vendor are different companies with different consoles, you inherit integration complexity. The industry trend toward single-vendor SASE exists precisely because managing two platforms creates operational overhead that mid-market teams cannot absorb.
Attempting a big-bang migration from MPLS.
Replacing all circuits at once is risky. A phased approach, starting with sites where MPLS contracts are expiring, lets you validate the new architecture before committing fully.
European compliance and SD-WAN
European organisations face specific regulatory requirements that influence how they architect their networks.
- NIS2 requires essential and important entities to demonstrate risk management, incident response, and supply chain security. SD-WAN within a SASE framework provides the centralised logging, policy versioning, and access controls that auditors expect.
- GDPR demands that personal data processing is lawful, proportionate, and documented. SD-WAN with integrated ZTNA ensures access to personal data is scoped to authorised users and devices, with audit trails showing who accessed what and when.
- DORA mandates operational resilience for financial entities. SD-WAN’s multi-path redundancy and automatic failover directly support resilience requirements by ensuring connectivity survives individual link failures.
Beyond regulation, data sovereignty matters. When your SD-WAN controller and security logs reside with a US-based provider, those logs may be subject to the US CLOUD Act regardless of where your data centres are located. European organisations handling sensitive data should evaluate whether their provider processes data within EU jurisdiction.
How Jimber delivers SD-WAN as part of Real SASE
Jimber provides SD-WAN as an integrated component of its cloud-managed SASE platform. Rather than offering SD-WAN as a standalone networking product, Jimber unifies connectivity with Zero Trust access, web security, and device posture verification in one console.
Application-aware routing.
Traffic is routed based on application identity and real-time link conditions. Business-critical applications get priority paths while general traffic uses whatever bandwidth is available.
Encrypted overlay tunnels.
All site-to-site traffic is encrypted by default across any transport type. Whether you connect over broadband, MPLS, or mobile, protection is consistent.
Zero-touch deployment.
New sites come online by plugging in an edge device and connecting it to the internet. Configuration pulls automatically from the cloud controller.
Single management console.
SD-WAN policies, ZTNA rules, web filtering, and device posture checks are all managed from one interface. One set of logs. One policy engine. One place to troubleshoot.
Network controllers for any environment.
Jimber supports virtual, physical, and industrial network controllers. For environments with IoT and OT devices, NIAC hardware provides inline isolation so agentless equipment connects securely without disrupting production.
Transparent pricing.
No bandwidth-based surcharges or hidden add-on fees. Pricing is predictable, which matters both for budgeting and for MSPs building managed service packages around the platform.
European data processing.
Jimber is headquartered in Belgium with data processing within EU borders. No US parent company. No CLOUD Act jurisdictional conflict.
Frequently asked questions
Is SD-WAN a replacement for MPLS?
It can be, but does not have to be. Many organisations run a hybrid model, keeping MPLS for a few critical sites while using broadband elsewhere. SD-WAN manages both transport types from one console, so you can transition at your own pace as contracts expire.
How long does an SD-WAN deployment take?
A pilot covering 3 to 5 sites can be operational in one to two weeks with zero-touch provisioning. Full rollout across all locations depends on scope and site complexity, but mid-market organisations typically complete deployment within three to six months.
Does SD-WAN work with 5G?
Yes. SD-WAN is transport-agnostic and treats 5G connections like any other link. Mobile connections can serve as primary transport for sites without fixed-line options or as failover backup for sites that need redundancy.
What about devices that cannot run an agent?
Printers, cameras, IoT sensors, and industrial machines connect through the network but cannot run SD-WAN or security software. NIAC hardware provides inline isolation for these devices, permitting only approved traffic flows while maintaining Zero Trust controls.
How does SD-WAN support NIS2 compliance?
SD-WAN within a SASE platform provides centralised logging, policy versioning, access controls, and incident detection capabilities. These are precisely the evidence categories that NIS2 auditors expect to see documented.
What is the difference between SD-WAN and SASE?
SD-WAN handles the networking layer: traffic routing, path selection, and site connectivity. SASE extends SD-WAN by adding security services like ZTNA, Secure Web Gateway, and Firewall-as-a-Service into a single platform. SD-WAN is a component of SASE, not a separate category.
Can an MSP manage SD-WAN on our behalf?
Yes, and for many mid-market organisations this is the preferred model. A multi-tenant platform allows MSPs to manage multiple customers from one console with consistent policies, transparent reporting, and predictable margins.
Take the next step
Ready to replace complex WAN infrastructure with secure, cloud-managed connectivity? Book a demo and see how Jimber’s SD-WAN, integrated with Zero Trust access and web security, works for your environment.