SD-WAN Security: Controls, Responsibilities, and SASE Boundaries

SD-WAN Security: Controls, Responsibilities, and SASE Boundaries

SD-WAN can support security through controls such as encrypted tunnels, traffic segmentation, firewall inspection, and policy steering. Which controls are included, where they run, and how they integrate with other services varies by implementation. A secure design therefore defines the controls and owners on each traffic path rather than assuming that SD-WAN alone provides complete protection.

SD-WAN also changes where security has to happen. When branches send internet and SaaS traffic directly instead of through a central data centre, the inspection that used to sit at one hub must be reproduced at the edge, in a connected cloud service, or deliberately not applied. This article covers the controls an SD-WAN design can include, the management plane that governs them, how to assign responsibility, and where SD-WAN ends and SASE begins.

What security controls can an SD-WAN design include?

These are possible building blocks, not a feature list every platform provides in the same form. Some services include a full next-generation firewall at the edge; others provide basic stateful filtering and rely on a connected security service for deeper inspection. Confirm the actual capability, licensing, and performance with inspection enabled, because throughput figures quoted without security functions may not reflect the configured design.

Why does the management plane matter?

The orchestrator or controller is the most privileged part of an SD-WAN. It can typically change routing and security policy, onboard new edges, and distribute keys to every site at once. That centralisation is a large part of SD-WAN's operational value, and it also means that a compromised administrator account or management interface can affect the entire network rather than a single device.

Treat the management plane as a high-value system in its own right:

• Restrict administrative access. Require multi-factor authentication, use role-based access so that operators have only the permissions they need, and remove shared or default accounts. Keep management interfaces off the public internet where the service allows it.
• Log and review changes. Ensure policy and configuration changes are attributable to a named person, recorded in an audit log, and reviewed through the organisation's change process. A template applied to every site needs the same scrutiny as a change to the core network.
• Control how edges join. Zero-touch provisioning is convenient, but the design should define how a new device is authenticated before it receives policy and keys, and how a lost, stolen, or decommissioned device is revoked.
• Maintain software. Track vendor security advisories for controllers and edge devices, and include them in patching and vulnerability management. SD-WAN management components have appeared in published advisories and in CISA's Known Exploited Vulnerabilities catalogue, so they should not be treated as set-and-forget infrastructure.
• Plan for controller unavailability. Understand whether edges keep forwarding traffic with their last known policy if the controller is unreachable, and how long keys or certificates remain valid in that state.

Where the provider operates the orchestrator, ask how its own administrative access is controlled and logged, and what the organisation can see of that activity.

What does encryption protect, and what does it leave open?

Encrypted tunnels, commonly IPsec, protect traffic between participating edges as it crosses an underlay such as broadband, LTE, or an MPLS service. Keys are usually generated and rotated through the controller rather than configured manually at each site. This protects the confidentiality and integrity of traffic in transit between those edges; it does not tell you whether the traffic itself is safe or permitted.

Check the boundaries of that protection:

• Traffic is decrypted at each tunnel end. Anything that reaches the branch LAN or the data-centre hub is unencrypted at the network layer unless the application provides its own encryption.
• Traffic sent directly to the internet or SaaS from a branch leaves the overlay. Its protection depends on application-level encryption such as TLS and on the inspection applied at the breakout point.
• Some designs leave private transport such as MPLS unencrypted by choice. That should be a recorded decision with an owner, not a default nobody reviewed, and it should be revisited if failover can move the same traffic onto public transport.
• Encryption limits what intermediate devices can see. Inspection that needs to read content, such as decrypting TLS to apply web or data-loss controls, must happen at a point where the traffic is decrypted, and it brings its own privacy, certificate, and exemption decisions.

IPsec does not replace endpoint protection, application controls, identity governance, or monitoring.

How should segmentation be designed?

Segmentation separates traffic groups so that a problem in one group does not give automatic access to another. In SD-WAN this is often implemented with separate routing instances or overlay segments carried end to end between sites, combined with zone-based policy at the edge. Common segments include corporate users, guest access, payment or regulated systems, and IoT or operational technology devices such as cameras, building systems, and sensors.

A segment is useful only when its boundaries and permitted flows are defined. For each segment, record what it contains, which other segments and services it may reach, and where traffic between segments is inspected. Shared services such as DNS, directory services, and management networks are often where segments meet, so review them explicitly. Exceptions should have an owner and a review date rather than becoming permanent by default.

Network segmentation also has limits. It constrains communication between groups, but it does not stop movement between devices within the same segment, and it does not assess whether a permitted connection is legitimate. Host-based controls, identity-aware access, and monitoring remain necessary inside each boundary.

Where should internet and SaaS traffic be inspected?

Local internet breakout is one of the most common reasons to adopt SD-WAN and one of the largest security changes it introduces. When each branch can send traffic directly to the internet, each branch becomes an internet edge. The design has to decide, for each class of traffic, where inspection happens.

Many designs combine these options: for example, backhauling traffic to on-premises applications, steering general web and SaaS traffic through a cloud security service, and allowing guest traffic out locally with basic filtering. Service chaining is the mechanism that sends each class of traffic through the intended functions in the intended order. Document what happens when a function in the chain fails: whether traffic is blocked, rerouted, or allowed out without inspection is a security decision, not just a resilience setting.

What should be logged and monitored?

Security controls are only useful if someone can see what they are doing. Decide which events each edge and connected service must export, such as denied flows, policy matches, threat detections, configuration changes, administrator logins, and tunnel or path failures. Send them to the system the security team actually uses, with accurate time synchronisation so that events from different sites and services can be correlated.

Confirm retention periods against investigation and compliance needs, and check whether a managed service keeps logs that the organisation cannot export. Where user identity matters to an investigation, make sure network events can be connected to the user or device involved. For a broader view of correlating network signals with application and infrastructure data, see full stack observability for troubleshooting.

How should teams assign security responsibility?

For each path, identify who owns policy, configuration changes, event review, incident response, and exceptions. A provider-managed function does not remove the organisation's need to understand the service boundary and escalation path. Confirm that events from edges and connected security services reach the teams responsible for investigation.

This matters most in co-managed and fully managed services, where the network team, security team, and one or more providers can each assume someone else is responsible. Write the split down in the contract or service documentation and test it, for example by walking through how a suspected compromise at one branch would be handled.

How should SD-WAN security be tested?

Test both permitted and denied flows. Include representative sites, application paths, segmentation boundaries, failures, and recovery. Keep evidence of the expected result, observed behaviour, exceptions, and remediation owner. Useful tests include:

• traffic between segments that should be blocked, including through shared services;
• internet and SaaS traffic from each type of site, confirming it reaches the intended inspection point;
• failover between transports and hubs, confirming that encryption and inspection still apply on the backup path;
• loss of the controller or a cloud security service, confirming the documented fail-open or fail-closed behaviour;
• administrator actions, confirming that changes are attributed and logged; and
• event delivery, confirming that a test detection reaches the team that should act on it.

Repeat the relevant tests after significant policy, software, or topology changes, not only at initial deployment. For architecture and topology context, see SD-WAN architecture: components, planes, and topologies and how to design an enterprise SD-WAN. Rollout sequencing and validation gates are covered in SD-WAN deployment: risks, sequencing, and mitigation.

Is SD-WAN the same as SASE?

No. SD-WAN focuses on connecting sites and steering traffic across available paths. SASE describes a broader model that combines network connectivity with security capabilities delivered or coordinated closer to users and applications. SD-WAN may be part of a SASE architecture, but it does not automatically include every SASE capability.

The boundary becomes clearer when you compare what each covers:

The cloud security service in a local breakout design is often where SD-WAN and SASE meet. Steering branch traffic to a cloud SWG or FWaaS is a step towards the SASE model, but it becomes SASE only when connectivity, identity, policy, and operations are designed together across users and sites. What is SASE? defines the broader model and its components, and SASE for remote and hybrid work covers the user-access side. The term originates with Gartner, whose glossary entry gives the category definition. NIST's Zero Trust Architecture (SP 800-207) is a useful reference for the identity-based access principles that ZTNA applies.

If an existing SD-WAN is the starting point for SASE, when to move from SD-WAN to SASE sets out decision gates and coexistence options, and the SASE implementation framework covers architecture and rollout.

Conclusion

SD-WAN provides useful security building blocks: encrypted overlays, segmentation, edge inspection, and policy-based steering towards security services. It also introduces new responsibilities, including a powerful central management plane and many local internet edges. A sound design states, for every traffic path, what is encrypted, segmented, inspected, logged, and allowed to bypass inspection, who owns each control, and how the result is tested. Where requirements extend to users away from sites and identity-based access to applications, the design is moving into SASE territory and should be assessed on those terms.