The Question
Gartner's 2024 Magic Quadrant for Single-Vendor SASE included nine vendors in the evaluated set. All nine claim to offer a unified platform that converges SD-WAN and SSE into a single architecture. All nine have a shared management console, a single contract, and a unified support relationship. The enterprise buyer reading that report could be forgiven for concluding that single-vendor SASE is now a commodity — that the integration problem has been solved and the remaining decision is one of feature depth and price.
That conclusion would be wrong in the majority of cases. The management console unification happened. The underlying architectural integration — shared policy engine, shared data plane, shared threat intelligence fabric — has not happened for most of the evaluated set. What most vendors are selling as single-vendor SASE is a shared login on top of two separately engineered products that communicate through APIs rather than native integration.
The distinction matters because the architectural benefits of SASE — unified policy enforcement, correlated threat detection across WAN and security layers, a single event log for forensics — only materialize when the integration is real. A shared console with API-connected back-ends delivers operational convenience, not architectural integration. Buyers who don't test for the difference before signing a multi-year contract discover it during incident response.
Single-vendor SASE is a legitimate architectural advantage — but only when the integration is real, not cosmetic.
Why This Matters Now
In 2022, Palo Alto Networks completed its integration of CloudGenix — the SD-WAN vendor it acquired in 2020 — into the Prisma SASE platform. The combined product, marketed as Prisma SD-WAN and Prisma Access, gave Palo Alto a credible claim to single-vendor SASE. It also provided an instructive case study in what acquisition-based integration actually looks like in production.
Enterprise customers who deployed Prisma SASE in 2022–2023 reported in subsequent Gartner Peer Insights reviews a consistent pattern: the SD-WAN and SSE components shared a management console (Strata Cloud Manager) but retained separate policy engines. A security policy created in Prisma Access did not automatically propagate to SD-WAN traffic routing decisions. Threat intelligence detected at the SSE layer was not automatically consumed by the SD-WAN policy engine to reroute suspicious traffic. DLP policies configured in the CASB layer did not share rule sets with the SD-WAN application identification engine.
Palo Alto has made meaningful integration progress since those early deployments, and the platform scores significantly better on integration depth metrics in current evaluations than it did in 2022. But the trajectory illustrates the general principle: acquisition-based SASE integration is a multi-year engineering project, not a press release. The vendor announcement of a completed acquisition is not evidence of architectural integration. The vendor announcement of a unified management console is not evidence of a shared policy engine.
For enterprise buyers evaluating SASE platforms in 2026, the question is not whether a vendor claims single-vendor SASE. It is whether the specific integration capabilities that deliver SASE's architectural value are present, testable, and documented — and whether the platform was built with those integrations natively or is still completing them.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report applies a dedicated Integration Architecture Score to all full-stack SASE platforms in the evaluated set. This score measures three specific integration dimensions that distinguish real architectural convergence from console unification:
Policy plane integration: Does a single policy govern both SSE inspection and SD-WAN routing decisions? Can a security event detected by the SSE layer automatically trigger a SD-WAN path change without manual configuration?
Data plane integration: Does traffic pass through a single inspection engine, or through separate SSE and SD-WAN engines that share telemetry via API?
Threat intelligence integration: Is the threat intelligence fabric shared between the SSE and SD-WAN layers, so that an indicator of compromise detected on one layer is immediately available to the policy engine of the other?
In the 2026 dataset, Cato Networks scores highest on all three Integration Architecture dimensions. As a cloud-native platform built on a single software stack from inception — not assembled through acquisition — Cato's SD-WAN and SSE functions share a native policy engine and a unified data plane. Threat intelligence detected by Cato's SSE layer is immediately available to SD-WAN policy without API intermediation. This is what genuine single-vendor SASE integration looks like architecturally.
Palo Alto Prisma SASE scores well on policy plane integration in current evaluations — reflecting meaningful post-2022 engineering investment — but shows measurable gaps on data plane unification for certain traffic classes. Cisco's SASE offering (combining Meraki SD-WAN, Cisco Umbrella, and Duo) shows the widest integration gaps in the evaluated set, with separate policy engines requiring explicit synchronization and no native shared threat intelligence fabric as of Q1 2026.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most SASE evaluations focus on feature checklists — SD-WAN capabilities on one side, SSE capabilities on the other — and select the vendor who scores highest across both lists. This approach systematically misses the integration question because integration is not a feature. It is an architectural property that only reveals itself when you test the system under real conditions.
There are three diagnostic tests that separate genuine single-vendor SASE from console unification, and almost no enterprise evaluation team runs them before signing a contract.
Test 1: The automatic policy propagation test. Configure a security policy in the SSE layer — for example, block access to a specific web category. Then check whether that policy is automatically reflected in the SD-WAN application routing policy without any additional configuration steps. In a genuinely integrated platform, a security policy has a single control plane that governs both layers. In a console-unified platform, you will need to separately configure an equivalent policy in the SD-WAN management interface. This test takes 15 minutes and definitively answers the policy plane integration question.
Test 2: The correlated event log test. Generate a test security event at the SSE layer — trigger a DLP policy, simulate a malicious URL access, generate a threat detection. Then check whether that event appears in the same event log, with the same event ID, as the corresponding SD-WAN traffic event for that session. In a genuinely integrated platform, a security event at the SSE layer is directly correlated with the WAN traffic record. In an API-integrated platform, the two events will appear in separate logs with separate identifiers that require manual correlation. This test takes 30 minutes and definitively answers the threat intelligence integration question.
Test 3: The DLP single-pass test. Submit a file containing test DLP trigger content through an application that traverses both the SD-WAN and SSE layers. Check whether the file is inspected once — at a single inspection point — or twice, generating two separate DLP events in two separate logs. Double inspection indicates separate data planes. Single inspection with a single event indicates a genuinely unified data plane. This matters operationally: double inspection increases latency, doubles storage requirements for DLP logs, and creates event correlation complexity that slows incident response.
Beyond the diagnostic tests, buyers routinely miss the organizational implications of the integration gap. A platform with separate policy engines for SD-WAN and SSE requires two separate policy management workflows, two separate change management processes, and skill sets that span both network engineering and security engineering disciplines. Organizations that expected operational consolidation as a benefit of single-vendor SASE and received console unification instead are often running more complex operations than they were with a best-of-breed multi-vendor architecture, because they have one vendor's contract and two vendors' operational complexity.
The acquisition timeline is also a signal that buyers should factor into long-term platform decisions. Vendors who completed major acquisitions within the last 24 months are still in the early stages of architectural integration. The management console unification typically completes within 12 months of acquisition. The policy plane integration takes 2–3 years. The data plane unification — true single-pass inspection — can take 3–5 years of engineering work on legacy-architecture platforms. A vendor's 2024 acquisition announcement is not evidence of 2026 architectural integration.
Questions Your Buying Team Should Be Asking
1. Is your SD-WAN and SSE policy engine the same software component, or do they communicate through an API? This is the most direct way to ask the policy plane integration question. Ask vendors to show you the architecture diagram for how an SSE security policy propagates to SD-WAN routing decisions. If the answer involves an API call between two systems, you are looking at console unification. If the answer involves a single policy engine with multiple enforcement points, you are looking at genuine architectural integration.
2. Can you show me a single event log that correlates an SSE security event with the corresponding SD-WAN traffic record without manual query construction? Run the correlated event log test during the proof-of-concept, not after contract signature. Ask the vendor's SE to generate a test security event and show you the correlated log entry without constructing a custom query. If the SE needs to run two separate queries and explain how the results relate to each other, you have your answer about integration depth.
3. Does DLP inspection happen once in your architecture, or does data pass through separate inspection engines for the SD-WAN and SSE layers? Single-pass inspection is one of the clearest architectural differentiators between native and acquired SASE platforms. Ask vendors to describe the inspection architecture specifically. "We use a cloud-native single-pass engine" and "our SD-WAN and security stacks share inspection resources" are different claims — ask which is accurate for your specific configuration.
4. When was the SD-WAN capability in your platform built, and was it built natively or acquired? Acquisition history is public information, but buyers rarely ask about it explicitly in vendor evaluations. Knowing when an acquisition occurred, and what the integration roadmap commitment was at the time, tells you where the vendor is on the 3–5 year integration timeline. A 2022 acquisition is likely still completing policy plane integration. A 2019 acquisition should have completed data plane integration by now — ask specifically whether it has.
5. What is on your integration roadmap for the next 18 months, and what capabilities are not yet delivered? Every vendor in this category has integration gaps they are working to close. Ask them to disclose the gaps explicitly and provide a committed timeline for closing them. Vendors who claim no integration gaps are either misrepresenting their architecture or have not been asked the right questions. Vendors who acknowledge gaps and provide clear timelines with contractual commitments are giving you material information you can use in contract negotiations and deployment planning.
The Stackcurve Take
The single-vendor SASE pitch is compelling for good reasons. Genuine architectural integration does deliver real operational benefits: a single policy that governs both network and security decisions, a single event log for forensics, a single support relationship, and reduced operational complexity compared to managing separate best-of-breed vendors. Those benefits are real when the integration is real.
The problem is that the market has allowed "single-vendor SASE" to become a label that covers a wide spectrum of integration maturity — from Cato's cloud-native architecture where the integration is complete and native, to platforms that share a UI while operating largely as separate products under the surface. Buyers who evaluate platforms on the label rather than the integration depth are frequently purchasing the branding without the substance.
The three diagnostic tests in this brief — policy propagation, correlated event log, and single-pass DLP — can be run in a half-day proof-of-concept session. They are the most reliable way to distinguish genuine architectural integration from acquisition-era console unification. Any vendor unwilling to run these tests during the evaluation process is providing material information about their confidence in the results.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers single-vendor SASE platforms with dedicated Integration Architecture scoring across all evaluated vendors. 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.