What Is SASE? Secure Access Service Edge Explained

Five capabilities appear in nearly every definition. Software-defined wide-area networking steers traffic across whichever links a site has, from central policy. A secure web gateway inspects and filters outbound web traffic, applying URL and category policy, malware scanning and increasingly content controls. A cloud access security broker governs use of software-as-a-service applications — which ones, by whom, and what data may move into and out of them. Zero-trust network access replaces the traditional remote-access VPN with per-application authorization based on identity and device state. Firewall-as-a-service provides the stateful and application-aware filtering that used to be a branch appliance.

Around those five, platforms add functions that are easier to run centrally than per site: DNS-layer filtering, inline data loss prevention, remote browser isolation, sandboxing of downloads, and inspection of traffic to and from cloud infrastructure. None of these are new capabilities. What is new is that a single policy expressed once — this group of people, on devices in this condition, may reach these applications under these conditions — is enforced across all of them rather than restated in five consoles.

You will also meet SSE, security service edge, which is the same platform without the network steering: the security half on its own, for organizations that already have a wide-area network they are not replacing or that intend to keep those two decisions with different suppliers. That split is the most useful distinction in the vocabulary, because it separates a networking project from a security one, and many buyers only need the second.

The fabric is a set of points of presence — data centers around the world running the provider's inspection stack. A branch site connects to the nearest one over an encrypted tunnel from its edge appliance; a remote user connects through a lightweight agent on the laptop; a cloud environment connects through a virtual instance or a peering arrangement. Once traffic is inside the fabric, policy is applied at that point of presence and the traffic egresses toward its destination from there.

Two properties follow from that shape. The first is that inspection stops being a capacity problem at each site — a small office and a large one get the same policy and the same inspection depth, because the work is done in a facility sized for it. The second is that latency now depends on the distance to the nearest point of presence, which makes the provider's map of them a genuine technical criterion rather than a marketing slide. Ask where the points of presence serving your actual locations are, and test from those locations rather than from headquarters.

TLS inspection is the specific thing to plan around. Most of the security value of a web gateway or inline data-loss control requires decrypting traffic, which means the fabric holds a certificate that every managed device trusts, and it means applications that pin certificates will break until they are excluded. That is manageable, and it is a project of its own — certificate distribution, an exclusion list that has to be maintained, and a documented position on which categories of traffic are never decrypted, such as banking and health. Deciding all of that after go-live is the usual reason a rollout stalls.

A cloud security fabric does not empty the comms room. Each site still needs an edge device to terminate its links and build the tunnels into the fabric — usually the SD-WAN appliance, sometimes a router with the provider's software on it — and that device is sized by encrypted throughput with the features you will actually enable, not by port count. Sites that must stay up through a hardware failure need two of them, which is a per-site decision rather than an estate-wide one.

Below that, nothing changes: access switches, PoE for phones, cameras and access points, the wireless infrastructure itself, structured cabling and patching, the rack, and power protection for all of it. If anything, a design that depends on reaching a cloud fabric raises the importance of the local plant, because a site with a single uplink and no battery behind the switch now loses its security policy along with its connectivity. Cellular failover as a second path is a common and inexpensive answer, and it is a hardware line item.

The other on-premises reality is what does not go through the fabric at all. Traffic between devices inside a site — a workstation to a local server, a scanner to a print server, industrial equipment to a controller — never leaves the building, and no cloud-delivered control sees it. That traffic is still governed by segmentation on the switches and by network access control at the port, which is why a SASE program usually runs alongside those rather than replacing them.

The distinguishing idea, and the one that separates a real SASE deployment from a set of cloud-hosted appliances, is that access decisions are made from identity and context rather than from network position. Every request carries a user, a device and a set of conditions — is the device managed, is it compliant, where is it, what is being asked for — and policy evaluates all of them each time rather than granting a network address and trusting whatever comes from it afterwards.

That is the same principle NIST Special Publication 800-207 sets out for zero-trust architecture: an explicit, per-request access decision made by a policy engine, informed by device state and continuously re-evaluated. CISA's Zero Trust Maturity Model describes the same target across its pillars and is the reference most public-sector programs are measured against. SASE is one delivery model for parts of that — chiefly the network and, through zero-trust network access, the application pillar — and it is not the whole of it. Identity governance, device management and data protection sit outside the fabric and have to be delivered by something.

The practical implication is that the identity provider becomes the most load-bearing system in the design. Multi-factor authentication, conditional access rules, group hygiene and device-compliance signals are what the policy is actually made of, and a fabric applying rich policy on top of a poorly maintained directory produces confident enforcement of the wrong thing. Anyone whose group memberships are three reorganizations out of date should fix that before it starts governing network access.

A single-vendor platform delivers the network and security halves from one stack, with one policy model, one console and one place to call. The integration is genuine and so is the coupling: replacing any component later means unpicking the whole. A dual-vendor approach pairs a network platform with a separate security service edge, which preserves choice on both sides and costs integration effort and, on a bad day, an argument about whose problem the latency is.

The question that cuts through most proposals is which components are actually included at the tier being quoted, and where each one runs. It is common for a bundle to include the network steering and a web gateway while zero-trust network access, cloud application controls, data loss prevention and sandboxing are separate line items — or included at a tier above. Ask for the component list against the licence, not against the platform, and ask which of them are the vendor's own code and which are acquisitions still being integrated, because a shared console is not the same as a shared policy engine.

Then price the whole thing honestly. Licensing is typically per user, sometimes per site or per bandwidth tier, and it is recurring; the appliances are capital; the circuits are ordered separately from whichever providers serve each location, and their lead times, not the platform's, set the schedule. Appliances, subscriptions and staging can be quoted on one document so the capital and recurring halves are visible together — which is worth doing, because a budget built from the hardware line alone will be wrong by a large multiple.

For public-sector buyers, start with authorization status. A cloud-delivered security service processes the organization's traffic, so whether the platform holds a FedRAMP authorization at the impact level the data requires is a threshold question rather than a detail, and it varies by component within a vendor's own portfolio — the web gateway and the zero-trust access service are not always authorized together. Ask per component, and ask which government environment the traffic actually lands in.

Then settle the failure behavior, because it is the question most likely to be skipped and most likely to matter. If a site cannot reach the fabric, does the edge device fail open and let traffic out unprotected, fail closed and take the site offline, or fall back to a local policy set? Each is defensible in different places, and the wrong default discovered during an outage is expensive. Ask the same question for the endpoint agent when a laptop is somewhere the fabric is unreachable.

Finally, the boring commercial ones that decide how the next five years go. Where telemetry and logs are stored and for how long, and whether you can export them. What the contract term is and what renewal looks like when the platform is load-bearing for connectivity as well as security. Whether the policy model can be exported in any form if you leave. And what happens operationally on the day the platform's own certificate authority, agent or policy push has a bad release — because when the network path and the security policy come from the same supplier, a single incident reaches further than it used to.