The Question
Every enterprise CISO has a version of this conversation: the network team confirms that the SD-WAN deployment is complete, branch offices are connected, and traffic is flowing. The security team then asks a different question — which traffic are you seeing?
For most distributed enterprises, the honest answer is: the traffic that comes back to headquarters. The hub-and-spoke architecture that defined WAN design for two decades was built around a logical assumption — that corporate data lived in corporate data centers, and branch users needed to reach it. The security stack sat at headquarters, where the data was. Every packet transited HQ on its way in or out of the enterprise.
That assumption no longer holds. In 2026, the majority of branch office traffic is destined for Microsoft 365, Salesforce, Zoom, ServiceNow, or a dozen other SaaS platforms that are not hosted in the corporate data center. Branch users are making thousands of direct-to-cloud connections every hour — connections that, in a traditional architecture, never touch the central security stack.
The gap is not theoretical. It is architectural. And for many enterprises, it means that security operations teams are watching a fraction of the traffic that actually represents their exposure.
Your branch offices are making thousands of direct-to-cloud connections that your security team cannot see — and the security architecture that would fix this requires changing more than your security stack.
Why This Matters Now
The architecture mismatch became undeniable in 2024 as Microsoft 365 adoption crossed 80% penetration in the enterprise market and organizations began seriously measuring the latency impact of backhauling cloud-bound traffic through headquarters. The numbers were not subtle: a branch office in Denver routing M365 traffic through a Chicago data center before reaching Microsoft's nearest Azure front-door point was adding 60–120ms of unnecessary round-trip latency to every email send, every SharePoint load, every Teams call setup.
The network operations response was predictable: enable local internet breakout at branch locations. Let branch traffic go directly to the internet rather than hairpinning through HQ. Latency dropped immediately. User experience improved. Network operations declared success.
Security operations saw a different picture. The same branches that now had fast access to M365 also had fast, uninspected access to everything else on the internet. The security controls that had protected branch users — the web proxy, the IDS sensors, the DLP policies, the TLS inspection engine — were all sitting in the Chicago data center watching traffic that no longer passed through it.
A 2025 Gartner survey of enterprises with more than 5,000 employees found that 67% had enabled local internet breakout at some branch locations, but only 31% had deployed cloud-delivered security controls to compensate for the lost visibility. The remaining 36% had created security blind spots they frequently could not fully characterize.
The problem was compounded by WAN contract structures. MPLS circuits typically run on 3–5 year terms. Many enterprises that recognized the architecture problem in 2024 and 2025 were locked into MPLS contracts that made immediate transition impractical. They were left in an uncomfortable middle state: partial cloud breakout, partial backhauling, and security visibility that matched neither architecture cleanly.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated vendors across the branch security use case specifically, examining how well each platform supports distributed enterprises transitioning from hub-and-spoke to cloud-delivered security architectures.
The Challengers category includes vendors with strong branch-specific capabilities: Cato Networks earned high marks for its single-vendor SASE approach that unifies SD-WAN and cloud security under a single policy engine — a meaningful advantage for enterprises that want to eliminate the visibility gap without managing separate SD-WAN and SSE vendor relationships. Versa Networks placed competitively on the strength of its on-premises SD-WAN integration with cloud security overlay.
The Leaders — Zscaler and Netskope — scored well on cloud security depth but require integration work with third-party SD-WAN solutions (Cisco Meraki, Fortinet, VMware SD-WAN) for the WAN layer, which adds architectural complexity that some enterprises underestimate during procurement.
Palo Alto Networks' Prisma SASE received strong marks for enterprises already standardized on the Palo Alto platform, where integration overhead is lower.
The key differentiator across all vendors in this use case is whether they support agentless branch coverage — protecting traffic from unmanaged devices, IoT endpoints, and guest networks that cannot run an endpoint agent.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
The most common failure mode in branch SASE deployments is not vendor selection — it is the assumption that buying cloud-delivered security automatically fixes the visibility problem. It does not, unless the traffic routing is also changed. These are the specific gaps that matter.
1. The SD-WAN and SSE ownership split
In most enterprises, SD-WAN is owned by network operations and SSE is owned by security operations. These teams have different procurement cycles, different budget owners, and sometimes different vendor relationships. The result is a branch security architecture that is assembled from two half-solutions rather than designed as a unified system. Security policy cannot follow the traffic if security operations doesn't control how the traffic is routed.
2. Partial breakout configurations that create unpredictable coverage
Enterprises frequently configure local internet breakout for specific application categories (Microsoft 365, Zoom, Google Workspace) while continuing to backhaul everything else. The intent is to preserve security coverage for general internet traffic while improving latency for known-good SaaS apps. The execution often introduces inconsistent security policy application — the classification of traffic into "breakout" and "backhaul" categories drifts over time as applications are added and removed from the approved list.
3. Legacy MPLS contracts as a change management obstacle
A three-year MPLS contract does not prevent SASE adoption, but it does change the economics. Enterprises in mid-contract frequently deploy cloud security as an overlay without retiring the MPLS circuits, paying for both architectures simultaneously. The business case for SASE in this scenario is harder to make, and the organizational pressure to simplify often evaporates once the security visibility problem is nominally "solved" by the overlay deployment.
4. Branch IoT and OT as persistent blind spots
Even enterprises that deploy SASE comprehensively for managed endpoints often leave operational technology, IoT devices, and shared-use hardware (conference room systems, printers, building management systems) outside the security perimeter. These devices connect to the internet directly over the branch network and are invisible to agent-based SSE architectures. Agentless branch coverage via GRE or IPSec tunnel to the SSE provider is the architectural solution, but it is frequently skipped in initial deployments.
The practical implication: buying SASE without auditing the branch traffic routing architecture first produces a security platform that protects the traffic it can see while leaving the visibility gap structurally intact.
Questions Your Buying Team Should Be Asking
1. What percentage of our branch traffic currently bypasses our central security stack?
This is the baseline question and most enterprises cannot answer it precisely before the audit. Require your network operations team to instrument actual branch traffic flows — not theoretical routing policy — before any procurement decision. The gap between policy intent and actual traffic routing is often significant.
2. Does your platform support agentless branch coverage for unmanaged devices and IoT endpoints?
Agent-based SSE protects managed laptops. It does not protect the conference room Zoom system, the IoT environmental sensors, the guest WiFi network, or the manufacturing floor OT devices that share a branch network segment. Verify that the vendor supports GRE or IPSec tunnel-based coverage for agentless traffic and that this coverage includes full policy enforcement, not just logging.
3. How does your SD-WAN integration work, and who owns the integration relationship?
If the vendor is a pure SSE provider (Zscaler, Netskope), ask specifically how traffic is steered from branch locations to their cloud. What SD-WAN platforms are supported? Is the integration native or requires a third-party connector? Who manages the steering policy when routing changes are needed? The answer tells you whether you are buying a unified architecture or an integration project.
4. What happens to branch security coverage during a cloud platform outage?
Cloud-delivered security is only as reliable as the cloud platform's uptime and the branch's internet connectivity. Understand the failover behavior: does traffic drop if the SSE platform is unreachable? Does it fail open (traffic continues uninspected)? What is the vendor's published availability SLA, and how does it compare to the security risk of the failopen scenario?
5. How do you handle enterprises with active MPLS contracts in a hybrid architecture?
Ask the vendor to show you reference deployments of enterprises running hybrid MPLS/SD-WAN architectures during a multi-year transition. Understand the security policy model during the transition period — specifically, how security policy consistency is maintained across traffic that takes different paths to the internet.
The Stackcurve Take
Branch office security is the use case where SASE's architectural logic is most clearly validated — and where the gap between purchasing intent and deployment reality is widest. The problem is real: hub-and-spoke security architectures protecting hub-and-spoke traffic flows while branch-to-cloud traffic flows uninspected is not a theoretical risk. It is the current state for a large fraction of distributed enterprises.
The solution is also real, and the vendor market has matured enough that capable platforms exist across multiple price points and architectural preferences. The deployment challenge is organizational and contractual, not technical.
The enterprises that close the visibility gap successfully treat it as a joint network and security initiative — not a security tool purchase that network operations is expected to route traffic through. Unified ownership of the SD-WAN and SSE decision, even when the vendors are different, is the single most reliable predictor of successful branch SASE deployment.
Enterprises that buy the SSE platform first and sort out the traffic routing later are buying a security capability they cannot yet use — and often pay for that mistake twice when the routing re-architecture project arrives.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers branch security architectures and single-vendor versus best-of-breed SASE approaches in detail. 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.