SSE (security service edge) is the security half of SASE (secure access service edge): a cloud-delivered secure web gateway (SWG), cloud access security broker (CASB) and zero trust network access (ZTNA), often with firewall as a service (FWaaS) and data loss prevention (DLP). SASE adds the networking half, chiefly SD-WAN, and converges both into one service. NIST SP 800-215 credits Gartner with coining the SASE term in 2019; as of October 2026, the Mplify Alliance (formerly MEF Forum) publishes standards for both.
More security analysis is listed in Enterprise Techie’s topic index.
In this guide
Key facts
| Term | What the source says | Source |
|---|---|---|
| SASE | Networking and security converged, delivered globally as a cloud service | NIST SP 800-215 (November 2022) |
| SSE | Secures access to the web, cloud services and private applications | Gartner definition, quoted by Mplify |
| SASE standard | Service attributes agreed between subscriber and provider | MEF 117 (October 2022), revised as Mplify 117.1 (June 2025) |
| SSE standard | Security functions and solutions that make up an SSE | Mplify 169 (February 2026) |
| ZTNA principles | Per-session access by dynamic policy; location grants no trust | NIST SP 800-207 (August 2020) |
| Maturity roadmap | Five pillars, stages from Traditional to Optimal | CISA Zero Trust Maturity Model v2.0 (April 2023; cisa.gov now labels the page archived) |
What SSE and SASE mean
NIST SP 800-215 describes SASE as converging “networking and security functions” and delivering them “at a global scale as a cloud service.” The services “are not new but simply delivered together as a single package.” Users and sites reach these services through the provider’s points of presence (PoPs).
SSE is the security subset. The Gartner definition Mplify quotes on its SSE certification page says SSE “secures access to the web, cloud services, and private applications” and is “primarily delivered as a cloud-based service.”
MEF 117 says it “expands upon the Gartner SASE concept”; Mplify 117.1 superseded it. Mplify 169 defines an SSE framework whose functions can come from different vendors, and calls the SWG a “secure gateway” because it now handles more than web traffic.
SASE components
| Component | What it does | In SSE | In SASE | Source |
|---|---|---|---|---|
| SWG | Filters outbound user traffic through HTTP and HTTPS inspection | Yes | Yes | NIST SP 800-215; Mplify 169 |
| CASB | Sits between users and cloud services: discovery, data protection, threat and misconfiguration detection | Yes | Yes | NIST SP 800-215; Mplify 117.1 |
| ZTNA | Identity- and context-based access to internally hosted applications | Yes | Yes | Mplify 117.1 (Gartner definition); NIST SP 800-207 |
| FWaaS | A firewall delivered as a cloud service | Often | Yes | Mplify 169; NIST SP 800-215 |
| DLP | Detects confidential data in a flow and prevents its exfiltration | Often | Yes; required in Mplify 117.1 | Mplify 117.1; NIST SP 800-215 |
| Remote browser isolation | Runs web content in a remote sandbox so malicious code never reaches the user | Sometimes | Sometimes | Mplify 117.1; NIST SP 800-215 |
| SD-WAN | Central policy for routing, access control and application priority over any transport | No | Yes | NIST SP 800-215; Mplify 117.1 |
ZTNA in NIST’s model
NIST SP 800-207 supplies the principles: network location alone does not imply trust, access is granted per session with least privilege, and dynamic policy weighs identity, application and device state. A policy engine decides, a policy administrator opens or closes the path, and a policy enforcement point (PEP) enables, monitors and terminates the connection.
NIST lets the PEP split into a client side, such as a laptop agent, and a resource-side gateway: the shape of agent-based ZTNA. Its portal model needs no client software, which suits BYOD, but the enterprise sees a device only while it is connected. Mplify 117.1 notes that Gartner’s ZTNA definition has become synonymous with VPN replacement and adopts a broader one covering on-premises access. NIST counts service accounts among the subjects a policy engine must know; for AI agents, see the AI agent identity governance guide.
SSE vs SD-WAN
They solve different problems. NIST SP 800-215 describes SD-WAN as separating the control and data planes so routing, access control and application priority are set centrally, over transports from MPLS to broadband, 4G/LTE and 5G. SSE controls what users reach and inspects what they send; SD-WAN decides how packets travel between sites.
They overlap at the branch edge, where SD-WAN appliances can carry firewall and SWG functions. Mplify 117.1 requires a SASE provider to enforce security functions running in both services according to the subscriber’s SASE policy, requires encryption between SASE edges, and recommends MEF 70.2 SD-WAN to connect them.
An SSE service can still take branch traffic. Microsoft describes the products behind Global Secure Access as its SSE solution; its remote network option accepts an IPsec tunnel from branch equipment but “doesn’t provide a secure connection between one remote network and another.” Site-to-site traffic stays with the WAN.
SSE alone or full SASE
When SSE alone is enough
- Most users are remote or hybrid, and most traffic goes to the internet and SaaS.
- Branches are few, with little traffic between them.
- An existing SD-WAN can tunnel to the SSE provider. Cisco, for example, says Catalyst SD-WAN integrates with Zscaler, Cloudflare, Palo Alto, Microsoft and Netskope.
- The funded project is retiring VPN concentrators and on-premises proxies, not the WAN.
When full SASE fits
- A branch-heavy network is replacing MPLS with broadband or wireless links, so application-aware path selection matters.
- The goal is one policy for branch and remote users; NIST SP 800-215 lists “uniform security policy across all users, regardless of location” and fewer physical appliances among SASE’s primary functions.
- Branch routers and firewalls are due for refresh anyway.
Single-vendor vs dual-vendor SASE
Single-vendor SASE means buying SD-WAN and SSE from one provider. Dual-vendor, or best-of-breed, pairs one vendor’s SD-WAN with another’s SSE, joined by tunnels such as the IPsec connection Microsoft documents.
Single-vendor offers one console, one policy language and one support contract, with integration the vendor owns. The risk is concentration: NIST SP 800-207 warns that proprietary formats can lock an enterprise in, with switching costs such as translating policy rules, and that an outage at a hosting provider could stop the whole enterprise if the cloud policy engine becomes unreachable. NIST advises weighing switching costs and supply chain risk alongside performance.
Dual-vendor keeps an SD-WAN that already works and limits dependence on one provider, at the cost of two policy models, two consoles, tunnels to maintain and split accountability in an outage. The cross-service policy coordination Mplify 117.1 assigns to a SASE provider falls to the buyer.
Vendors’ own descriptions as of October 2026, alphabetical, not ranked:
| Vendor | Security (SSE) | Networking | Vendor’s description |
|---|---|---|---|
| Cisco | Cisco Secure Access | Catalyst SD-WAN | Together “the foundation” of Cisco’s SASE architecture |
| Cloudflare | Cloudflare One: Access, SWG, CASB, DLP | Cloudflare WAN over IPsec, GRE or direct interconnect | Cloudflare’s SASE platform |
| Fortinet | FortiSASE: SWG, ZTNA, CASB, FWaaS | Fortinet Secure SD-WAN | Unified SASE, a single-vendor approach |
| Microsoft | Entra Internet Access and Entra Private Access | Branch equipment over IPsec | “Microsoft’s Security Service Edge (SSE) solution” |
| Netskope | Netskope One SSE | Netskope One SD-WAN | “single-vendor SASE solution” |
| Palo Alto Networks | Prisma Access | Prisma SD-WAN | Prisma SASE; SD-WAN sites onboard natively |
| Zscaler | Zero Trust Exchange | Zero Trust SD-WAN via a Zscaler Edge appliance | Branch traffic forwarded to the Zero Trust Exchange |
For two of these head to head, see Zscaler vs Palo Alto SASE in 2026; the same consolidation tradeoff appears in the Google and Wiz CNAPP analysis.
Migrating from VPN and on-premises proxies
NIST SP 800-207 says no significant enterprise is likely to migrate “in a single technology refresh cycle,” and migration may go one business process at a time. It starts with a survey of assets, subjects, data flows and workflows, since a policy engine with incomplete knowledge will most often deny requests. The CISA maturity model (v2.0, April 2023, a page cisa.gov now labels “Archived Content”) describes the direction: its Traditional network stage relies on macro-segments and “bulk traffic VPN tunnels”; Optimal means distributed micro-perimeters with just-in-time, just-enough connectivity.
- Inventory applications, users, devices and traffic flows, including shadow IT.
- Connect identity, device management and logging first; NIST says these must work in both architectures during the hybrid period.
- Move internet and SaaS traffic from on-premises proxies to the cloud SWG and CASB, documenting existing categories and exceptions first.
- Move private applications from VPN to ZTNA one at a time, keeping VPN for named exceptions.
- Connect branches through existing SD-WAN tunnels, or adopt SASE networking as WAN contracts renew.
The VPN to ZTNA migration playbook covers parallel running and decommissioning.
Evaluation questions
MEF 117 treats a SASE service as attributes agreed between subscriber and provider, so get these answers in the contract.
- Points of presence and data residency. Which PoPs inspect your traffic, which does the provider own, and where are logs stored? NIST notes some SASE offerings use major cloud vendors’ PoPs. Fortinet, for example, offers a version customers run in their own data centers for residency and sovereignty rules.
- Encrypted traffic and privacy. MEF 117 notes many security functions work only on unencrypted sessions, so traffic is decrypted and re-encrypted; Mplify 169 adds bypass. Ask how bypass is set for privacy-sensitive categories and who can see decrypted content. CISA warns that inspection products which fail to validate certificate chains weaken TLS.
- Identity provider integration. NIST expects identity, credential and access management plus MFA. Confirm support for your identity provider, how groups are provisioned, and whether device posture feeds access decisions.
- Policy model. One rule base across SWG, CASB, ZTNA, FWaaS and SD-WAN, or several? Ask about policy export and APIs, since NIST names rule translation as a switching cost.
- Logging and SIEM export. NIST’s seventh tenet calls for collecting as much information as possible about assets, traffic and access requests; CISA’s model moves from manual, low-fidelity logs to centralized, correlated analysis. Ask which logs export, in what format, how fast and at what cost. For detection, see MDR vs EDR.
- SLAs. Given NIST’s warning about cloud policy engine outages, contract for availability, support response and service credits, and confirm whether traffic fails open or closed.
How to decide
- Remote workforce, few branches, SaaS-heavy: start with SSE and keep the current WAN.
- A working SD-WAN with years left: pair it with SSE, and test tunnel failover and log correlation in the proof of concept.
- MPLS renewals and branch refresh due: evaluate full SASE, comparing single-vendor and dual-vendor quotes over the full term.
- Strict residency or privacy rules: screen PoP locations, log storage and decryption controls first; they can rule out options before any feature comparison.
Frequently asked questions
Is SSE part of SASE?
Yes. SSE is the security subset of SASE: SWG, CASB and ZTNA, often with FWaaS and DLP. SASE adds networking, chiefly SD-WAN, and Mplify 169 defines an interface for connecting an SSE to other SASE functions such as SD-WAN.
What is SSE (security service edge)?
In the Gartner definition Mplify quotes, SSE secures access to the web, cloud services and private applications through access control, threat protection, data security, monitoring and acceptable-use control. It is mostly cloud-delivered, sometimes with on-premises or agent components.
What are the components of SASE?
NIST SP 800-215 lists firewall, SWG, anti-malware, intrusion prevention, CASB and DLP as the minimum security services in most commercial SASE offerings, with SD-WAN and globally distributed PoPs for networking. ZTNA covers private applications.
What is the difference between SSE and SD-WAN?
SSE is cloud-delivered security for access to the web, SaaS and private apps. SD-WAN routes traffic between sites over multiple links under central policy. Together they make up SASE.
What is single-vendor SASE?
SD-WAN and SSE from one provider, managed together; Fortinet and Netskope both use the term. Dual-vendor SASE pairs one company’s SD-WAN with another’s SSE, trading simpler operations for flexibility.
Sources
- NIST SP 800-207
- NIST SP 800-215
- CISA Zero Trust Maturity Model
- CISA: HTTPS interception alert
- MEF 117
- Mplify 117.1
- Mplify 169 SSE Framework
- MEF 162 SSE certification
- Microsoft: Global Secure Access
- Microsoft: Remote networks
- Cisco: SD-WAN with Secure Access
- Cisco: Catalyst SD-WAN security
- Cloudflare One
- Fortinet SASE
- Netskope One SASE
- Palo Alto: Prisma SASE
- Palo Alto: Prisma SD-WAN onboarding
- Zscaler: Zero Trust SD-WAN
Last checked: October 2026. Guidance and product features change; check each source before you rely on it.
Buying? Start from RFPhub’s free SASE RFP template.