If your SASE rollout fails, it won’t fail in a dramatic way. There won’t be an outage that pages the NOC at 3 AM. It will fail slowly, quietly, in a conference room, when someone from the security team and someone from the networking team realize they’ve been building two separate things for six months and nobody told them to connect.
That’s the real risk with SASE. Not the technology—the technology is mature. The risk is the sequence. Deploy in the wrong order, and you spend a year rearchitecting a half-built system while your legacy VPNs keep running because nobody’s confident enough to pull the plug.
SASE—Secure Access Service Edge—converges wide-area networking and cloud-delivered security into a single platform. SD-WAN, Secure Web Gateway, Cloud Access Security Broker, Firewall as a Service, and Zero Trust Network Access all live under one architectural umbrella. In theory, this simplifies everything. In practice, getting there requires dismantling decisions that organizations spent a decade building and replaced them in the right order. Skip a step, and you’ve replaced one set of problems with a more expensive set.
The shape of that transformation looks like this — a perimeter built around a hardened datacenter and bottlenecked by VPN concentrators, replaced by a distributed edge that meets users wherever they actually work:
[Image: images/sase-before-after-network.png]The trombone effect on the left is the operational debt SASE pays down. The work in this post is moving from the left model to the right one — in the right order.
Here’s the implementation sequence that actually works.
Step 1: Assess Network Topology and Traffic Flows
Before you touch a single vendor portal, you need a brutally honest picture of where your traffic actually goes. Not where the network diagrams say it goes—where it actually goes.
Most enterprises discover something uncomfortable during this phase: a significant portion of their “internal” traffic is backhauling through a central data center to reach SaaS applications that are sitting on the public internet. Users in a branch office hit Salesforce by routing through headquarters first. Every Teams call takes a detour through your data center before reaching Microsoft’s servers. This is the “trombone effect”—traffic that stretches out and snaps back instead of taking the direct path—and it’s the single biggest driver of the latency complaints your help desk keeps logging.
To quantify this, measure round-trip time for remote users accessing SaaS applications via VPN versus direct-to-net. That baseline is critical—it’s the number you’ll use to justify the project budget and demonstrate ROI in Step 7.
Beyond latency, you need to understand traffic sources (remote users, branch offices, IoT devices, cloud workloads), traffic destinations (data center apps, IaaS, SaaS), and encryption requirements. That last category matters because SSL/TLS inspection is resource-intensive. If you’re not accounting for it now, you’ll hit capacity problems later when the SASE platform starts decrypting traffic at scale.
The most critical output from this phase is an application dependency map. ZTNA doesn’t grant network access—it grants application access. That’s a fundamental shift. If an application uses a web front end that connects to a separate database backend, ZTNA needs to know about both. Miss the database connection, and your users will complain that the app “kind of works” for two weeks before someone tracks down why.
Zscaler’s Private Access includes Application Discovery, which logs the specific applications users hit and shows the last 14 days of discovered apps in the dashboard. Let that window collect enough traffic to show real usage before you start building policies. That data is worth more than any spreadsheet your network team maintains.
Step 2: Architecture Selection—Single-Vendor vs. Best-of-Breed
The architecture decision you make in week two will determine how painful your week 104 is. Take it seriously.
The single-vendor approach gives you a unified management console, a single endpoint agent, and a shared data lake for networking and security telemetry. Cato Networks built SD-WAN and SSE into a single software stack from the start, which reduces integration overhead because the components already speak the same language. Palo Alto Prisma SASE takes a similar unified-platform approach. The tradeoff is lock-in: if your vendor is excellent at security but mediocre at SD-WAN performance in Southeast Asia, you’re stuck with mediocre SD-WAN in Southeast Asia. Industry coverage keeps making the same point: secure advanced SD-WAN is critical to SASE, so the market is moving this direction regardless.
The best-of-breed approach lets you keep an existing SD-WAN investment and add a best-in-class SSE layer on top. Zscaler is frequently deployed this way—as the SSE component layered onto Cisco, Aruba, or VMware SD-WAN. The tradeoff is operational complexity: multiple dashboards, potential for policy inconsistencies, and packet steering configurations between the SD-WAN edge and the SSE cloud that require ongoing maintenance.
Neither approach is universally right. Organizations replacing MPLS and wanting one throat to choke tend toward single-vendor. Organizations with substantial SD-WAN investments that work well tend toward best-of-breed. The honest question to ask your team: “Do we have the operational maturity to run two platforms as if they’re one?”
The trade-offs that actually matter live in six dimensions. The matrix below scores both approaches against each so the conversation with your team is grounded in something more specific than vendor pitch decks:
[Image: images/sase-vendor-comparison-matrix.png]Use this as the starting point for the architecture conversation, not the ending point. The right answer depends on which dimensions your organization can actually afford to lose on.
Step 3: Identity and Policy Definition
SASE doesn’t use IP addresses as the perimeter. Identity is the perimeter. This step is where the transition becomes concrete.
Major SASE vendors expose SAML 2.0 and SCIM integrations for common IdPs such as Okta, Microsoft Entra ID, and PingOne. Once connected, security policies attach to users and groups rather than subnets and IP ranges. “The HR group can access the payroll application from devices with current OS patches and active disk encryption” is a ZTNA policy. “Anyone on the 10.10.x.x subnet can reach 192.168.50.4 on port 5432” is what you’re replacing.
Palo Alto’s ZTNA 2.0 takes this further with continuous trust verification. Legacy ZTNA 1.0 authenticates a session at the start and then largely trusts it for its duration. ZTNA 2.0 keeps checking—if device posture changes mid-session (say, the endpoint agent reports that antivirus stopped running), the policy engine can terminate or restrict the session. This isn’t just a marketing distinction; it closes a genuine gap that attackers have used to maintain persistence after initial authentication.
Cato’s identity-aware routing adds another dimension: policies can dictate not just whether a user can access an application, but how that traffic is prioritized across their global backbone. A video call for an executive might get QoS treatment that a background sync job doesn’t. That kind of granularity requires the networking layer and the security layer to share identity context, which is one reason single-vendor architectures have an advantage here.
Step 4: SD-WAN and Edge Integration
This is where physical hardware appears. Every branch office, data center, and cloud environment needs a path into the SASE provider’s cloud.
Cato ships “Socket” appliances that support Zero Touch Provisioning—they arrive at a branch, get plugged in, and automatically connect to the nearest Cato Point of Presence. No pre-staging required. For organizations replacing MPLS, this is the most operationally significant change: the Socket handles link aggregation, and all traffic flows through Cato’s global private backbone rather than leased lines.
Palo Alto’s Prisma SD-WAN devices (formerly CloudGenix ION) operate at Layer 7 and steer traffic based on application performance SLAs rather than raw packet metrics. They know the difference between a Teams call and a backup job and treat them accordingly.
Cloudflare One’s Magic WAN Connector establishes tunnels to Cloudflare’s Anycast network automatically. Because Cloudflare advertises the same IP addresses globally, traffic often enters a nearby data center, though Cloudflare documents that routing can land in a different location for reliability reasons. That model is architecturally different from Zscaler’s connector model, but it does not eliminate PoP-selection tradeoffs entirely.
For cloud environments, Zscaler deploys Cloud Connectors as virtual machines inside AWS or Azure VPCs. Cloudflare uses Anycast IP tunnels—same model as their WAN architecture, applied to cloud. The key question during this phase: can you actually cut over branch by branch, or do you have dependencies that require a big-bang migration? Most enterprises that try the big-bang approach regret it.
Step 5: Configure ZTNA and Retire the VPNs
This is the phase your security team has been waiting for and your help desk is dreading. Go slow.
The standard approach is parallel operation. Run the SASE client alongside the legacy VPN client. Initially, the SASE agent captures internet and SaaS traffic while the VPN handles private data center access. As you define applications in the ZTNA policy engine and validate that traffic flows correctly, move specific routes from the VPN to SASE. Zscaler’s Application Discovery is particularly useful here—it helps administrators observe which applications users reach while the VPN remains active, so nothing gets missed before the VPN is decommissioned.
The payoff is application segmentation that a VPN can’t offer. VPN gives users network access, which means a compromised endpoint can reach everything on the same subnet. ZTNA gives users application access only. Palo Alto’s App-ID technology identifies applications regardless of port, so policies are written against “Salesforce” or “the HR portal” rather than IP addresses and TCP ports. Lateral movement from a compromised endpoint becomes significantly harder when the endpoint can only see what it’s explicitly been granted access to.
Don’t underestimate the user communication required during cutover. Users notice when their VPN client disappears. Brief them, document the new client behavior, and have help desk scripts ready for the common “I can’t reach X anymore” calls you’ll get in the first two weeks.
Step 6: Endpoint Agent Deployment
The SASE agent is the new network perimeter. Deploy it carefully.
Cloudflare’s WARP client is architecturally flexible. You can run it in DNS only, Traffic and DNS, Traffic only, Local proxy, or Posture only mode depending on what you’re trying to protect. Cloudflare One Client uses MASQUE by default and also supports WireGuard, which handles fast roaming better than IPsec—users moving between networks don’t drop sessions. Zscaler’s Client Connector (formerly Z-App) supports Z-Tunnel 2.0 using DTLS, which tunnels all ports and protocols rather than just HTTP/HTTPS, addressing a limitation of earlier proxy architectures.
Device posture checks are where this phase connects back to identity. Zscaler’s device posture profiles show how agents can evaluate criteria on the device before policy is applied. Before establishing a tunnel, the agent checks for disk encryption, OS patch levels, registry keys, and running security software. Palo Alto’s GlobalProtect integration with Prisma can quarantine a device that fails posture—not just deny the specific connection attempt, but restrict the device from all corporate resources until it’s remediated. That enforcement only works if your posture policies are well-tested before you enforce them broadly. Pilot aggressively, roll out carefully.
Cato’s client adds self-healing connectivity: it automatically selects the optimal PoP and switches dynamically if a user travels or the current PoP degrades. Users don’t notice the failover. That’s the goal—a security architecture that’s invisible when it’s working.
Step 7: Measure Security Outcomes and User Experience
SASE implementations that don’t measure outcomes become SASE implementations that get questioned at budget review. Set your metrics now.
Legacy monitoring tools—SNMP, ping-based checks—are blind to cloud-delivered security. You need Digital Experience Monitoring to understand what users actually experience, not what your infrastructure reports.
Palo Alto’s Autonomous DEM (ADEM) is natively integrated into the GlobalProtect agent and runs synthetic tests from the user’s laptop to the application. It can isolate whether latency is caused by the Wi-Fi, the ISP, the SASE cloud, or the application server itself—hop-by-hop visibility that transforms help desk calls from “it’s slow” into “the ISP between your ISP and our PoP has 40ms of added latency.” Zscaler’s Digital Experience (ZDX) provides similar endpoint-to-cloud visibility and aggregates it into a ZDX Score by region, so IT teams can proactively spot degradation before it generates tickets.
Security effectiveness metrics are equally important. Track reduction in inbound ports exposed on internet-facing firewalls—with full ZTNA, that number should approach zero. Measure lateral movement prevention: how many attempts to access unauthorized internal applications are being blocked. Track SSL/TLS inspection coverage. These numbers tell the story of what SASE actually changed, not just what you deployed.
Key Insight: The SASE rollout that fails fastest is the one that treats Step 7 as optional. If you can’t demonstrate measurable security improvement and user experience improvement, you can’t justify the next phase of the rollout—or the renewal.
Choosing Your Vendor
The four leading platforms serve genuinely different organizational needs, and the differences aren’t marketing—they’re architectural.
| Feature | Zscaler (ZIA/ZPA) | Cloudflare One | Palo Alto Prisma SASE | Cato Networks |
|---|---|---|---|---|
| Architecture | Proxy-based (Zero Trust Exchange) | Network-based (Global Anycast) | Flow-based (ZTNA 2.0) | Converged private backbone |
| On-Prem Edge | App Connectors (VMs, outbound-only) | Magic WAN Connector (HW/VM) | Prisma SD-WAN ION devices | Cato Socket (ZTP hardware) |
| Backbone | Public internet + private peering | Massive Anycast network | GCP/AWS + private peering | SLA-backed global private network |
| Best For | SSE-first, VPN replacement | NaaS, cloud-native orgs | Deep security, existing Palo Alto | MPLS replacement, mid-market |
Zscaler remains the most mature SSE platform. Its App Connector architecture—where connectors make outbound-only connections so no inbound ports are ever exposed—is the enterprise standard for secure third-party access. The SD-WAN capabilities are improving, but if branch connectivity is your primary driver, pair it with a dedicated SD-WAN partner or evaluate the others.
Cloudflare One has an edge in performance: every server in every city runs every service, so traffic enters the nearest location without hairpinning to a centralized inspection point. For cloud-native organizations without substantial on-premises infrastructure, the setup velocity is hard to match.
Palo Alto Prisma SASE wins on security depth and user experience visibility. ADEM’s hop-by-hop telemetry is genuinely differentiated, and ZTNA 2.0’s continuous verification closes holes that legacy ZTNA left open. It’s a complex platform to configure—essentially a distributed next-generation firewall—but organizations with existing Palo Alto deployments have a path through that complexity.
Cato Networks wins on convergence and simplicity. Because they built SD-WAN and SSE together from inception rather than acquiring separate products, there’s no integration friction. Their global private backbone provides MPLS-comparable SLAs over the internet. The tradeoff is a closed ecosystem—you generally use the full Cato stack, which means less flexibility if you want to bring in best-of-breed components.
Reality Check: No vendor will tell you where they’re weakest. Run your own PoC for each shortlisted vendor against your actual traffic patterns—not their lab environment. Sixty days of real data will surface the gaps their sales team won’t.
Getting the Sequence Right
The seven steps above aren’t arbitrary—they’re sequential because each one creates the preconditions for the next. You can’t define meaningful ZTNA policies (Step 3) until you’ve mapped your applications (Step 1). You can’t retire VPNs (Step 5) until you’ve configured ZTNA (Steps 3 and 4). You can’t measure outcomes (Step 7) until you have a baseline to measure against.
Where most enterprise deployments stumble is treating this as a technology project rather than an architectural transformation. The traffic assessment gets compressed. The architecture decision gets made by a vendor instead of by the organization. Policy definition starts with the vendor’s default templates rather than the organization’s actual access requirements. Then six months later, you’re explaining to the CISO why the SASE platform is running in parallel with the VPN with no end date in sight.
Follow the sequence. Take the assessment seriously. Make the architecture decision before you start the PoC, not after. And measure everything.
The organizations that execute this well don’t just end up with a better security architecture—they end up knowing their network better than they did before they started. That knowledge is worth something independent of the SASE deployment itself.
