Why SASE Projects Fail
Most SASE failures are organizational, not technical. Here are the patterns that kill SASE projects and how to avoid them.
Roughly a third of SASE projects stall, roll back, or quietly die. The pattern is consistent across industry reports and community discussions: in every single failure, the technology worked. The platform did what it was supposed to do. The failure was organizational.
This is an opinionated piece. I am going to name the patterns I see repeatedly, and some of them will be uncomfortable because they point at people and processes, not products.
Pattern 1: The turf war
SASE collapses networking and security into one platform. That means the networking team and the security team — who have operated independently for a decade — suddenly share a console. Someone has to own it. Usually, nobody wants to give up control, and nobody wants to report to the other team's VP.
The fix is not technology. It is organizational design. The most successful SASE deployments create a "Network Security" or "Infrastructure Security" team that reports to the CISO and includes both networking and security engineers. The least successful maintain separate teams with a "collaboration agreement" that has no enforcement mechanism.
Pattern 2: No executive sponsor
SASE is a cross-functional project. It touches identity (IAM team), endpoints (endpoint team), networking (network team), security (security team), and operations (helpdesk, change management). Without an executive who can resolve disputes, allocate budget across teams, and prioritize SASE work when it conflicts with other projects, the deployment stalls at the first cross-team dependency.
The most common stall point: the SASE agent needs to be deployed to all endpoints via Intune or JAMF. The endpoint team has a full backlog and puts the SASE agent deployment at the bottom of the queue. Without an executive who can reprioritize their backlog, you wait. And wait.
Pattern 3: Boiling the ocean
The vendor sold the full vision: SWG, CASB, ZTNA, DLP, FWaaS, SD-WAN, DEM — all at once. The project plan has a 12-month timeline with a big-bang cutover at the end. This never works.
Successful SASE deployments ship value in the first two weeks. DNS-layer protection or SWG in monitor mode can be live within days and immediately shows the security team what threats are hitting the organization. That quick win builds credibility and momentum for the harder phases (ZTNA, DLP) that require more organizational change.
- Week 1–2: DNS protection + SWG in monitor mode
- Month 1–2: SWG in enforce mode + ZTNA pilot group
- Month 2–4: ZTNA full rollout, VPN decommission
- Month 4–6: CASB discovery + DLP in monitor mode
- Month 6–9: DLP enforcement + SD-WAN pilot (if applicable)
- Month 9–12: SD-WAN full deployment + DEM
Each phase has its own success criteria, its own metrics, and its own executive review. If Phase 2 stalls, Phase 1's value is already delivered and cannot be taken away.
Pattern 4: Treating it as a technology project
SASE changes how users connect to applications. That is a user experience change, and it requires change management. If the first time users hear about SASE is when their VPN stops working and an unfamiliar agent appears on their laptop, you have failed at communication.
The best SASE rollouts include a company-wide email from the CTO explaining why the change is happening, a 5-minute video walkthrough showing what the new agent looks like and how to get help, a dedicated Slack channel staffed by the SASE team for the first month, and weekly "what changed this week" updates sent to all affected users. Total effort: maybe 20 hours of communication work spread across three months. The return on investment is essentially zero complaints from a 3,000-person user base.
Pattern 5: Measuring the wrong things
Too many SASE projects measure success by percentage of users migrated. That is an output metric, not an outcome metric. Migration percentage tells you nothing about whether the deployment is actually improving security or user experience.
Measure outcomes instead:
- Threats blocked per week (SWG value)
- Mean time to connect to applications (ZTNA value vs. VPN baseline)
- Shadow IT applications discovered and remediated (CASB value)
- DLP policy violations detected (DLP value)
- Helpdesk tickets related to remote access (operational improvement)
- MPLS cost reduction (SD-WAN value, if applicable)
The uncomfortable truth
SASE vendors will tell you their platform is easy to deploy. It is — technically. A competent engineer can configure SWG policies in an afternoon. But deploying SASE into a real organization with real politics, real legacy infrastructure, and real users who do not like change is an organizational transformation project that happens to involve technology. Treat it accordingly, and it will succeed. Treat it as a technology project, and it will fail in ways that have nothing to do with the technology.
Sources
- Gartner, "Strategic Roadmap for SASE Convergence" (2024) — gartner.com
- Gartner, "Market Guide for Security Service Edge" (2024) — gartner.com
- CISA, "Zero Trust Maturity Model" Version 2.0 (2023) — cisa.gov
- Fortinet, "SASE Deployment Best Practices" — fortinet.com
Related on sase.cloud
One email per publish. Unsubscribe anytime.