What is SASE? Secure Access Service Edge, explained properly

What is SASE?

SASE (Secure Access Service Edge) — pronounced “sassy” — is a cloud-delivered architecture that converges wide-area networking and network security into a single service, applied at the edge closest to the user. Gartner introduced the term in 2019. The defining idea is that security policy follows the identity, not the location: the same rules apply whether a user is in headquarters, at home, or on a hotel network.

The one-sentence version most people find useful: SASE is what you get when you stop backhauling traffic to a data centre in order to secure it, and instead put the network and the security in the same cloud, everywhere your users are.

The word “converged” is doing heavy lifting there, and it is the part vendors most often gloss over. A collection of separately-acquired products in one portal is integration, not convergence. Real convergence means one policy engine, one inspection of the traffic, one identity model and one log — because every place those things are duplicated is a place where policy drifts and an attacker finds a seam.

Why did SASE happen?

SASE exists because the assumptions behind traditional network security stopped being true. Applications left the data centre for SaaS and public cloud, users left the office, and the hub-and-spoke model that backhauled every packet to a central stack of appliances became simultaneously slower, more expensive and less secure than the thing it was protecting against.

Consider what the old architecture actually assumed:

• Applications live in a data centre you own.
• Users sit in offices connected to it by MPLS.
• Being inside the perimeter is a reasonable proxy for being trusted.
• Security is a stack of appliances you can put in one place.

Every one of those is now false for most organisations. When the application is in AWS and the user is at home, hauling their traffic across the country to a firewall and back adds latency, cost and no meaningful safety. SASE is the architectural response: move enforcement to a distributed cloud fabric, and anchor trust to verified identity and device posture rather than to network position.

What are the components of SASE?

A complete SASE platform converges a network layer — SD-WAN and a global private backbone — with a security layer comprising ZTNA (Zero Trust Network Access), SWG (Secure Web Gateway), CASB (Cloud Access Security Broker), FWaaS (Firewall as a Service) and DLP (Data Loss Prevention), all governed by a single identity-aware policy.

The list is the easy part. The hard part — and the only part worth evaluating a vendor on — is whether those functions share one policy, one inspection pass and one data model, or whether they are seven products behind one login.

What is the difference between SASE, SSE and SD-WAN?

SD-WAN is the network half. SSE (Security Service Edge) is the security half — ZTNA, SWG, CASB, and usually FWaaS and DLP, delivered from the cloud. SASE is both halves converged into one service. In short: SASE = SSE + SD-WAN, under a single policy. Gartner introduced SSE in 2021 to describe the security functions bought independently of the WAN.

Practical guidance: if your immediate problem is remote users and SaaS, SSE alone will move the needle quickly. If your problem also includes branch connectivity, MPLS cost or unpredictable performance between regions, you are looking at SASE. Most organisations arrive at SASE eventually — the question is whether they get there through one architecture or through two projects that later have to be reconciled.

What is ZTNA, and why does it replace VPN?

ZTNA (Zero Trust Network Access) grants a verified user access to a specific application, and nothing else. A VPN grants access to a network segment and trusts everything that follows. That difference is why one compromised VPN credential so often becomes a full lateral-movement incident, and why ZTNA is usually the first component organisations deploy.

• Access is per application, not per network. Nothing is reachable until policy says it is.
• Applications are invisible until authorised. Nothing to scan means nothing to attack.
• Trust is continuous. Identity, device posture, location and risk are evaluated on an ongoing basis, not once at connect time.
• Lateral movement is designed out. A compromised session reaches one application, not the whole subnet.

The phrase Robin uses in briefings is deliberately blunt: trust no packet, verify everything. The engineering translation is that network position must stop being a credential.

Single-vendor SASE or multi-vendor SASE?

Single-vendor SASE delivers networking and security from one converged platform, with one policy engine and one log. Multi-vendor SASE stitches a separate SD-WAN and SSE together. Single-vendor generally wins on operational simplicity, consistent policy and unified visibility; multi-vendor wins where an existing investment cannot yet be displaced. Gartner has published a dedicated single-vendor SASE Magic Quadrant since 2023.

The honest trade-off, without vendor framing:

• Single-vendor. One policy, one inspection, one support call, one place to look during an incident. The cost is concentration — you are betting on one platform’s roadmap.
• Multi-vendor. Best-of-breed choice and reuse of existing kit. The cost is seams: two policy models, two logging schemes, two escalation paths, and an integration that only you own.

The question that settles it in most evaluations is not a feature comparison. It is: when something breaks at 3am, how many consoles does the on-call engineer have to correlate? Convergence is an operations decision dressed as an architecture decision.

How do you migrate to SASE?

Migrate in layers, not in one cutover. The pattern that works: start with ZTNA to retire remote-access VPN, then move internet and SaaS traffic to the SASE cloud for inspection, then convert branch sites from MPLS as circuits come up for renewal, and only then decommission the legacy stack. Each stage delivers value on its own and is independently reversible.

1. Baseline. Map applications, users, sites, current egress paths and existing security controls. Establish what “working” currently means, in numbers.
2. ZTNA first. The fastest, most visible win — remote access improves for users and lateral-movement risk drops immediately.
3. Internet and SaaS. Point outbound traffic at the SASE cloud. Turn on SWG, CASB and DLP in monitor mode before enforcing.
4. Branch conversion. Migrate sites as MPLS contracts expire. Run hybrid deliberately; hybrid is a stage, not a failure.
5. Consolidate policy. Retire duplicated rules. This is where the operational savings actually appear, and where most projects stop too early.
6. Decommission. Only once telemetry proves the new path carries everything.

The most common migration mistake is re-implementing legacy firewall rules verbatim in the new platform. You will have imported the old architecture’s assumptions along with its rules, and you will get the cost of SASE without the security model.

How does SASE relate to AI security?

SASE has become the practical enforcement point for enterprise AI usage. Because employee AI activity is traffic to a cloud service, the SASE platform is where you can discover shadow AI, apply identity-aware policy per AI tool, inspect prompts and uploads with inline DLP, protect internal AI applications with ZTNA, and produce one unified audit log — without deploying an agent for every new AI product.

This is the intersection where Robin’s two specialisms meet, and it is why the SASE conversation and the AI conversation increasingly happen in the same meeting. The full treatment is in AI Security: what it actually means, and what actually works.

Frequently asked questions