Secure Access Service Edge (SASE)

Secure Access Service Edge (SASE) is a network architecture model that converges wide-area networking (WAN) capabilities with comprehensive cloud-delivered security functions into a single, unified service framework. The model addresses the structural mismatch between legacy perimeter-based security architectures and the distributed reality of cloud applications, remote workforces, and edge computing. This page covers the formal definition and scope of SASE, its technical mechanics, the regulatory and market drivers behind adoption, classification distinctions, deployment tensions, and a structured reference matrix for comparing core components.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix
• References

Definition and Scope

SASE was first formally articulated by Gartner analysts Neil MacDonald and Joe Skorupa in a 2019 research publication titled The Future of Network Security Is in the Cloud, which defined it as a converged cloud-native service combining WAN capabilities with network security functions. The scope of SASE encompasses five foundational functional domains: Software-Defined Wide Area Networking (SD-WAN), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Zero Trust Network Access (ZTNA), and Firewall-as-a-Service (FWaaS).

The architecture is distinguished from prior security models by its delivery mechanism: all security and network functions are delivered from cloud-native Points of Presence (PoPs) distributed globally, rather than through centralized on-premises hardware stacks. Identity — of users, devices, applications, and services — functions as the primary enforcement boundary, replacing the IP address and physical location as the trust anchor.

SASE intersects with federal cybersecurity mandates. Executive Order 14028 (May 2021), issued by the Biden administration, directed federal agencies to adopt Zero Trust architecture principles (EO 14028, WhiteHouse.gov), which are structurally embedded within the ZTNA component of SASE. NIST Special Publication 800-207 provides the formal Zero Trust Architecture reference model that underpins this component (NIST SP 800-207).

The Network Security Authority providers catalog service providers operating across these SASE functional domains in the US market.

Core Mechanics or Structure

A SASE architecture operates through a distributed cloud fabric connecting user endpoints, branch offices, and cloud workloads to security enforcement services delivered at the network edge. The five core components interact in a layered policy enforcement chain:

SD-WAN abstracts the underlying transport layer — MPLS, broadband, LTE, 5G — and applies traffic steering policies based on application type, latency sensitivity, and cost. It replaces static route-based connectivity with dynamic, policy-driven path selection.

Secure Web Gateway (SWG) intercepts and inspects outbound web traffic, enforcing URL filtering, SSL/TLS inspection, malware detection, and data loss prevention (DLP) policies without requiring traffic to backhaul through a central data center.

Cloud Access Security Broker (CASB) sits between users and cloud service providers, applying visibility, compliance, and threat protection controls to SaaS application traffic. CASB addresses the NIST SP 800-210 guidance on access control for cloud systems (NIST SP 800-210).

Zero Trust Network Access (ZTNA) replaces legacy VPN tunnels by granting application-level access based on verified identity and device posture, evaluated at each session. No implicit access to network segments is granted. This aligns with the logical access control requirements articulated in NIST SP 800-207.

Firewall-as-a-Service (FWaaS) delivers Layer 3 through Layer 7 inspection, including intrusion prevention system (IPS) capabilities, from cloud PoPs rather than physical appliances. Policy enforcement is centrally managed but distributed in execution.

Traffic flows from an endpoint to the nearest SASE PoP, where the full security stack is applied in-line before the session is permitted to reach its destination — whether that is the public internet, a SaaS application, or a private data center resource.

Causal Relationships or Drivers

Three structural shifts created the conditions under which SASE became architecturally necessary.

Cloud migration at scale relocated application workloads from on-premises data centers to IaaS and SaaS platforms. The Cybersecurity and Infrastructure Security Agency (CISA) reported in its 2023 Cybersecurity Strategic Plan that federal agencies alone operate across more than 100 cloud service environments (CISA Cybersecurity Strategic Plan FY2024-2026). Backhauling cloud-destined traffic through centralized on-premises security stacks introduced latency and created single points of failure.

Remote and distributed workforce expansion eliminated the physical perimeter as a meaningful security boundary. When endpoints operate outside of corporate office environments, network location provides no reliable signal of trust, making perimeter-based firewalling structurally insufficient.

Regulatory compliance pressure intensified requirements for continuous monitoring, encrypted traffic inspection, and identity-centric access control. HIPAA Security Rule provisions (45 CFR Part 164) require covered entities to implement technical safeguards including audit controls and transmission security (HHS.gov HIPAA Security Rule). PCI DSS 4.0, published by the PCI Security Standards Council in March 2022, introduced requirements for network security controls across all cardholder data environment traffic paths. SASE architectures provide a structural framework for satisfying these controls across distributed environments.

For additional context on the regulatory landscape shaping network security architecture choices, the Network Security Authority purpose and scope provides sector-level framing.

Classification Boundaries

SASE is frequently conflated with adjacent architectures. The classification boundaries are operationally significant:

SASE vs. SSE (Security Service Edge): Gartner introduced SSE in 2021 as a subset of SASE comprising only the security components — SWG, CASB, and ZTNA — without the SD-WAN networking layer. SSE addresses organizations that have separate WAN management or do not require SD-WAN integration. SASE requires both the security stack and the SD-WAN component to be converged under a single vendor or tightly integrated platform.

SASE vs. Zero Trust Architecture (ZTA): ZTA, as defined in NIST SP 800-207, is a security philosophy and policy enforcement model. SASE is a delivery architecture that implements ZTNA as one of its five components. ZTA can be implemented without SASE; SASE cannot be fully realized without ZTNA principles embedded in the access control layer.

SASE vs. SD-WAN: SD-WAN is a networking transport optimization technology. SASE subsumes SD-WAN but adds the complete security stack. Deploying SD-WAN alone provides no inherent security function beyond traffic routing flexibility.

Single-vendor SASE vs. Dual-vendor SASE: The market distinguishes platforms where a single provider delivers all five components natively from deployments where an SD-WAN vendor and a security vendor are integrated through APIs and shared policy management. The latter is often called dual-vendor or hybrid SASE.

Tradeoffs and Tensions

Vendor lock-in vs. best-of-breed capability: Single-vendor SASE platforms offer unified policy management and reduced operational complexity but constrain organizations to one vendor's capability maturity across all five functional domains. Selecting the strongest available tool in each category requires integration effort that partially negates the operational simplicity SASE promises.

Latency vs. inspection depth: Deep packet inspection, SSL/TLS decryption, and full Layer 7 analysis introduce processing latency at SASE PoPs. Organizations with latency-sensitive applications — financial trading systems, real-time voice, industrial control communications — face a tradeoff between inspection comprehensiveness and application performance. The number and geographic density of PoPs directly affects this tension; a provider with 35 PoPs globally serves dispersed workforces differently than one with 100.

Organizational sovereignty vs. cloud delegation: Routing all enterprise traffic through a third-party cloud fabric transfers a degree of visibility and control to the SASE provider. For organizations subject to FedRAMP authorization requirements — governed by the Office of Management and Budget Memorandum M-23-22 (OMB M-23-22, WhiteHouse.gov) — SASE platform FedRAMP authorization status becomes a procurement gate.

Legacy infrastructure coexistence: Most enterprise environments cannot execute a full SASE migration in a single transformation cycle. Operating hybrid environments — where SASE PoPs coexist with legacy MPLS circuits and on-premises firewalls — requires policy synchronization across incompatible management planes, creating gaps where policy enforcement consistency is difficult to audit.

Common Misconceptions

Misconception: SASE is a product that can be purchased. SASE is an architectural model describing the convergence of five functional capabilities. No single product constitutes SASE. Organizations procure platforms or integrated service combinations that approximate the architecture to varying degrees of completeness.

Misconception: SASE eliminates the need for endpoint security. SASE enforces network-level and application-level controls at the cloud edge. Endpoint detection and response (EDR), device posture assessment, and local encryption remain necessary. NIST SP 800-207 explicitly notes that Zero Trust — and by extension ZTNA within SASE — relies on device health signals from endpoint security agents as inputs to access policy decisions.

Misconception: SASE and VPN replacement are equivalent transformations. ZTNA within SASE does replace remote access VPN for many use cases. However, site-to-site connectivity, OT/ICS network access, and partner interconnects often require separate architectural treatment not addressed by ZTNA alone.

Misconception: SASE is only relevant to large enterprises. The CISA Zero Trust Maturity Model, published in 2023 (CISA Zero Trust Maturity Model v2.0), applies to federal agencies of all sizes. Mid-market organizations managing distributed branch offices and SaaS-heavy application stacks encounter the same structural drivers that motivate SASE adoption at enterprise scale.

Checklist or Steps

The following sequence describes the phases organizations move through when evaluating and structuring a SASE deployment. This is a reference sequence, not prescriptive guidance.

1. Inventory existing network and security stack components — catalog SD-WAN, MPLS circuits, on-premises firewall appliances, remote access VPN platforms, and cloud security proxies in use.
2. Map traffic flows by classification — identify which traffic categories (internet-bound, SaaS, private application, site-to-site) currently traverse which enforcement points.
3. Assess identity infrastructure readiness — SASE depends on identity providers (IdPs) capable of issuing device posture signals and user identity context to access policy engines. SAML 2.0 or OIDC federation capability is a structural prerequisite.
4. Define SASE scope boundary — determine whether the target architecture requires SD-WAN convergence (full SASE) or security services only (SSE), based on WAN ownership and existing networking contracts.
5. Evaluate PoP coverage against workforce geography — map provider PoP locations against the geographic distribution of users and branch sites. Assess latency expectations for latency-sensitive application categories.
6. Assess FedRAMP or sector-specific authorization requirements — for federal contractors or regulated-industry deployments, confirm the SASE platform's authorization status under applicable frameworks (FedRAMP, StateRAMP, HIPAA BAA availability).
7. Establish phased migration milestones — define which user populations, traffic categories, or branch sites migrate first, preserving legacy infrastructure for others during the transition window.
8. Define unified policy governance model — establish how network policy (SD-WAN) and security policy (SWG, CASB, ZTNA, FWaaS) will be authored, versioned, and audited in the converged management plane.

The how to use this network security resource page describes how this reference property organizes service and standards information relevant to assessments of this type.

Reference Table or Matrix