SASE Architecture Explained: — How Networking and Security Fuse at the Cloud Edge

① Why SASE exists — the old model breaks when apps and users leave the building

Picture Rahul, an L1 engineer at Infosys, looking after 40 branch offices. Every branch hangs off an MPLS circuit that drags all its traffic back to one HQ data centre. There, a stack of firewalls inspects everything and sends it out to the internet. For a decade that design was fine — because the apps and the data lived in that data centre too. The traffic was already going where the security was.

Then two things broke the assumption. First, the apps left the building — email is now Microsoft 365, files are in Google Drive, the CRM is Salesforce, infrastructure is in AWS. Second, the users left the building too — after 2020 half the workforce is remote, on home Wi-Fi and 4G. So now a Lucknow employee opening a SaaS app sends traffic backhauled to the Mumbai data centre, inspected, then out to a cloud that might be hosted 5 km from where they started — and the reply hairpins all the way back.

Pain one is latency from backhaul. Every extra hop to and from the central stack adds delay, and users feel it on exactly the apps that matter — voice, video, interactive SaaS. Pain two is the choke point: that central firewall stack is a single funnel. Size it for peak and you over-pay; size it for average and it melts on a busy Monday. And when it goes down, every branch and every remote user goes down with it. The old design scaled the business onto one fragile pipe.

There was a stop-gap: the VPN. But a VPN drops the remote user onto the whole network and then trusts them — so one stolen laptop can move sideways to anything. (We will see in section ④ why that trust model is exactly what Zero Trust and ZTNA throw out.)

Here is the shift. In 2019, Gartner named the answer SASE (pronounced "sassy"). Instead of hauling traffic to where the security lives, SASE moves the security to a distributed cloud edge — a network of Points of Presence (PoPs) close to wherever the user is. The user connects to the nearest PoP, gets inspected there, and goes straight to the app. No backhaul, no single choke point, and the same protection whether you are in the office, at home, or on a train.

Why the old model breaks — in one tap each

Tap each card — these are the four forces that pushed every enterprise toward SASE.

② The two halves — WAN-edge networking + SSE security, converged

SASE has exactly two halves, and getting them straight is the whole lesson. The first half is networking — the WAN edge. Its job is to get the packet to the right place over the best available link. The headline piece here is SD-WAN, joined by WAN optimisation and quality-of-service. This half decides the path.

The second half is security, and Gartner gave it its own name in 2021: SSE (Security Service Edge). SSE is a bundle of cloud-delivered security services. The four that Gartner names as the core, plus DLP, are the ones you must know cold.

SWG (Secure Web Gateway) inspects and filters web traffic — blocks malware, phishing and disallowed sites. CASB (Cloud Access Security Broker) sits between users and SaaS apps to give visibility and control over things like shadow IT and risky sharing. ZTNA (Zero Trust Network Access) gives a user access to one specific private app after verifying identity and device — never to the whole network like a VPN. FWaaS (Firewall as a Service) is the cloud-delivered firewall for non-web traffic. DLP (Data Loss Prevention) spots sensitive data — a PAN card number, source code, a customer list — and stops it leaving.

Now the part that matters most: convergence. SASE is not "SD-WAN over here and five security tools over there." It is those functions delivered as one cloud service, sharing one policy and one identity engine at the PoP. So when Priya at ICICI writes a rule like "finance group can use Salesforce but not download reports to an unmanaged device," that one rule is enforced by SWG, CASB and DLP together, for that user, at whichever PoP she connects through — office, home or airport.

The SSE security services — decoded

Tap each card. These five are the security half of SASE; memorise the one-line job of each.

resource "cloudflare_access_application" "crm" {
  zone_id = "f037e56e0a3b4b1d9e2c6a7b8c9d0e1f"
  name    = "Internal CRM (private app)"
  domain  = "crm.infycorp.internal"
}

resource "cloudflare_access_policy" "crm_finance" {
  application_id = cloudflare_access_application.crm.id
  name           = "Finance group, healthy device only"
  decision       = "allow"
  include { group = ["finance@infycorp.in"] }
  require { device_posture = ["disk-encrypted"] }
}

Plan: 2 to add, 0 to change, 0 to destroy.
cloudflare_access_application.crm: Creation complete after 2s
cloudflare_access_policy.crm_finance: Creation complete after 3s
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
# crm.infycorp.internal now reachable ONLY by finance@ on an encrypted device — no VPN, no network-wide access

③ How a session flows — identity first, single-pass inspection, then steer

Theory is fine; let's watch one real session. Aditya, a remote employee of Flipkart, opens the company's CRM from his laptop at home. In the old world his VPN would tunnel him onto the corporate LAN. In the SASE world, his traffic instead goes to the nearest PoP — and four things happen there, in order.

1 · Identity + posture. Before anything else, the PoP asks two questions at the policy decision point: who is this (via SSO/identity provider) and is the device healthy (disk encrypted, patched, EDR running). This is the heart of identity-as-the-perimeter: your IP address and whether you're 'on the network' no longer grant trust — your verified identity and device posture do.

2 · Single-pass inspection. If identity and posture pass, the traffic is inspected — once. The PoP performs TLS decryption and runs SWG, CASB and DLP in one combined pass, rather than hopping the packet through a chain of separate boxes. 3 · Decision. The combined result is allow, block, or steer. 4 · Steer. The session is sent to the right destination — a SaaS app, an IaaS workload, or a private app via ZTNA — straight from the edge.

That phrase single-pass is worth one more beat, because it's the difference between SASE done well and SASE done badly. The opposite is service-chaining: decrypt at box A, inspect, re-encrypt, hand to box B, decrypt again, and so on. Each hop adds latency and a place to break. A true SASE engine decrypts once and lets SWG, CASB and DLP all read the same plaintext in a single pass — so adding a security check doesn't add a network hop.

$ curl -v https://crm.flipkart.example 2>&1 | grep -E 'subject|issuer'
# When the PoP is decrypting, the server cert your laptop sees is issued by the SASE provider's CA,
# not the app's real CA. That is the SSL/TLS inspection at work.

*  subject: CN=crm.flipkart.example
*  issuer:  CN=Zscaler Root CA; O=Zscaler Inc.
# issuer = the SASE edge CA → inspection is ON for this session
# (a pinned app would compare this against its embedded cert and abort the connection)

④ Adopting SASE — single vs dual vendor, migration, and the Zero Trust map

On a real project the first big fork is single-vendor vs dual-vendor SASE. Single-vendor means one provider delivers both halves — SD-WAN and the full SSE stack — in one converged platform with one console and one policy. Dual-vendor (Gartner's term is a SASE "alternative") keeps a separate SD-WAN vendor and a separate SSE vendor, linked by APIs and service-chaining. Both can tick the same feature boxes, but Gartner increasingly recommends single-vendor for the tighter integration and simpler operations.

Which to pick? If you're greenfield or have a lean team, single-vendor wins on simplicity. If you already run a beloved SD-WAN estate (say a big Cisco or Versa deployment), dual-vendor lets you keep it and add an SSE layer on top. Neither is wrong — but know that dual-vendor buys flexibility at the cost of two policy engines to keep in sync.

What do you consolidate first? You don't boil the ocean. The highest-value, lowest-risk first move is almost always to replace the VPN with ZTNA — it kills the biggest attack surface (the internet-exposed VPN appliance and network-wide trust) and users barely notice. Then route internet/SaaS traffic through the cloud SWG/CASB so branches break out locally with inspection. Then retire the central hub firewall in favour of FWaaS. SD-WAN modernisation of the branch fabric usually runs in parallel.

Why is ditching the VPN first such a clear win? Because VPN appliances are now a prime target. In January 2025, attackers exploited CVE-2025-0282 — a critical unauthenticated remote-code-execution flaw in Ivanti Connect Secure VPN gateways — in the wild before a patch existed, dropping malware on exposed boxes. ZTNA removes that class of risk: there's no public VPN appliance to attack, and a verified user reaches only one app, not the whole flat network.

How SASE maps to Zero Trust. SASE is how you deliver Zero Trust at the network edge. In NIST SP 800-207 language, the PoP's policy engine is the Policy Decision Point (PDP) — it makes the allow/deny call from identity, device and context — and the PoP's enforcement sits in the traffic path as the Policy Enforcement Point (PEP). "Never trust, always verify" stops being a slogan and becomes the literal identity+posture check at every PoP.

One sober note from the real world: putting your security in a vendor's cloud means that vendor's own exposure becomes part of your risk. In the August 2025 Salesloft–Drift OAuth supply-chain breach, attackers used stolen OAuth tokens to pull data from over 700 organisations' Salesforce instances — and the victim list included Zscaler, Cloudflare and Palo Alto Networks themselves. The lesson for you: SASE shrinks your attack surface a lot, but vendor and third-party (OAuth/SaaS) risk doesn't vanish — which is exactly why CASB and DLP for SaaS sit inside the SSE stack.

For your certification path, this lesson is foundational. Security+ (SY0-701) now explicitly tests Zero Trust, SASE and ZTNA — "never trust, always verify," no implicit trust by location. CCSP covers the cloud architecture and access-control thinking SASE embodies. And the broad SSE/SASE concepts here underpin every vendor exam in this series. Get this mental model solid and the rest of the 30 lessons slot into it.