What SASE actually is, what it converges, and why the SSE distinction now drives most procurement decisions

Secure Access Service Edge (SASE, pronounced "sassy") is a cloud-delivered model that converges wide-area networking and network security into a single service, applied at the network edge based on the identity of the user or device, real-time context, and policy. Gartner introduced the term in its 2019 report "The Future of Network Security Is in the Cloud." The core idea reverses the legacy model: instead of backhauling traffic to a security stack sitting in a data center, security and networking move to the cloud edge closest to the user, and policy follows the identity rather than the location.

The word "converged" carries most of the weight. A bundle of separate networking and security products sold together is not SASE. SASE describes a unified service where networking and security functions are delivered from the same cloud fabric, managed from one control plane, and applied as traffic passes through a single inspection point. That single-pass, single-policy characteristic distinguishes a true SASE architecture from a collection of point tools wired together.

Almost every networking and security vendor now markets a "SASE" or "SASE-ready" offering. Because the term is applied loosely, two products both called SASE can differ enormously in what they actually converge and how. Buying against the label rather than the architecture is how organizations end up with a re-bundled point-product stack that carries SASE pricing without SASE operational benefits.

The model SASE replaces is the hub-and-spoke network paired with VPN remote access. In that design, branch offices and remote users route their traffic back to a central data center, where a stack of security appliances inspects it before sending it on to the internet or cloud applications. This made sense when most applications lived in that data center. It makes far less sense when most traffic is headed to SaaS and cloud platforms, because backhauling adds latency, concentrates load on appliances and VPN concentrators, and ties security policy to network topology.

SASE inverts this. Traffic from any edge - a branch, a remote laptop, a cloud workload - connects to the nearest point of presence in the provider's cloud, where networking and security policy are applied together, and is then sent directly to its destination. Policy is bound to identity and context, not to where the connection physically originates. The practical effects are lower latency for cloud-bound traffic, consistent policy enforcement regardless of user location, and the retirement of the appliance-and-VPN sprawl that hub-and-spoke designs accumulate.

Gartner's definition identifies five core capabilities that converge in a SASE platform. The first is the networking pillar; the remaining four are the security pillar.

Software-Defined WAN is the networking foundation. It steers traffic intelligently across multiple transport types (broadband, MPLS, LTE/5G) based on application needs and link conditions, replacing rigid router-and-circuit configurations with policy-driven, application-aware routing.

A Secure Web Gateway inspects outbound web traffic, enforces acceptable-use and URL-filtering policy, and blocks malicious sites and content. It is the control point for users accessing the internet directly from the edge rather than through a backhauled data center proxy.

A Cloud Access Security Broker sits between users and SaaS applications, giving visibility and control over sanctioned and unsanctioned cloud usage. It enforces data-protection and access policy for services like Microsoft 365, Salesforce, and Google Workspace, including data loss prevention.

Zero Trust Network Access replaces the implicit trust of a VPN. Rather than placing a user on the network, ZTNA grants access to specific applications only after verifying identity and context, and never exposes the broader network. It is the modern replacement for remote-access VPN.

Firewall as a Service delivers firewall capability (including next-generation features like intrusion prevention and application control) from the cloud rather than from a physical appliance at each site. It applies consistent firewall policy to all edges from a single cloud-managed control plane.

This is the distinction that most directly shapes a buying decision, and it is the one buyers most often get wrong.

As organizations began adopting SASE, it became clear that not everyone needed or wanted to converge networking at the same time as security. Many had recently invested in SD-WAN, or wanted to keep networking and security procurement separate, or simply needed to modernize the security stack first. In 2021, two years after the original SASE definition, Gartner introduced Security Service Edge (SSE) in its "Strategic Roadmap for SASE Convergence" to name this narrower scope.

SSE is the security half of SASE. It converges the security components - SWG, CASB, ZTNA, and FWaaS - into a single cloud-delivered service, without the SD-WAN networking component. Put simply: SSE is SASE without the SD-WAN. It secures access to the internet, SaaS, and private applications, but it does not own the WAN transport or traffic-steering layer.

The choice between shopping for SSE and shopping for full SASE is really a question of scope and sequencing:

If your networking is already handled and stable - for example, you have a recent SD-WAN deployment you are happy with - an SSE platform lets you modernize security without disrupting the network layer. You converge the security stack now and leave networking where it is.

If you are facing both a network refresh and a security modernization at the same time, full SASE lets you converge both into one platform and one operating model rather than running two procurements and two control planes.

The organizational reality often decides it: when networking and security teams are ready to move together, SASE is the logical target. When the security team wants to modernize but networking is committed to its existing SD-WAN or carrier setup, SSE is the pragmatic path, with the option to converge networking later.

Getting this wrong wastes money in both directions. Buying full SASE when you only needed SSE means paying to re-platform networking you did not need to touch. Buying SSE when you actually needed converged networking means a second procurement and integration project you could have avoided.

A second architectural fork sits inside "full SASE": whether all five components come from one vendor or from two.

Single-vendor SASE delivers all networking and security capabilities from one provider, through one cloud fabric, one management console, and ideally a single-pass inspection of traffic. Gartner specifically defines single-vendor SASE as the converged delivery of SD-WAN, SWG, CASB, FWaaS, and ZTNA by one vendor across all edges. The advantages are operational: one policy model, one place to troubleshoot, fewer integration seams, and typically better performance because traffic is inspected once rather than chained through multiple services.

Dual-vendor (or multi-vendor) SASE pairs a networking provider with a separate security provider, integrating them through APIs and service chaining. Gartner sometimes refers to these as "SASE alternatives" because they can check the same capability boxes without achieving the same depth of convergence. The advantages are flexibility and best-of-breed selection: you can pair the SD-WAN you already trust with the SSE platform that best fits your security requirements, and you avoid locking the entire stack to one roadmap.

The trade-off is real and worth stating plainly. Single-vendor SASE optimizes for operational simplicity and performance at the cost of flexibility and some lock-in. Dual-vendor SASE optimizes for flexibility and component-level fit at the cost of more integration work, two management planes, and the service-chaining overhead of passing traffic between separately operated services. Neither is universally correct. The right answer depends on the state of your existing investments, the maturity of your teams, and how much you value a single throat to choke versus best-of-breed control.

Once the terms are clear, a few questions move you from definition to decision.

Determine whether you need to converge networking and security together, or only the security stack. If your SD-WAN is recent and stable, SSE is likely your scope. If a network refresh and security modernization coincide, full SASE is on the table.

Weigh operational simplicity and single-pass performance against best-of-breed flexibility. Factor in how much SD-WAN and security investment you already have and whether your teams are ready to converge.

For any platform marketed as SASE, ask how the components are actually integrated. Is traffic inspected in a single pass under one policy model, or are point products service-chained behind one bill? The answer separates real convergence from a re-bundled stack.

The right SASE approach depends on your current investments, team readiness, and procurement constraints. Here are the three primary models and where each fits best.

Converges SWG, CASB, ZTNA, and FWaaS without touching networking. Modernize the security stack while leaving SD-WAN in place.

Best fit: Organizations with a recent or stable SD-WAN deployment, or those keeping networking and security procurement separate.

Tradeoffs: Networking remains a separate platform and operating model; converging it later is a second project.

All five components from one provider, one console, single-pass inspection. Maximum operational simplicity.

Best fit: Organizations facing simultaneous network and security modernization whose teams are ready to converge.

Tradeoffs: Less component-level flexibility and more dependence on one vendor's roadmap.

Best-of-breed SD-WAN paired with a separate SSE platform, integrated via API and service chaining.

Best fit: Organizations with strong existing investments on one side and specific best-of-breed requirements on the other.

Tradeoffs: Two management planes, more integration work, and service-chaining overhead between separately operated services.