Safeguard
Research•

How does SD-WAN work across multiple clouds, and what stays your job?

SD-WAN can link branches and several clouds under one policy, but each cloud keeps its own network constructs. See what NIST says to plan for and verify.

Safeguard Security Team
4 min read

A multicloud SD-WAN connects users, branches, data centers and several cloud providers under one set of routing and security policies. It abstracts each provider's networking, which differ in design. It does not remove your duty to define the segmentation, encryption and monitoring that those policies express.

What is SD-WAN?

NIST's guide to secure enterprise networks (SP 800-215) traces the path: leased lines, then frame relay, then MPLS, the first IP-based wide area network, which let voice, video and data share one line. SD-WAN is the next step. It removes the tight coupling between control plane and data plane and lets you specify policies centrally, including access control, routing and application traffic priority.

NIST lists common features: connecting users anywhere to applications anywhere over any transport, such as MPLS, broadband, LTE or 5G; application awareness, choosing the path by traffic type, load and business priority; integrated security and networking functions; centralized visibility and management that authenticates newly connected appliances; and optional integration with branch LANs.

How does it reach the cloud?

NIST describes two ways. First, use the VPN services cloud providers offer, including private subnets and peering between them. Second, integrate your own SD-WAN with the providers' private networks, building an overlay on top of the provider network as the underlay. NIST notes the second option depends on providers offering API integrations for different SD-WAN products.

The benefits NIST names are end-to-end visibility between the access endpoint and the cloud resource, and applying the same segmentation logic you use for on-premises resources to cloud resources.

What is hard about several clouds?

NIST's list of requirements for a multicloud networking platform reads like a to-do list. The primary challenge is that public cloud providers have different proprietary architectures with their own constructs. To cross clouds, you use each cloud's native networking functions, abstract them through APIs, add data plane features for availability, security and visibility, and manage them automatically.

The platform should offer a common ingress and egress policy for environments such as VPCs, VNETs and VCNs, encryption inside the cloud and from the data center to the cloud, and automation for deployment. NIST adds that the abstraction layer needs complete visibility into the whole network, so it depends on monitoring tools, and that infrastructure-as-code tools can automate the virtual network configuration through plug-ins for major providers.

What trends should you watch?

NIST flags four trends with security implications: SD-WAN bought as a cloud service, AI-based monitoring and dynamic routing, 5G for last-mile access, and secure remote access functions folded into SD-WAN. It also describes SASE, which delivers networking and security together as a cloud service through points of presence, and notes that its functions are not new but delivered as one package instead of separate point products.

A constructed example

A retailer runs its storefront in one cloud and analytics in another, with stores connected over broadband. Before SD-WAN, each store had a VPN to each cloud. After, stores connect to a virtual overlay and a central policy says "point-of-sale traffic may reach the payment service and nothing else." The team writes that policy once. They still test it per cloud, since each provider's security groups and routing tables behave differently and a gap in one will not show up in the other.

How to check or apply this

  1. Decide the segmentation first: which zones exist and what may talk to what.
  2. Express it as one policy, then verify the translation in each cloud's native rules.
  3. Confirm the SD-WAN product has API integration with every provider you use.
  4. Require encryption between sites and clouds, and check key and certificate management.
  5. Manage configuration as code and review changes like application changes.
  6. Feed monitoring from every cloud into one place, since the abstraction layer needs visibility.
  7. Test failure: take down one transport and confirm traffic moves per policy.
  8. Review your exit path, because an overlay can become a lock-in point.

Safeguard works at the software layer: dependency scanning, reachability and policies for the code you deploy to those clouds. It does not provide SD-WAN or network security products.

Quick check

Does SD-WAN replace cloud provider networking?

No. NIST describes an abstraction layer or overlay built on top of each provider's native network, which stays the underlay.

What is the hardest part of multicloud networking?

According to NIST, providers use different proprietary constructs, so consistent policy has to be mapped onto each of them and verified separately.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.