The Question
The term SASE describes a complete architecture: Security Service Edge capabilities (SWG, CASB, ZTNA, FWaaS, UEBA) converged with Software-Defined WAN into a single cloud-delivered platform. In practice, very few enterprises buy SASE as a complete stack on day one. Most start with SSE — the security components — while deferring the SD-WAN layer, often because they have existing WAN infrastructure under active contracts or mid-cycle hardware investments.
This SSE-first pattern is so common that it's effectively the default enterprise SASE adoption path. Gartner's 2025 SSE Magic Quadrant noted that the majority of enterprise SASE deployments were SSE-first, with SD-WAN integration planned but deferred. The question is not whether SSE-only is a valid deployment model — it clearly is, for a large proportion of enterprises. The question is whether your specific environment has characteristics that make the absence of SD-WAN a meaningful gap rather than a deferred roadmap item.
The answer depends almost entirely on your branch traffic profile. And most enterprises don't analyze that profile carefully enough before making the SSE-only decision.
SSE-only is not incomplete SASE — for many enterprises it is the right architecture. The question is whether your branch traffic profile creates a gap that SSE alone cannot see.
Why This Matters Now
In early 2025, a mid-size retail chain with 340 locations deployed Zscaler Internet Access and Zscaler Private Access as its SSE layer, deferring SD-WAN in favor of existing Cisco Meraki deployments at branches. The deployment was successful for its stated purpose: remote worker security, cloud application access, and ZTNA replacement of legacy VPN.
Six months into production, the security operations team identified a blind spot. Branch-to-branch traffic — inventory synchronization, point-of-sale transaction batching, and back-office application replication between store locations — was not transiting the Zscaler SSE layer at all. It was moving directly over the Meraki SD-WAN mesh, invisible to the security inspection policy. When a ransomware payload entered via a compromised POS terminal at a single location, it moved laterally across the branch-to-branch SD-WAN fabric for four hours before the SSE layer detected it via an outbound C2 connection.
The incident was contained, but it was instructive. SSE sees user-to-cloud traffic and internet-bound traffic. It does not see site-to-site traffic unless that traffic is explicitly routed through the SSE inspection layer — and in most SD-WAN deployments, it isn't. For retail chains, manufacturing networks, distributed services businesses, and any organization with significant branch-to-branch data flows, this is not a theoretical gap. It is a real blind spot with real incident implications.
The lesson isn't that SSE-only is wrong. It's that the decision to deploy SSE without SD-WAN should be made with explicit awareness of what traffic the SSE layer will and will not see.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated the traffic coverage profile of SSE-only deployments across five major verticals: financial services, healthcare, retail, manufacturing, and professional services.
The analysis found that SSE-only provides adequate security coverage for organizations where user-to-cloud and user-to-internet traffic represents more than 80% of total security-relevant traffic flows. This profile is characteristic of knowledge-worker-dominated organizations: professional services firms, SaaS-heavy technology companies, and cloud-native financial services organizations.
The analysis found meaningful coverage gaps in organizations where branch-to-branch or site-to-data-center traffic represents more than 25% of total traffic. This profile is characteristic of retail (inter-store and store-to-DC traffic), manufacturing (OT network connectivity, plant-to-plant replication), and healthcare (EMR synchronization across hospital networks).
Zscaler's published integration guides for Cisco Meraki, Fortinet FortiGate, Aruba EdgeConnect, and VMware/Broadcom SD-WAN provide specific configuration patterns for routing site-to-site traffic through the ZIA inspection layer — but these configurations require deliberate design decisions and are not enabled by default. Palo Alto Prisma SASE, with native CloudGenix SD-WAN integration, handles this routing automatically within the unified platform.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
The SSE vs. full SASE decision is often framed as a budget and timeline question: SSE now, SD-WAN later when the contract renews. This framing is operationally convenient but analytically incomplete. The real question is architectural: what traffic flows are outside the SSE inspection perimeter, and does that matter for your threat model?
The case where SSE-only is the right call
SSE-only is architecturally complete for organizations whose security-relevant traffic is predominantly user-to-cloud and user-to-internet. A professional services firm with 500 knowledge workers using Microsoft 365, Salesforce, and a handful of SaaS tools, connecting to two or three data center applications via ZTNA — this organization captures 95% of its security value from SSE alone. The SD-WAN layer adds routing optimization and WAN cost reduction, but the security inspection coverage from SSE is nearly complete.
Remote-work-first organizations have an even stronger SSE-only case. When the majority of users connect from home or coffee shops to cloud applications, there is almost no traffic pattern that requires SD-WAN for security inspection coverage. SSE sees everything that matters.
Organizations mid-MPLS-contract are also rational SSE-first adopters. The economic case for disrupting a multi-year MPLS contract to add SD-WAN before contract expiry rarely works. SSE delivers immediate ROI on cloud security and remote access, and the SD-WAN layer can be added at WAN contract renewal without security coverage compromise in the meantime.
The case where the gap is real
Multiple physical branch offices with direct internet breakout and significant inter-branch traffic flows represent the clearest case where SSE-only leaves a meaningful coverage gap. Retail chains, bank branch networks, restaurant chains with standardized point-of-sale infrastructure, and manufacturing networks with plant-to-plant replication are all examples where site-to-site traffic is security-relevant and outside the default SSE inspection perimeter.
Manufacturing and OT environments have an additional dimension: OT network connectivity often uses protocols and traffic patterns that are not visible to SSE-layer inspection without specific OT security tooling. Full SASE with SD-WAN provides a network-layer visibility plane that SSE alone cannot replicate.
Healthcare networks with EMR synchronization across hospital campuses and clinic networks face a similar profile: significant site-to-site traffic carrying PHI that represents both a compliance coverage gap and a lateral movement exposure if not inspected.
The integration path: making existing SD-WAN work with SSE
For organizations deploying SSE while retaining existing SD-WAN, the integration question is whether the SD-WAN platform can route site-to-site traffic through the SSE inspection layer. Zscaler publishes detailed integration guides for Cisco Meraki (using service insertion), Fortinet FortiGate (using IPsec tunnels to Zscaler), Aruba EdgeConnect, and Silver Peak. These integrations work, but they require deliberate design and configuration — they are not automatic.
Palo Alto Prisma SASE handles this natively if you're running Prisma SD-WAN (formerly CloudGenix). Cato Networks handles it natively within its single-platform architecture. For organizations running Cisco Meraki or Fortinet SD-WAN with a non-native SSE vendor, the integration requires effort and ongoing operational attention to maintain.
Questions Your Buying Team Should Be Asking
1. What percentage of our total security-relevant traffic is site-to-site or branch-to-data-center, versus user-to-cloud and user-to-internet — and have we profiled this from actual traffic analysis rather than assumption?
The answer to this question should drive the SSE-vs-full-SASE decision. Most organizations have an intuitive sense of their traffic profile but haven't produced the actual analysis. A two-week NetFlow collection exercise before the procurement decision is worth the effort.
2. If we deploy SSE without SD-WAN integration, which specific traffic flows will be outside our security inspection perimeter — and do those flows carry data or access patterns that are relevant to our threat model?
This question forces explicit mapping of the coverage gap rather than allowing it to remain a vague "future roadmap item." For retail and manufacturing organizations, the answer is almost always that the gap matters. For professional services organizations, the answer is usually that it doesn't.
3. Does our existing SD-WAN platform have a documented integration path with our chosen SSE vendor — and what specifically is and isn't covered in that integration?
Vendor integration guides describe happy-path configurations. Ask for specific documentation of what traffic types are and aren't routed through the SSE inspection layer in the integration configuration. Ask a reference customer running the same SD-WAN/SSE combination to describe what they explicitly had to configure to close coverage gaps.
4. If we start with SSE and add SD-WAN at our next WAN contract renewal, will our SSE vendor's SD-WAN offer be technically and commercially competitive at that point — or are we creating pressure to add SD-WAN from the SSE vendor even if it isn't the right choice?
The SSE-first path creates commercial pressure to add SD-WAN from the same vendor at renewal — the consolidation discount makes it economically attractive even if a different SD-WAN vendor would be a better architectural fit. Identify this pressure point before it arrives and evaluate SD-WAN options independently.
5. For our OT/manufacturing environments or healthcare networks, does SSE-only provide adequate visibility into the protocols and traffic patterns those environments use — or do we need network-layer visibility that only SD-WAN integration can provide?
OT protocols (Modbus, DNP3, BACnet, EtherNet/IP) and healthcare network traffic patterns are often outside the scope of SSE-layer inspection. Organizations with significant OT or healthcare infrastructure should evaluate whether SSE-only creates a meaningful clinical or operational technology security blind spot.
The Stackcurve Take
The SSE-first SASE adoption path is the right choice for most enterprises in most situations. It delivers immediate, measurable security improvement — replacing legacy VPN with ZTNA, adding inline CASB for cloud application visibility, and providing SWG protection for internet-bound traffic — without requiring WAN disruption or hardware refresh.
The mistake is treating "SSE first" as equivalent to "SSE is all we need." For organizations with distributed branch networks, significant site-to-site traffic, or OT environments, the traffic that SSE doesn't see by default may be exactly the traffic where a sophisticated attacker will move.
The discipline required is a traffic profile analysis before the procurement decision — not after deployment. Understand what SSE will see, understand what it won't see, and make a deliberate architectural decision about whether the gap requires SD-WAN integration or whether the SSE-only coverage is adequate for your specific environment and threat model.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers SSE deployment patterns, SD-WAN integration frameworks, and traffic coverage analysis methodology for all major enterprise deployment profiles. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.