Concept
SASE Architecture: How It Works and the Main Models
Short answer: Secure Access Service Edge (SASE) architecture is the design that combines wide area networking and network security into one service with one policy. It has three layers: a networking layer that carries traffic, a security layer that inspects it, and a single management plane that defines policy for both. The main architectural choice is where traffic is inspected: in a vendor's cloud points of presence (PoPs), on the organization's own endpoints and gateways, on infrastructure the organization runs centrally, or a mix.
This brief explains the layers of a SASE architecture, how traffic moves through it, the four architecture models, and how an organization chooses between them.
What is SASE Architecture?
SASE architecture is the structure that delivers networking and security as one converged service, close to the user and the application instead of in a central data center. Gartner introduced the term SASE in its 2019 report The Future of Network Security Is in the Cloud.
The architecture replaces a hub-and-spoke model. In that older model, branch and remote traffic travels back to a headquarters data center for inspection before it reaches the internet or cloud applications. SASE moves inspection to the edge, so each connection is checked near where it starts.
A SASE architecture is defined less by a product list than by three properties: one policy for every user and location, identity as the basis for access decisions, and inspection that follows the user wherever they connect.
What are the Layers of a SASE Architecture?
The layers of a SASE architecture are the networking layer, the security layer, and the management plane.
| Layer | What it does | Typical functions |
|---|---|---|
| Networking layer | Connects users, branches, data centers, and cloud workloads, and selects the path for each session | Software-defined wide area network (SD-WAN), mesh or overlay networking, path selection |
| Security layer | Inspects traffic and enforces access and threat policy | Firewall as a Service (FWaaS), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Zero Trust Network Access (ZTNA), Data Loss Prevention (DLP) |
| Management plane | Defines policy once and distributes it to every enforcement point, and collects logs | Central console, identity provider integration, reporting |
The security layer on its own is called Security Service Edge (SSE). SASE is SSE plus the networking layer, managed together.
What is a Policy Enforcement Point in SASE?
A Policy Enforcement Point (PEP) is the place where a SASE architecture applies policy to live traffic. Every packet that a SASE policy covers passes through a PEP, which inspects it and allows, blocks, or changes the session.
Where the PEPs sit is the most important design decision in a SASE architecture. It decides how far traffic travels before inspection, what happens when a connection to the vendor drops, and where inspected data is processed.
What is the Role of the Management Plane?
The management plane is the control layer where administrators define one policy and push it to every PEP. It connects to the organization's identity provider, so rules can refer to users and groups instead of IP addresses.
The management plane does not need to sit in the traffic path. In most designs, enforcement points keep applying their last policy if they lose contact with the management plane, and they receive updates when the connection returns.
How Does Traffic Flow Through a SASE Architecture?
Traffic flows through a SASE architecture in four steps for each new session.
- Identify the user and device: The client or gateway confirms who the user is through the identity provider and checks the device's posture, such as operating system version or disk encryption.
- Reach the nearest enforcement point: The session goes to a PEP, either in a nearby cloud PoP or on the device or local gateway itself.
- Inspect and decide: The PEP decrypts the traffic where policy requires it, identifies the application, and applies firewall, web, cloud application, and data rules in one pass.
- Forward and log: Allowed traffic continues to the internet, the cloud application, or the private application. The PEP sends a log record to the management plane.
Where step 2 happens is what separates the architecture models below.
What are the Main SASE Architecture Models?
The main SASE architecture models are cloud-native, hybrid, self-hosted, and distributed. They share the same security functions and differ in where the PEPs run and who operates them. These are the same four types the SASE.net evaluation checklist compares.
| Attribute | Cloud-native | Hybrid | Self-hosted | Distributed |
|---|---|---|---|---|
| Where inspection runs | Vendor-operated PoPs | Vendor PoPs plus on-site appliances | The organization's own data center or cloud, centrally | On endpoints, branch gateways, and the organization's cloud instances |
| Who operates the inspection points | The vendor | Shared | The organization | The organization, managed from one console |
| Path for internet traffic | Device or branch to a PoP, then to the destination | Depends on the location | Device or branch to the central site, then to the destination | Device or branch directly to the destination |
| Added latency | A round trip to the nearest PoP | Varies by location | A trip to the central site | Local processing only |
| If the vendor cloud is unreachable | Traffic that must pass through a PoP is affected | PoP traffic is affected; appliances continue | Not dependent on a vendor cloud | Local enforcement continues with the last policy |
| Where inspected data is processed | In the vendor's PoPs | Mixed | On the organization's infrastructure | On the organization's infrastructure |
What is a Cloud-Native SASE Architecture?
A cloud-native SASE architecture sends user and branch traffic through tunnels to a global network of vendor-operated points of presence, where the security stack inspects it. It is the model Gartner described in 2019 and the most common one today.
Its strength is simplicity: branches need only a light tunnel device, remote users connect to the nearest PoP, and the vendor runs the infrastructure. Its trade-offs are the extra round trip for every session, dependence on the vendor's PoP coverage in each region, and inspection of the organization's traffic on infrastructure it doesn't control.
What is a Hybrid SASE Architecture?
A hybrid SASE architecture combines vendor cloud PoPs with appliances on the organization's sites, under one policy. A common pattern keeps firewalls at large offices and uses cloud PoPs for remote users and small branches.
Hybrid designs fit organizations in transition, such as those with recent branch firewalls they want to keep while adding cloud-delivered access for remote staff.
What is a Self-Hosted SASE Architecture?
A self-hosted SASE architecture runs the security stack on infrastructure the organization owns and operates, usually in its own data centers or private cloud, with traffic routed there for inspection. It gives full control over where traffic is decrypted and where logs are kept.
The trade-off is operating effort and a central path: the organization runs and scales the inspection infrastructure itself, and remote traffic still travels to those central sites.
What is a Distributed SASE Architecture?
A distributed SASE architecture runs the security stack on the organization's own enforcement points: endpoint agents, branch gateways, and cloud instances. A central cloud console defines policy, but inspection happens where the traffic starts, with no central chokepoint.
Its strengths are minimal added latency, continued enforcement when the vendor cloud is unreachable, and data that stays on the organization's infrastructure. Its trade-off is that the organization runs software on more devices, so deployment and updates must be automated from the console.
Zenarmor follows this model: one app runs on gateways, endpoints, and cloud instances, and enforces policy locally instead of routing traffic through vendor PoPs.
What Problems Does SASE Architecture Solve?
SASE architecture solves the problems that appear when users and applications leave the data center.
- Backhauled traffic: Remote and branch traffic no longer travels to a central site before reaching cloud applications.
- Inconsistent policy: One policy covers office, remote, and cloud access instead of separate rules in separate products.
- Network-based trust: Access depends on identity and device posture, not on being inside the corporate network.
- Tool sprawl: Several point products and their consoles become one service and one management plane.
What are the Limitations of SASE Architecture?
The limitations of SASE architecture depend on the model, but four apply broadly.
- Migration effort: Moving from separate firewalls, virtual private networks (VPNs), and proxies to one policy takes planning and usually happens in phases.
- Identity dependence: Policy is only as good as the identity data behind it, so the identity provider must be clean and complete.
- Encrypted traffic: Full inspection requires Transport Layer Security (TLS) decryption, which needs certificates on devices and exceptions for sensitive categories.
- Vendor coupling: A single-vendor platform simplifies operations but makes the organization dependent on one supplier's roadmap.
How Should an Organization Choose a SASE Architecture?
An organization chooses a SASE architecture by matching the enforcement model to where its users, data, and applications are. Work through these steps.
- Map traffic: List where users work, which applications they use, and where those applications run.
- Set latency and resilience needs: Decide which sites and applications can't tolerate an extra round trip or a cloud outage.
- Check data location rules: Confirm whether regulations or contracts limit where inspected traffic may be processed.
- Review existing infrastructure: Note which branch firewalls and endpoint tools can run or host an enforcement point.
- Pick the model per location: Choose cloud-native, hybrid, self-hosted, or distributed, and confirm that one management plane covers all of it.
- Pilot one site and one user group: Measure latency, policy coverage, and operating effort before rolling out further.
Frequently Asked Questions
What Are the 5 Core Components of SASE Architecture?
The five core components are SD-WAN, Firewall as a Service, Secure Web Gateway, Cloud Access Security Broker, and Zero Trust Network Access. Data Loss Prevention usually runs inside the SWG and CASB.
Is SASE Architecture Cloud-Only?
No. The first SASE designs inspected traffic in vendor clouds, but hybrid, self-hosted, and distributed architectures run the same security functions on the organization's own endpoints, gateways, and cloud instances under one cloud-managed policy.
What Is the Difference Between SASE Architecture and a Traditional Network Architecture?
A traditional network architecture sends remote and branch traffic to a central data center for inspection and trusts users inside the network. SASE architecture inspects traffic at the edge, close to the user, and grants access by identity and device posture.
What Is the Difference Between SASE and SSE Architecture?
SSE architecture includes only the security layer: SWG, CASB, and ZTNA. SASE architecture adds the networking layer, such as SD-WAN, and manages both under one policy.