Full-stack SASE: from a pile of point products to one converged network and security platform

What we see in the field

Walk into a multi-site organization and the network security stack usually looks like this: an SD-WAN (software-defined wide-area network) from one vendor at the branches, firewalls from another vendor on premises or in the data center, and a separate cloud service for the security service edge (SSE: web gateway, SaaS access control and zero-trust network access) and for remote-user VPN. A pairing we see constantly is a VeloCloud SD-WAN with Zscaler for the edge, or with on-premises firewalling from Fortinet or Palo Alto Networks.

To be fair to that model, it has historically worked, and it still works today. The cost is overhead. Every platform has its own console, its own policy language, its own logging, its own upgrade cycle and its own renewal. A change to one policy has to be reproduced in two or three places. Troubleshooting a user’s bad day means correlating across all of them. The infrastructure team spends its week keeping the pieces consistent rather than improving anything, and the organization pays three or four vendors for overlapping functions.

What converged SASE changes

SASE (secure access service edge) is the convergence of that networking and security stack into one cloud-delivered platform. A handful of vendors have moved all the way there, with SD-WAN, firewall, web gateway, SaaS access control and zero-trust access built as one system rather than bundled: Netskope, Versa, Cato Networks and Aryaka among them.

Two things change when the stack is genuinely converged. The first is management: one console and one policy that follows the user and the application wherever they are, which is what people mean by “single pane of glass.” The second is architecture: zero trust stops being a remote-access feature bolted onto a VPN and becomes the way every session is evaluated, end to end, at scale. Identity and device posture drive access to the branch, to the data center, to SaaS and to the cloud the same way.

Why so many SASE projects stall

Almost every client we talk to wants this. The struggle is rarely the platform. It is mapping the transition from the stack they have to the platform they want, without breaking the business in between. A converged SASE platform sits in the path of everything, so the partner doing the work has to become intimately involved with far more than the high-level network diagram:

• The internal applications: where they live, who uses them, what they talk to, what cannot tolerate a change in path or inspection.
• The SaaS partners the organization has chosen, and how each one handles identity, data and access control.
• The large language models (LLMs) the organization uses, what data flows to them, and what policy should govern that.
• The cloud environments, regions and the private connectivity already in place to each.
• The identity provider and device management that zero-trust decisions will depend on.

Partners who skip this discover it during the rollout, one surprise at a time. The project slows, exceptions pile up, and the converged platform ends up configured to look like the old stack it replaced.

Do the mapping before the platform is chosen

The pattern we see in successful projects is simple: take the team through that understanding during pre-sales, before a platform is selected. The discovery produces a map of users, sites, applications, SaaS, LLMs, clouds and identity, plus the handful of flows that must not change. That map does three jobs. It tells you which converged platforms genuinely fit. It becomes the pilot design, so the pilot tests the hard cases rather than the easy ones. And it becomes the rollout sequence, site by site and application by application, once the platform is chosen. Pilots designed this way succeed, and the rollout that follows looks like the pilot rather than a new project.

Transport and overlay: the half that gets forgotten

A SASE platform is only as good as the paths underneath it. The overlay cannot fix a branch that is on the wrong transport, and a cloud point of presence is only close if the circuit reaches it well. This is where Nimbl Networks’ connectivity relationships matter: with the map in hand we help choose the right OEM for the platform, the proper transport for the applications actually in play at each site (dedicated internet, broadband, wave transport, private cloud connectivity), and the right overlay technologies to improve performance for the traffic that is critical. Our primary SD-WAN and SASE providers are Zayo, AT&T, Lumen and Halo Global, and the platform decision and the transport decision are made together rather than in sequence.

A path that holds up

1. Map the current stack, the applications, the SaaS platforms, the LLMs, the clouds and the identity layer. Write down the flows that must not change.
2. Shortlist the converged platforms that fit the map, and the transport and overlay options for each site.
3. Pilot the hard cases: a site with legacy applications, a remote group, a SaaS platform with strict access rules.
4. Roll out in the sequence the map suggests, retiring a point product only once its function is proven on the platform.
5. Retire and renegotiate: the firewalls, the VPN, the separate SSE subscription and the circuits that only existed for backhaul. The savings live here, and only appear if someone owns this step.