Cisco Catalyst SD-WAN Deep Dive Part 7: SIG, Secure Firewall, and Edge Security

Part 5 introduced DIA and Part 6 covered Cloud OnRamp for SaaS — both built around the same premise: don’t backhaul Internet-bound traffic to a hub when a local circuit can carry it instead. That premise leaves an open question this post answers: if traffic isn’t backhauling through the hub, where does it get inspected?

There are two answers, and most real designs end up using both, segmented by what’s being protected.

On-box inspection: the UTD container running inside cEdge

The first answer keeps inspection local. cEdge platforms can run UTD — Unified Threat Defense — as a containerized service inside IOS-XE itself, providing Snort-based IPS, URL filtering, and AMP-style malware detection directly on the WAN Edge. Traffic gets redirected into the container for inspection before it’s allowed to exit locally over DIA, all on the same box that’s doing the SD-WAN forwarding described in Part 4 — no separate appliance, no separate hop.

This is the natural complement to DIA: if you’ve decided a branch should break Internet traffic out locally rather than backhaul it, UTD is how that branch gets some of the inspection coverage back without re-centralizing the traffic path you just decided to decentralize. It’s also bounded by what a branch-class router’s CPU/container resources can realistically do — UTD is a reasonable fit for branch-grade DIA traffic, not a substitute for a dedicated next-gen firewall doing deep TLS inspection at scale.

Cloud-delivered inspection: routing DIA traffic through SIG

The second answer keeps inspection local in policy terms but not in physical terms: instead of inspecting on-box, the WAN Edge steers DIA-bound traffic into a cloud-delivered security stack — Cisco’s Secure Internet Gateway (SIG) integration, built on the Umbrella platform — over a tunnel from the branch to the cloud security service. The branch still breaks out locally rather than backhauling to a physical hub, but “locally” now means “to the nearest cloud security PoP” rather than “straight to the Internet unfiltered.” That gets you DNS-layer security, secure web gateway functionality, CASB, and cloud-delivered firewalling — the kind of stack that’s genuinely impractical to run as a branch-router container — without reintroducing the hub-backhaul latency DIA was meant to avoid in the first place.

Which of these two a given service VPN uses is a policy decision, conceptually the same kind of service redirection introduced back in Part 2 and Part 3’s service-route discussion — a segment’s traffic gets steered to whichever inspection point (local UTD, cloud SIG, or still a physical hub for segments that haven’t moved to DIA at all) the policy says it should.

The bigger pattern: this is the SASE conversation, in Cisco’s vocabulary

Step back, and this is the same industry-wide shift this site has already covered from the other side of the fence. The Fortinet ZTNA-and-SD-WAN convergence post covers exactly this move — security stops living only in a data-center chokepoint and becomes something the fabric carries with it, whether that’s zero-trust application access or inline traffic inspection — and the Fortinet hub-placement series, Part 3 names the underlying trend directly: the data center stops being the default security chokepoint once cloud-delivered inspection is good enough to put security at the edge instead. Cisco’s framing of the same trend runs through Umbrella/SIG for the cloud-delivered half and its own Secure Access zero-trust offering (the converged Duo-plus-Umbrella SSE stack) for the ZTNA half — different product names, same architectural conclusion every major SD-WAN vendor has converged on: inspection has to follow the traffic to wherever it’s actually breaking out, because backhauling everything to a hub stopped being viable the moment DIA became the default rather than the exception.

Next

Part 8 turns from runtime security to operations: building and managing this fabric through code instead of point-and-click — the vManage API surface, and where Terraform and Ansible fit into provisioning and ongoing change management.