SASE (Secure Access Service Edge) is an IT architecture model in which networking and security functions are combined into a single, cloud-delivered service. The service runs at the network edge, close to the user or device. Instead of routing all traffic through a corporate headquarters, SASE inspects it and applies rules at many of the provider’s distributed points. Access is decided by the user’s identity and context, not by where they sit in the network.

What is SASE?

The term SASE was introduced by the analyst firm Gartner in 2019, in the report “The Future of Network Security Is in the Cloud.” It describes the convergence of two areas that previously evolved separately: software-defined wide area networking (SD-WAN) and cloud-delivered network security services.

SASE responds to a simple fact. In the past, resources, users and security controls all sat inside a corporate “perimeter” — the network boundary a company fully controlled. Today applications live in the cloud and people work remotely. The old model no longer fits.

The most important shift is moving away from backhauling. Backhauling means hauling traffic from remote workers and branch offices back to a central data center just to push it through the security controls located there. In the SASE model, traffic inspection and rule enforcement happen at the provider’s nearest node. Access is decided by the identity of the user or device, in line with the Zero Trust principle (“never trust, always verify”).

What components make up SASE?

SASE is not one product but several technologies managed from one place. They are usually split into a networking layer and a security layer.

SD-WAN — the networking layer

SD-WAN (Software-Defined Wide Area Network) handles the sensible routing of traffic between branches, users and applications. It picks the best path on the fly, can combine different links (MPLS, broadband internet, LTE/5G) and send traffic straight to cloud applications instead of hauling it back through headquarters. It is the network foundation on which the SASE security services rest.

SWG — Secure Web Gateway

An SWG (Secure Web Gateway) inspects users’ web traffic. It filters URLs and content categories, blocks known malicious domains and enforces internet-use policy. A key element is the inspection of encrypted (TLS/SSL) traffic. Most traffic today is encrypted — including the channels used to deliver malware. Without decryption, that traffic stays unreadable to security controls.

CASB — Cloud Access Security Broker

A CASB (Cloud Access Security Broker) sits between users and cloud (SaaS) applications. It shows which services a company actually uses — including shadow IT, the applications adopted without the IT department’s knowledge. CASB enforces cloud access rules, detects risky settings and provides DLP (Data Loss Prevention) functions, limiting the leakage of sensitive data through cloud channels.

ZTNA — Zero Trust Network Access

ZTNA (Zero Trust Network Access) grants access to specific applications on a “never trust, always verify” basis. A classic VPN admits the user into the whole network. ZTNA works differently: it grants access to a single application and only for the duration of a session, after checking identity and context (who, from which device, from where). Applications stay invisible to unauthorized parties — they are not exposed on a public address. This gives an attacker fewer targets and makes it harder to move around the network.

FWaaS — Firewall as a Service

FWaaS (Firewall as a Service) is a firewall delivered from the cloud. It filters and controls traffic across layers L3 to L7. It takes over the tasks of traditional hardware firewalls — port and protocol control, application inspection, IPS (intrusion prevention systems) — but as a service that is easy to scale and managed uniformly. There is no need to maintain appliances at every location.

Centralized management

What holds SASE together is a single place to manage it. From there, you set rules that apply the same way to all users and all locations, no matter where someone connects from. This gives one consistent view of traffic and removes the problem of settings drifting apart across separately configured devices.

Why did SASE emerge?

The immediate driver was the breakup of the “perimeter” model, shaped by several trends at once:

Hybrid and remote work — people connect from anywhere and no longer sit behind the corporate firewall.
The move to cloud — applications and data have shifted to SaaS and public clouds, so traffic no longer revolves around the corporate data center.
Distributed users and devices — branches, mobile devices and IoT generate traffic that is not worth backhauling to headquarters.
The inefficiency of backhauling — routing cloud-bound traffic through headquarters adds latency and link cost while no longer providing a real security benefit.

What benefits does SASE provide?

Consolidation — several functions (networking, SWG, CASB, ZTNA, FWaaS) replace a collection of separate products from different vendors.
Less complexity and cost — fewer appliances to maintain, fewer consoles, and often lower link costs by moving away from MPLS and backhauling.
Zero Trust in practice — access based on identity and context, checked on every session, instead of implicit trust inside the network.
One view and one set of rules — consistent rules and insight into all users’ traffic from one place.
Performance — inspecting traffic close to the user and shorter paths to applications reduce latency compared with backhauling.

How does SASE differ from SSE?

This is one of the most common sources of confusion. SSE (Security Service Edge) is a subset of SASE that Gartner carved out in 2021. It covers only the cloud-delivered security layer — without the networking part.

SSE = SWG + CASB + ZTNA (and usually FWaaS). It is the “security half” of SASE.
SASE = SSE + SD-WAN. That is, the security layer plus the networking layer, combined and managed together.

In practice, many companies start by deploying SSE, because securing access to the cloud and applications is the most pressing need. They add the SD-WAN component later, arriving at full SASE. Gartner introduced SSE precisely because networking and security are often handled by different vendors and different teams. Separating the layers reflects real purchasing paths.

How does SASE differ from MPLS and traditional networks?

MPLS is a carrier-link technology that guarantees bandwidth and quality. It was typically used to connect branches to headquarters and the data center. In the pre-SASE model, branch traffic flowed over MPLS to headquarters, where the security controls stood.

MPLS: fixed, expensive point-to-point links; cloud traffic backhauled through headquarters; scaling is costly and slow.
SASE/SD-WAN: flexible use of any links (internet, LTE/5G, MPLS too); direct paths to cloud applications; traffic inspection in the cloud, close to the user.

SASE does not always remove MPLS entirely. More often it reduces dependence on it and treats MPLS as one of the links within SD-WAN — especially where quality guarantees are needed.

How does SASE differ from a VPN?

A classic VPN creates an encrypted tunnel and — after login — admits the user into a segment of the corporate network, often with broad access. ZTNA within SASE works differently. It provides individual applications rather than the whole network, checks session context, and does not expose resources on a public address. From a security standpoint the difference is large. A compromised VPN account gives an attacker a foothold in a wide network and the ability to move around it. ZTNA limits reach to individual, permitted applications.

What are the use cases for SASE?

Secure hybrid and remote work — the same rules and the same traffic inspection regardless of where an employee connects from.
Branch connectivity — secure, direct branch access to cloud applications, without backhauling traffic to headquarters.
MPLS migration — gradual replacement of expensive carrier links with flexible SD-WAN.
Global reach — the provider’s distributed points of presence deliver low latency to users across regions.
VPN replacement — ZTNA as a more secure alternative to tunnel-based remote access.

What are the implementation challenges of SASE?

Deploying SASE is an architectural and organizational project, not just a service purchase:

Merging networking and security teams — SASE combines domains that in many companies belong to separate teams with different priorities.
Step-by-step migration — a “big bang” switch is rarely feasible; deployment usually starts with ZTNA or SSE, with SD-WAN added later.
TLS inspection — decrypting traffic is needed for the security controls to work, but it raises questions of performance, privacy and exceptions (e.g. banking or health traffic).
Vendor lock-in — handing both networking and security to one provider is convenient but increases dependence.
Point-of-presence (PoP) coverage — quality depends on how densely and where the provider has its nodes relative to users.

How to choose a SASE vendor: single or multiple?

One of the main dilemmas is the vendor model:

Single-vendor SASE — all components (SD-WAN and the entire security layer) come from one provider and are natively integrated. Pros: consistent rules, one console, simpler operations. Cons: stronger lock-in and the risk that not every component is best-in-class.
Dual/multi-vendor SASE — for example, SD-WAN from one provider and SSE from another. Pros: a choice of best-of-breed components, less lock-in. Cons: harder integration, the risk of inconsistent rules and a fragmented view of traffic.

When choosing, it is worth assessing: point-of-presence (PoP) density in the regions where the company operates; the depth of each component, not just its presence “on the list”; the quality of TLS inspection and DLP; the ability to pass telemetry to your own systems; and the billing model.

SASE from a cybersecurity perspective — what vendors don’t tell you

For a security team, SASE brings real benefits: it consistently enforces Zero Trust, makes it harder to move around the network (ZTNA does not expose the whole network), reduces the number of attack targets compared with publicly reachable VPN gateways, and provides consistent rules for distributed users.

There is, however, a consequence that vendor materials usually leave out: in a SASE architecture, the point where traffic is observed and telemetry is collected shifts into the provider’s cloud. Inspection and event logging happen in the provider’s infrastructure rather than in a network the company fully controls. This has practical implications:

Log retention and availability — the scope, format and retention period of traffic logs depend on the provider and the plan; your own SOC (security operations center) may have limited or delayed access to raw telemetry.
Detection in your own SOC/NDR — NDR (network detection and response) systems and detection rules built on traffic from the corporate network lose some visibility when traffic is inspected and terminated at the provider. You then need to plan the export of logs and telemetry to your own SIEM and to verify whether the provider exposes the data at a usable resolution.
Detection dependence on the provider — part of detection effectiveness moves to the provider’s side. This should be reflected in the risk model and in contractual requirements.

This is not an argument against SASE, but a reminder that the decision also has a security-operations dimension. You must deliberately plan where logs are generated, who stores them, and how they reach your own detection and response tooling.

Learn more

Microsegmentation — Microsegmentation limits lateral movement, supporting SASE’s zero-trust access control.
BYOD (Bring Your Own Device) — BYOD increases endpoint risk, which SASE addresses through identity and policy-based access.
SaaS Security Posture Management (SSPM) — SSPM secures SaaS apps that SASE users access through cloud-delivered controls.
Zero Trust Architecture — Zero Trust is a core model behind SASE’s verify-explicitly access approach.
North-South vs East-West Traffic — SASE mainly inspects north-south traffic between users and cloud services.
Cloud Security Posture Management (CSPM) — CSPM helps secure cloud environments that SASE connects and protects.
On-premise / Cloud / Hybrid — SASE provides consistent access control across on-premise, cloud, and hybrid setups.
SaaS / IaaS / PaaS — SASE secures access to SaaS, IaaS, and PaaS resources from a common policy layer.

Secure Access Service Edge (SASE)