SASE Explained: Converging Network and Security at the Edge

The perimeter you were defending no longer exists

For thirty years, network security assumed a defensible edge: users, applications, and data sat inside a building, traffic flowed through a stack of appliances at headquarters, and the firewall marked the line between trusted and untrusted. Two shifts dismantled that model. Applications moved to SaaS and public cloud, so the data you protect no longer lives behind your firewall. And users moved everywhere, so the people accessing that data no longer sit behind it either.

The workaround most organizations reached for was backhauling — hairpinning remote and branch traffic through a central data center over VPN or MPLS just so it could pass the security stack before heading back out to a cloud app that might be in the same region as the user. It adds latency, it concentrates load on VPN concentrators that were never sized for an all-remote workforce, and it does nothing for the fact that the trusted-inside assumption is simply wrong. Secure access service edge, or SASE (pronounced "sassy"), is the architectural response: deliver networking and security together, from the cloud, close to wherever the user and workload actually are.

What SASE actually combines

SASE is not a single product. Gartner's original framing describes the convergence of wide-area networking and network security into one cloud-delivered service. In practice that means five capabilities that historically came from five different vendors, now integrated at a distributed set of points of presence:

• SD-WAN — application-aware routing across whatever transport is available (broadband, LTE/5G, MPLS), with path selection, failover, and quality of service. This is the networking half. A well-run SD-WAN fabric is often the on-ramp that carries branch and remote traffic into the SASE edge.
• SWG (Secure Web Gateway) — inspects web and internet traffic, enforces acceptable-use and threat policy, and blocks malicious destinations. It replaces the on-premises proxy.
• CASB (Cloud Access Security Broker) — visibility and control over sanctioned and shadow SaaS: what data goes where, which apps are in use, and whether that usage meets policy. This is where much of your data-loss control lives.
• ZTNA (Zero Trust Network Access) — brokered, per-application access based on verified identity and device posture, rather than dropping a user onto a flat network segment. This is the piece that replaces VPN.
• FWaaS (Firewall as a Service) — cloud-delivered firewalling and intrusion prevention for non-web traffic, so branch offices do not each need their own appliance and rule set.

The value is not the checklist — it is the convergence. When these functions share one policy engine, one identity context, and one inspection path, a packet is decrypted once, evaluated against user, device, application, and data context together, and logged in one place. Stitching five standalone tools together gives you five consoles, five policy languages, and five blind spots where they hand off.

SASE vs SSE: know which half you are buying

The market split SASE into two halves, and the distinction matters when you scope a project.

• SSE (Security Service Edge) is the security half: SWG, CASB, ZTNA, and FWaaS, delivered from the cloud. It assumes your existing network connectivity stays as is.
• SASE is SSE plus the SD-WAN networking layer — the full convergence of security and WAN transport.

Most organizations enter through SSE. If your branches already have decent internet and your pain is remote access and SaaS control, you can adopt the security services without touching the WAN, and add SD-WAN later when circuit contracts come up for renewal. Naming your target as SSE-first or full-SASE up front prevents scope confusion and keeps a vendor from selling you WAN transformation you did not ask for.

Single-vendor vs best-of-breed

The central architectural decision is whether one platform delivers all five functions or whether you integrate specialists.

Single-vendor SASE means one policy engine, one agent on the endpoint, one dashboard, and one support relationship. Traffic is inspected once. This is the model that delivers the operational simplicity SASE promises, and for most mid-market organizations it is the right default. The tradeoff is that no single vendor is best-in-class at all five capabilities, and you take on real concentration risk — an outage or a pricing change at one provider affects everything.

Best-of-breed / dual-vendor pairs, say, a strong SD-WAN provider with a specialist SSE platform. You get stronger individual components and negotiating leverage, at the cost of integration work, potential double inspection, and two vendors pointing at each other when something breaks. Gartner's own guidance leans toward single-vendor or tightly-integrated dual-vendor SASE for most buyers, precisely because loosely coupled point products recreate the fragmentation SASE was meant to eliminate.

The honest evaluation questions:

1. Where are the vendor's points of presence, and are they near your users and your cloud regions? Latency is decided by geography.
2. Is inspection genuinely single-pass, or does traffic traverse multiple engines?
3. How is TLS decryption handled at scale without breaking certificate-pinned apps?
4. Is ZTNA a real identity-and-posture broker, or a rebadged cloud VPN?
5. What is the published availability, and what actually happens to traffic when a PoP fails?

A phased adoption path

SASE is a multi-year architecture change, not a switch you flip. The sequence below is the one we run for clients, and it front-loads the risk reduction so each phase stands on its own.

1. Start with ZTNA to replace VPN. This is almost always the first phase, and for good reason. It delivers immediate, visible risk reduction — brokered per-application access closes the flat-network exposure that legacy VPN creates — and it retires the VPN concentrator that has become your remote-access bottleneck. Roll it out one application group at a time, running ZTNA alongside the VPN, then decommission VPN access per app as coverage proves out.
2. Move web traffic to the cloud SWG. Redirect internet-bound traffic to the SASE edge and retire on-premises proxies. Users get consistent policy whether they are in an office, at home, or on the road, and you stop backhauling web traffic to a data center.
3. Bring SaaS under CASB and data-loss control. Turn on CASB to inventory sanctioned and shadow SaaS, then layer data-protection policy onto the apps that hold regulated or sensitive data.
4. Consolidate branch security into FWaaS. As branch firewall hardware reaches end of life, shift inspection to the cloud instead of refreshing appliances site by site.
5. Converge the WAN with SD-WAN. Align this with circuit renewals. Application- aware routing plus cloud on-ramps completes the SASE picture and is where the WAN cost savings materialize.

Two guardrails throughout. Run new controls in monitor mode before enforcement so you learn real traffic before you block it — the fastest way to get a SASE program cancelled is an outage on day one. And treat identity as the prerequisite, not a parallel workstream: ZTNA and conditional access are only as good as the identity provider and MFA behind them, so clean up authentication and privileged access first.

Where SASE fits in your broader strategy

SASE is best understood as the delivery mechanism for Zero Trust at the network layer. Zero Trust is the operating model — never trust based on network location, verify every request using identity, device, and context. SASE is how you enforce that model consistently for a distributed workforce and a cloud-hosted application estate, without hairpinning traffic through a headquarters that fewer and fewer people ever visit. The two initiatives should be planned together; a ZTNA rollout is simultaneously a SASE phase and a Zero Trust phase.

intSignal designs and operates secure access service edge deployments end to end — scoping SSE-first or full-SASE, selecting single-vendor or integrated architectures around your real footprint, and sequencing the rollout so VPN retirement and branch consolidation happen without disrupting production. If your remote access is straining and your security stack still assumes a perimeter that no longer exists, talk to our network team for a candid read on where to start.