SASE Components: The Core Building Blocks of a SASE Architecture

Secure Access Service Edge (SASE) delivers converged networking and security functions from a global service edge under one policy framework. Gartner introduced the term SASE in its 2019 report, The Future of Network Security Is in the Cloud, authored by Neil MacDonald, Lawrence Orans, and Joe Skorupa.

The defining property of SASE is convergence: functions that traditionally ran as separate appliances become services in shared points of presence (PoPs) and are applied to traffic in a single inspection pass. SASE identifies traffic by user and device identity rather than by IP address, so one policy can follow a user across office, home, and mobile environments.

The full definition, uses, benefits, and challenges are discussed in SASE Solutions.

The core components of SASE are the 5 converged functions listed below, one from the networking side and four from the security side.

DLP joins the five in most platform implementations as the data-centric control woven through SWG and CASB. Each component carries a distinct responsibility within the architecture.

SD-WAN carries traffic from branches, sites, and users to the SASE cloud and selects the optimal path for every session. It decouples the control plane from the data plane and abstracts the underlying transport, so it combines Multiprotocol Label Switching (MPLS), broadband, and LTE links and steers applications based on measured latency, loss, and jitter. Inside SASE, SD-WAN's specific job is to deliver traffic to the nearest PoP, where the security components take over. SD-WAN is also what distinguishes full SASE from Security Service Edge (SSE), which omits it. SASE vs SD-WAN compares the standalone technology with the converged architecture in detail.

Firewall as a Service (FWaaS) delivers next-generation firewall capabilities from the cloud edge instead of from hardware at each site. It applies stateful inspection, application awareness, intrusion prevention system (IPS), and DNS controls to all traffic reaching the PoP. FWaaS centralizes what distributed appliances fragmented: one rule base covers every site and user, and capacity scales in the provider's cloud rather than in branch hardware refreshes. It also supplies the network-layer segmentation that supports Zero Trust's assume-breach principle. SASE vs Firewall analyzes the overlap and differences between edge-delivered and appliance firewalls.

A Secure Web Gateway (SWG) inspects and governs all web-bound traffic passing through the service edge. It performs URL filtering against categorized databases, decrypts and inspects Transport Layer Security (TLS) sessions, blocks malware downloads, and stops access to phishing pages. The SWG runs natively in every PoP, so remote users get the same web policy as office users without the backhaul that traditional models require. Enforcement is per identity and group, covering both acceptable-use and regulatory web controls. SASE SWG covers its capabilities, deployment models, and comparisons in depth.

A Cloud Access Security Broker (CASB) gives the organization visibility and control over SaaS application usage and the data inside it. The CASB discovers every cloud application in the traffic, rates each one for risk, and enforces policy across the four pillars of visibility, compliance, data security, and threat protection. It operates inline at the PoP for real-time session control and through APIs for data at rest in sanctioned platforms such as Microsoft 365. Gartner coined the CASB category in 2012, and SASE absorbed it as a native function rather than a separate proxy. The boundary between the component and the full architecture is explained in SASE vs CASB.

ZTNA brokers access between verified identities and specific private applications on a default-deny basis. It replaces the remote access virtual private network (VPN) by connecting the user to one authorized application through the SASE cloud instead of placing the device on the network. Applications sit behind lightweight connectors that establish outbound-only sessions, making them invisible to internet scanning. Every access request is evaluated against identity, device posture, and context, and can be re-evaluated throughout the session. Of all the components, ZTNA most directly implements Zero Trust within SASE. SASE vs ZTNA discusses its scope relative to the overall architecture.

DLP identifies sensitive data in traffic and enforces policy on its movement. SASE DLP inspects content crossing the PoP, classifies it against patterns such as credit card numbers, national identifiers, and source code, and allows, blocks, encrypts, or quarantines the transfer. Because DLP runs in the same pass as SWG and CASB, the policies covering web uploads, SaaS sharing, and email attachments are enforced simultaneously, reducing latency. Centralized DLP removes the coverage gaps of per-channel DLP products, which historically enforced different rules on different exits. SASE DLP covers the full function in depth.

The networking side of SASE spans the 4 capabilities listed below.

The security side of SASE, the set Gartner groups as SSE, centers on the four controls below, with DLP as the data-protection layer that runs across them.

Threat prevention is not a separate component but a capability most SASE providers integrate across these controls, combining signatures, sandboxing, and TLS inspection within FWaaS and the Secure Web Gateway. These functions matter less on their own than in how they run together.

SASE components work together by sharing one cloud edge, one identity context, and often one inspection pass for every session. A user's traffic reaches the nearest PoP, where the platform establishes identity once and then applies SD-WAN steering, firewall policy, web filtering, cloud application control, access brokering, and DLP as stages of a single processing pipeline rather than as separate hops.

Convergence produces three properties that traditional tool chains lack:

A change to a user's risk level then propagates instantly to every function, because all functions rely on the same identity and context.

The role of the SASE PoP is to serve as the physical enforcement location where all SASE components execute close to the user. A PoP is a provider-operated data center footprint running the full SASE software stack, connected to other PoPs over a private backbone and peered with major cloud and SaaS providers. Users and sites always connect to the nearest PoP, which keeps the added latency low, under 10 ms in some well-provisioned regions. Leading providers operate PoP networks ranging from roughly 50 to over 150 locations. PoP density is a primary vendor selection criterion, because every security function is only as close as the nearest PoP.

The PoP is the dominant enforcement model, but not the only one. Distributed SASE architectures such as Zenarmor replace vendor-operated PoPs with Policy Enforcement Points (PEPs), or enforcement nodes, that run on the organization's own endpoints, gateways, containers, and cloud instances, executing the same component stack where the traffic originates.

The distributed model removes the PoP variables of detour latency, outage failover, shared tenant IP reputation, and exit geography, and it keeps TLS inspection inside customer or partner boundaries, a property described as sovereign SASE. PoP density decides quality in the cloud-delivered model; node-placement flexibility decides it in the distributed model.

In a single-pass design, SASE decrypts, parses, and evaluates each packet stream once, then lets every security engine read from that one analysis. Traditional service chains decrypt and re-encrypt at every appliance, multiplying latency and cost; a single-pass architecture performs TLS interception once, extracts the objects and metadata, and runs firewall, SWG, CASB, DLP, and threat engines against the shared result in parallel. The design cuts processing latency and guarantees that every engine sees identical data, which removes the evasion window between inconsistent inspection points.

Single-pass processing is a headline architectural claim of vendors such as Cato Networks, Palo Alto Networks, and Netskope. Zenarmor extends the claim from the cloud to the software package with its single-application design, in which every component runs inside one processing pipeline on any x86 or ARM64 hardware rather than as coordinated cloud services.

No, not all SASE components are required in every deployment, because organizations prioritize components according to their traffic profile and risk. A cloud-first company may deploy ZTNA, SWG, and CASB while deferring SD-WAN it does not need, resulting in an SSE deployment. A branch-heavy retailer may instead begin with SD-WAN and FWaaS. Gartner's definition treats the converged set as the target architecture, but adoption is legitimately modular. Complete SASE remains the end state, where single-policy coverage is achieved.

Yes, SASE components can be adopted individually, and phased adoption is the dominant real-world pattern. The security functions are also packaged separately as SSE and are often adopted first by organizations whose networking refresh is not yet due. The Security Service Edge model demonstrates this security-first entry point. The condition for safe modular adoption is choosing components that can later converge onto one platform, thereby avoiding a new generation of disconnected point tools.

Choosing which SASE component to deploy first is a 4-step prioritization process that matches the component to the organization's most acute exposure.

Organizations often begin with ZTNA, since remote access is one of the most common initial attack vectors; the Cybersecurity and Infrastructure Security Agency's (CISA) Known Exploited Vulnerabilities catalog repeatedly lists exploited VPN and gateway flaws. This priority is reflected across documented SASE Use Cases.

SASE components differ between vendors in origin, depth, and integration, even when the component checklist appears identical. Networking-origin vendors such as Cato Networks and Versa developed SD-WAN first and expanded security capabilities later. Security-origin vendors such as Zscaler and Netskope developed SWG and CASB first and expanded networking capabilities through partnerships or later development. A third category consists of distributed, edge-native vendors such as Zenarmor, which deliver the full component set as a single application running on customer or partner infrastructure instead of relying on a PoP network.

Depth also varies: ZTNA implementations differ in posture assessment and legacy-protocol support, CASB in API coverage, and DLP engines in classifier quality. Integration varies most of all. True single-pass inspection is easier on a platform built as one system, while platforms assembled from acquired products, including some single-vendor suites, often run those products behind a unified console rather than in a single pass.

Evaluating a SASE vendor means assessing each component at the level of capability the organization actually requires, not simply confirming that the component names are present.