How are firewalls and SD-WAN related?

Firewalls and SD-WAN are related because they often sit on the same branch device, but they solve different problems. A firewall decides which traffic is allowed. SD-WAN manages and steers traffic across several wide area links with central policy. Neither replaces the other.

What does a firewall do?

NIST SP 800-41 Revision 1 defines firewalls as devices or programs that control the flow of network traffic between networks or hosts employing differing security postures. It covers several firewall technologies, discusses their advantages and disadvantages, and gives recommendations for policy, selection, configuration, testing, deployment and management. The core idea is a rule set: this source may reach that destination on that port, and everything else is denied.

What does SD-WAN do?

SD-WAN is a way to manage wide area network connections, usually several at once, through central software and policy rather than router-by-router configuration. It commonly decides which link an application should use based on measured quality, and it simplifies rolling out the same settings to many sites. SD-WAN is an industry term, and products differ, so check what a specific one includes.

Notice that the first question SD-WAN answers is "which path," while the firewall's is "whether at all."

Where do they overlap?

Many SD-WAN products bundle a firewall function, so a single appliance at a branch does both. Others work alongside a separate firewall, or send traffic to a cloud security service. Either way, the same traffic passes through both functions. The overlap in packaging can hide the difference in purpose.

Encryption is another overlap. SD-WAN products often build encrypted tunnels between sites, typically with IPsec. The tunnel protects traffic in transit. A firewall decides whether the traffic should be allowed in the tunnel at all.

What risks come from treating them as one thing?

A team may assume that because the device is called "secure SD-WAN," the firewall rules are sound. But a firewall policy is only as good as its rules. An allow-any rule between branches turns the whole network flat. Another error is applying inspection only to some traffic. If SD-WAN breaks out internet traffic directly at the branch, that traffic must still meet a policy, or branch users get less protection than headquarters users.

A third risk is central control. One controller managing hundreds of sites is also a single high-value target. Protect its accounts with strong authentication and limit who can change policy. NIST SP 800-207 on zero trust adds a design principle: do not grant trust only based on network location, so each access decision should be evaluated on its own.

A constructed example

A retailer replaces its branch routers with SD-WAN devices that include firewall features. The network team configures link steering for video calls and card payments. Months later, a review finds the branch firewall policy was left at "allow all outbound," copied from the old router, and the branches may reach each other freely. The team keeps the SD-WAN steering as it is, rewrites the firewall rules to deny by default, separates payment devices into their own zone, and logs denied connections to detect scanning.

How to check or apply this

1. List what each device in the path does: routing, steering, tunneling, filtering.
2. Write firewall rules as an allowlist with a default deny.
3. Segment sensitive systems, such as payment and building controls.
4. Apply the same inspection to local internet breakout as to traffic sent to a central site.
5. Protect the SD-WAN controller with MFA and role-based access.
6. Log firewall decisions centrally and review denied traffic.
7. Test the policy from inside a branch by attempting forbidden connections.
8. Review rules at least twice a year, and remove ones nobody can explain.

Quick check

Sources

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• NIST SP 800-207, Zero Trust Architecture
• RFC 4301, Security Architecture for the Internet Protocol

Last reviewed: 18 October 2026.