SASE and SSE Explained: When Each One Fits

SASE and SSE explained in one line: SASE (secure access service edge) is a cloud-delivered architecture that combines networking, mainly SD-WAN, with security services such as a secure web gateway, a cloud access security broker, and ZTNA, while SSE (security service edge) is the security half of that bundle without the networking. According to NIST SP 800-215, Gartner coined SASE in 2019, and industry press reports that Gartner introduced SSE in 2021. Both names describe a bundle of services rather than one product, so vendors fill them with different parts. This guide shows what is inside, how SSE and SASE differ, and when each one fits.

Where the terms come from

In 2019 Gartner used the term SASE for an architecture that converges networking and security functions and delivers them at global scale as a cloud service. NIST SP 800-215 makes a point worth remembering: the individual services are not new, they are simply delivered together as one package instead of as separate appliances. SSE came later. Press coverage of Gartner's 2021 roadmap on SASE convergence reports that Gartner split out the security services as their own category, and that SSE amounts to SASE without the SD-WAN. Both terms are analyst categories, not standards, so a vendor's definition may differ from Gartner's.

What is inside

Most descriptions share a common core:

• SD-WAN (software-defined WAN): the networking part. It connects branches and users to applications over any transport and sets routing and access policy centrally (NIST SP 800-215)
• SWG (secure web gateway): inspects and filters web traffic for threats and enforces policy
• CASB (cloud access security broker): enforces policy between users and cloud (SaaS) services
• ZTNA: per-app access to private applications, covered in ZTNA vs VPN: Which Should You Choose?
• FWaaS (firewall as a service): cloud-hosted firewalling that can replace some physical firewall appliances
• Add-ons: DLP (data loss prevention), browser isolation, sandboxing, and continuous risk assessment. NIST lists firewall, SWG, anti-malware, IPS, CASB, and DLP as the minimal security services in most commercial SASE offerings

Definitions differ at the edges. Coverage of Gartner's definition names SWG, CASB, and ZTNA as the necessary parts of SSE, while Zscaler and Palo Alto Networks also count FWaaS in their SSE descriptions. Fortinet and Check Point describe SSE by what it secures: web, cloud, and private apps. Microsoft calls its offering a Security Service Edge solution built from Entra Internet Access (a secure web gateway) and Entra Private Access (ZTNA), paired with Defender for Cloud Apps as its CASB. The practical lesson is to ask every vendor for a written list of what is included and which parts need a separate license.

How traffic flows

Instead of sending remote users' traffic back to head office first, a SASE or SSE service has users and sites connect to a nearby point of presence (PoP) run by the provider. NIST SP 800-215 describes clients, branches, and applications connecting to the provider's PoPs, with a security agent on the device often steering traffic. The PoP checks identity, device, and policy, then forwards the traffic to the internet, a SaaS service, or a private application. This avoids the hair-pinning problem NIST describes for VPN-based access, at the price of depending on the provider's network.

How SSE and SASE differ

• Scope: SSE covers the security services only; SASE adds the networking layer (SD-WAN)
• What it changes: SSE can sit on top of your existing network and routing, while SASE also reshapes the WAN, such as branch connectivity, which is a bigger project. Palo Alto Networks notes that SSE does not address network optimization or routing
• Speed to value: Zscaler says SSE is faster to deploy than SASE, and Palo Alto Networks describes starting with SSE and adding SD-WAN later. Both sell both, so read that as a vendor view; your real timeline depends on branches, existing contracts, and team skills
• Who owns it: SSE usually lands with the security team, while SASE needs the network and security teams to design and run it together

When each one fits

• Mostly remote or hybrid users, heavy SaaS use, and no wish to change the WAN: start with SSE (SWG, CASB, ZTNA). CISA and partners urge organizations to move toward Zero Trust, SSE, or SASE for greater visibility of network activity
• Many branches and an MPLS or SD-WAN renewal coming: consider SASE so networking and security move together. NIST SP 800-215 notes that MPLS reaches the internet only through limited access points, which adds latency
• An SD-WAN that already works well: choose SSE first and check that it works with your SD-WAN, rather than replacing both
• Small office, mostly on-premises systems, few remote users, or isolated networks such as OT: you may not need a cloud edge service yet, and a well-run firewall may be enough. See NGFW, UTM, and WAF compared

Strengths and limits

• Strength, one policy everywhere: NIST SP 800-215 lists applying the same security policy to all users regardless of location, one dashboard for visibility, and fewer physical appliances to manage
• Strength, visibility: web and SaaS traffic passing through one place also helps you see tools nobody approved, including AI tools. See Shadow AI: Risks and Response
• Limit, the provider is in the path: traffic depends on PoP performance and availability. Check Point lists performance concerns from routing through a centralized architecture, and NIST SP 800-207 notes that replicating enforcement points reduces the risk but does not remove it
• Limit, integration with legacy and on-premises systems: Check Point lists integration with existing systems and cloud compliance requirements among deployment challenges
• Limit, inspecting encrypted traffic and privacy: you must decide what to inspect, what to exclude, and who can see logs, including where data is processed when PDPA matters
• Limit, licensing and lock-in: components may be licensed separately. Microsoft, for example, documents most of its services on a per-user license model

How to adopt with less risk

A staged approach limits risk. Start by mapping where users and applications really are, decide the scope (SSE only, or SASE), pilot with one group, move web and SaaS traffic first, then private applications, and finally retire the appliances and VPN rules the service replaced. Keep a documented fallback path for the day the provider has an outage.

Questions worth asking every vendor:

• Which components are included in the price, and which need extra licenses?
• Where are the PoPs, and what happens when one fails?
• Which protocols do private-app connections support, including UDP?
• How is encrypted traffic inspected, and what can be excluded?
• Can logs go to our SIEM, and how long are they kept?
• If SSE and SD-WAN come from different vendors, how do they work together?
• Can we export our policies and leave?

Start today

• Map your traffic: how much goes to SaaS and the internet versus the data center, where users and branches are, and what the VPN and proxies carry today
• Inventory overlapping tools: VPN, proxy, firewall, CASB, and SD-WAN licenses with renewal dates. You may already own some SSE components
• Define the problem first: is it remote access, web filtering, SaaS data control, or branch connectivity?
• Write requirements and exit terms before any demo
• Pick a pilot: one group, such as remote contractors, or one branch

To see where network access sits among your wider zero trust gaps, try the self-assessment, and read Zero Trust Architecture: Components and Roadmap for the pillars these services help support.

Common mistakes

• Buying by acronym: SASE or SSE on a quote does not tell you what is included
• Starting with SD-WAN when the problem is security, or the reverse. Choose by problem
• Forgetting the exit: policies may not be portable, so ask early
• Ignoring user experience: test latency from real locations and with real apps before expanding
• Skipping availability: no fallback path when the provider has an outage
• Replacing everything at once: moving in waves makes problems easier to fix

DLP is one of the services often bundled with SSE and works at the traffic inspection point; for its limits and how to use it, see What Is DLP? Data Loss Prevention and Shadow AI Risk.

References and further reading

• NIST SP 800-215: Guide to a Secure Enterprise Network Landscape: primary source on ZTNA, SD-WAN, and SASE, including that Gartner coined SASE in 2019
• CISA and partners: Modern Approaches to Network Access Security (2024): urges a move toward Zero Trust, SSE, and SASE
• Network World: SSE is SASE minus the SD-WAN: press report on Gartner's 2021 introduction of SSE and its core components
• Zscaler: What is SASE?: vendor view: SASE as SD-WAN converged with SSE
• Zscaler: What is Security Service Edge?: vendor view: SSE components and when to start with SSE
• Palo Alto Networks: SASE vs SSE: another vendor's view of the differences and when to choose each
• Fortinet: What is SASE?: a vendor definition that treats SSE as the security subset of SASE
• Check Point: What is SASE?: a vendor definition with deployment challenges
• Microsoft Learn: What is Global Secure Access?: an example of SSE assembled from SWG, ZTNA, and CASB, with licensing