What SASE actually is
SASE is the convergence of five network and security capabilities into a cloud-delivered model: SD-WAN (network routing), secure web gateway (SWG), cloud access security broker (CASB), zero-trust network access (ZTNA), and firewall-as-a-service (FWaaS). The architectural claim is that these functions, delivered from common cloud edge locations and unified by policy, produce better security and better performance than the legacy stack of separate hardware appliances at each office.
The claim is mostly true. The delivery is mostly complicated. Most vendors strong in one or two of the five capabilities are weaker in the others, regardless of what the datasheet says. The acquired-to-fill-the-gap architecture that many "single-vendor SASE" platforms are actually built on creates seams that manifest as policy-sync issues, inconsistent logging, and uneven user experience.
When you genuinely need SASE
Not every organization needs SASE in 2026. The signals that you genuinely do:
- Distributed workforce, meaningful percentage of users work outside offices most weeks. Legacy VPN architectures degrade at scale and don't offer application-layer policy.
- Multi-office with WAN overhead, MPLS contracts expiring, branch connectivity costs climbing, SD-WAN ROI obvious.
- SaaS-heavy stack, majority of critical applications are SaaS, making office-centric security architecture increasingly misplaced.
- Compliance or regulatory driver, industries with data residency, audit, or zero-trust mandates.
Signals that SASE isn't yet a priority:
- Small single-office workforce operating on a handful of SaaS apps.
- Legacy network contracts with years to run where SD-WAN economics don't yet pencil.
- Organizations still without MFA, EDR, or email security, foundational gaps dominate over architectural ones.
The five capabilities, in plain English
Most 2026 deployments prioritize SD-WAN and ZTNA first, SWG and CASB second, FWaaS last. The sequence matches ROI and risk reduction curves we've measured across engagements.
Single-vendor vs. multi-vendor
Every major platform will tell you they offer complete single-vendor SASE. Palo Alto, Zscaler, Cisco, Netskope, Cato, Fortinet, all have the marketing. The reality across 2025 deployments:
- Very few vendors are strong in all five capabilities. Most are acquired-to-coverage. Policy and telemetry unification lags product-level acquisition by 18-36 months.
- Single-vendor is cleaner on paper: unified policy, unified logging, unified console, single support relationship.
- Multi-vendor is the actual common deployment. Best-of-breed SD-WAN + specialist ZTNA + specialist SWG/CASB is frequent.
The right answer depends on your starting point. If you're greenfield, single-vendor can work, accept the weaker capabilities in exchange for integration simplicity. If you have existing best-of-breed investments (particularly in SD-WAN), forcing them out to achieve "single vendor" is usually the wrong move.
Deployment sequencing
A typical 18-24 month SASE program for a 500-2,500 user mid-market client:
Evaluation criteria that matter
When our team runs SASE evaluations, these dimensions separate the real contenders from the demo-ware:
- Edge presence where your users and applications actually are (POP count is a vanity metric).
- Operational maturity, production deployments at your scale, 3+ customer references in your industry.
- Integration with your existing identity, federates cleanly to your IdP, respects your RBAC, exports to your SIEM.
- Policy unification, can you write a policy once and have it apply consistently across the five capabilities.
- Commercial model, per-user, per-bandwidth, per-capability, or bundled; 3-year TCO with realistic assumptions.
