SDWSCS Part 6: SASE — Architecture & Use Cases

The first five parts of this series put enforcement on the edge or behind a service chain. This part covers the third answer, and the hinge of the whole syllabus: Secure Access Service Edge — move the enforcement into the cloud and make the WAN’s job simply to deliver traffic there efficiently. I’ve written about this convergence before from the Fortinet/ZTNA angle; this is the Cisco version, and the syllabus treats it as the conceptual bridge between the security half and the cloud half of the course.

What SASE is, minus the vendor gloss

SASE (Gartner’s term, 2019) is the observation that two products were converging: SD-WAN (get traffic from anywhere to anywhere, well) and the cloud security stack (enforce policy on traffic, anywhere). The security half has its own acronym — SSE, Security Service Edge — and consists of a familiar list:

  • SWG — secure web gateway: proxying, URL filtering, content inspection
  • CBFW / FWaaS — cloud-based firewall: L3/L4 + IPS for non-web protocols
  • CASB — visibility and control over SaaS usage (Part 8’s subject)
  • DNS-layer security — the cheapest, earliest control point
  • ZTNA — per-application access replacing network-level VPN
  • DLP & RBI — data loss prevention and remote browser isolation

SASE = SSE + SD-WAN. That equation matters because it tells you what the SD-WAN side must be good at in a SASE design: building and load-balancing tunnels to the SSE points of presence, steering the right traffic into them, and measuring whether the PoP is actually healthy. Those are exactly the skills Parts 7–9 build.

Cisco’s SASE assembly

Cisco’s SASE story is assembled from named parts rather than a single product:

FunctionComponent
SD-WAN fabricCatalyst SD-WAN (this series, passim)
SWG, DNS security, CBFW, CASB, DLPUmbrella SIG (Parts 7–8)
Identity & MFADuo
ZTNACisco Secure Access (the SSE platform that has absorbed the Umbrella feature set upstream)
Digital experience monitoringThousandEyes (Part 9)

The integration that makes it SASE rather than a parts list is the automatic tunnel workflow: vManage builds and maintains the IPsec tunnels from every edge to the nearest Umbrella/Secure Access PoPs, tracks their health, and data policy steers traffic into them — no per-site manual tunnel engineering. One console defines the security policy (Umbrella), the other defines which traffic goes to it (vManage), and the demarcation line between the two consoles is the single most useful thing to understand before Part 7’s deployment.

When SASE wins — and when it doesn’t

The use cases the syllabus wants you to be able to argue:

SASE wins:

  • Many small sites. A 200-branch retailer with 1-2 rack-unit sites: no on-box IPS capacity planning, no per-site policy drift — thin edges, tunnels to SIG, one cloud policy. The economics aren’t close.
  • Roaming and home users. The branch stack can’t follow a laptop home; the Umbrella roaming client / Secure Client makes off-net users subject to the same cloud policy as branch users. One policy, every user location.
  • M&A and rapid onboarding. Bringing an acquired estate under your security policy without touching their edge hardware: tunnel their egress to your SSE tenant.
  • Encrypted traffic at scale. TLS decryption in the cloud sidesteps the branch-edge resource maths from Part 4 (the PKI trust problem, however, comes along unchanged).

SASE loses (or at least argues):

  • East-west and site-to-site traffic. SSE PoPs sit between you and the Internet; branch-to-DC flows never transit them. Segmentation and fabric-internal inspection remain on-box or chained — Parts 3–5 don’t get deleted by SASE, whatever the slideware says.
  • Latency-critical local breakout. A tunnel to a PoP 30 ms away is a tax on every packet; for some real-time traffic, local inspect-and-breakout is better.
  • Data-residency-constrained traffic where the nearest compliant PoP isn’t near.
  • Sites whose transport is the problem. SASE assumes decent Internet underlay; a site on wet string needs WAN engineering first.

The honest summary I’d defend in a design review: SASE moves the Internet-bound perimeter into the cloud; it does not abolish the on-box stack for fabric-internal traffic. Most real designs in 2026 are the hybrid from Part 2: ZBFW everywhere, SIG for Internet-bound web, service chains for the regulated remainder.

Next up, Part 7: Umbrella SIG properly — PoP architecture, the automatic tunnel workflow from vManage, active/active vs active/backup tunnel designs, and DNS policies as the first enforcement layer.