Secure Access Service Edge (SASE, pronounced “sassy”) is an architecture that delivers networking and security together from the cloud. Instead of routing traffic back to a data center to pass through a stack of firewalls and proxies, users and offices connect to the provider’s nearest point of presence, where security policy is applied before traffic goes on to the internet, SaaS apps or private applications. SASE combines SD-WAN with a set of security services, typically a secure web gateway, a cloud access security broker, zero trust network access and firewall as a service.
At a glance
- SASE combines SD-WAN networking and cloud-delivered security; a single policy and console is the goal, though how unified it is varies by offering.
- The security half is usually secure web gateway (SWG), cloud access security broker (CASB), zero trust network access (ZTNA) and firewall as a service (FWaaS), often with data loss prevention (DLP).
- Policy follows the user and device, so a person gets the same protection in the office, at home or travelling.
- It can come from one vendor or from two vendors integrated together, and multi-vendor setups usually share less policy and logging.
- Most companies adopt it in phases rather than in a single cutover.
What problem it solves
Traditional network security assumed people and applications were inside the office or data center. Branches sent internet traffic back to headquarters over MPLS, and remote users connected through a VPN to the same central firewall. That design struggles once most applications live in SaaS and the public cloud and most people work from anywhere. Backhauling everything to one site adds delay, overloads the central firewall and VPN concentrator, and gives users a reason to bypass security when it gets in the way.
It also tends to produce a sprawl of separate products: a router and firewall at every branch, a web proxy, a VPN, a CASB, each with its own console, rules and renewal date. Policies drift apart, and it becomes hard to answer basic questions such as who accessed what and from where.
SASE moves inspection to the cloud, close to where users are, and aims to put networking and security under one policy so the same rules apply regardless of location. How fully that happens depends on the offering: single-vendor platforms tend to share one policy engine, while multi-vendor pairings may keep separate consoles and rules.
How it works
Connecting. Remote users install an agent (sometimes called a client or connector) that sends their traffic to the provider. Offices connect with an SD-WAN appliance or an IPsec tunnel from an existing firewall or router. Private applications in a data center or cloud are reached through a lightweight connector, so they don’t need to be exposed to the internet.
Inspecting. At the provider’s point of presence, traffic passes through the security services. The SWG filters web traffic and blocks malicious sites; the CASB controls use of SaaS applications; ZTNA grants access to specific private applications after checking identity and device posture; FWaaS applies firewall rules to non-web traffic. Much of this inspection depends on decrypting TLS traffic, which is where a lot of the policy detail and privacy exceptions live.
Policy and identity. Rules are written against users, groups, devices and applications, drawing on your identity provider, rather than against IP addresses and office locations. The aim is for the same policy to be enforced wherever the user connects; check how much of it is shared between the networking and security components in practice.
Networking. The SD-WAN side steers branch traffic over the best available link (fiber, broadband, cellular) and sends it to the nearest point of presence. Some providers run their own backbone between points of presence; others rely on the public internet. Point-of-presence locations and capacity vary a lot by provider and matter for performance.
When it matters for buyers
- When the VPN or central firewall is the bottleneck. Complaints about slow SaaS apps from home or from branches are a common trigger.
- When MPLS or branch firewall contracts come up for renewal. Renewal is a natural point to rethink WAN and security together rather than replacing like for like.
- When opening offices or absorbing an acquisition. Bringing a new site onto SASE can be faster than shipping and configuring a full branch security stack.
- When cyber insurance or audits ask about remote access. Insurers and auditors increasingly ask about MFA, VPN exposure and how remote access is controlled.
- When the team is small. Consolidating several products into one service can reduce the number of consoles and vendors a lean team has to run.
Questions to ask vendors
- Which components are native to your platform and which come from partners or acquisitions, and do they share one policy engine, one console and one agent?
- Where are your points of presence relative to our offices and users, and do you run your own backbone between them?
- How do you handle TLS inspection, and how do we exempt categories such as banking or healthcare?
- How do you support legacy applications and non-web traffic that ZTNA may not cover?
- What SD-WAN options do you support, and can we keep our existing SD-WAN or firewalls during the transition?
- What uptime and latency commitments are in the SLA, and what happens to traffic if a point of presence fails?
- How is it priced (per user, per site, by bandwidth), and which features cost extra?
- What logs can we export to our SIEM, and how long are they retained?
How it differs from SSE
Security Service Edge (SSE) is the security half of SASE on its own: SWG, CASB, ZTNA and, in most definitions, FWaaS, without the SD-WAN networking. SSE protects users and data wherever they are; SASE also takes over how branches connect. Buyers often start with SSE to fix remote access and web security, then add SD-WAN when WAN contracts allow. Neither replaces a firewall in every case: sites with heavy local traffic or on-premises servers may still need one.
How it differs from SD-WAN
SD-WAN is a networking technology that manages traffic across multiple links between sites and the internet. Many SD-WAN appliances include a basic firewall, but SD-WAN alone doesn’t provide cloud-delivered web, SaaS and private-app security for remote users. SASE is SD-WAN plus that security layer. For a broader look at rollout options, see our Secure Access Service Edge (SASE) guide and SASE vs VPN.
Problems this helps with
- Remote users backhauled through a data center VPN that slows everything down
- Separate boxes and consoles for branch networking and security
- Inconsistent security for people in the office, at home and on the road
- Too many vendors to manage for WAN, firewall and web security
