Security moved to the cloud edge, and picked up two acronyms on the way.
February 3, 2026
Secure Access Service Edge, or SASE, was named by Gartner in 2019. Security Service Edge, or SSE, followed as the name for the security half of it on its own.
Underneath the acronyms is a real architectural change: security controls moved from appliances in your building to a provider's global network, so they apply wherever the user is.
The old model sent all traffic back to headquarters to pass through the security stack, then out to the internet. That was fine when applications lived in headquarters.
When the applications moved to the cloud and the users moved to their homes, backhauling became absurd: traffic travelling from a house to an office to a cloud provider and back, adding latency and cost for no benefit.
SASE moves the inspection point to a provider's points of presence near the user. Traffic goes user, to nearby enforcement point, to destination.
SASE is the full bundle: networking plus security. The networking part is software defined wide area networking, which handles branch connectivity and path selection.
SSE is the security half only: secure web gateway, cloud access security broker, zero trust network access, and usually firewall as a service and data loss prevention.
The distinction is commercially useful. Many organizations already have a network vendor they are happy with and only want the security services, which is exactly the SSE purchase.
The inspection point for outbound web traffic. It applies URL and category filtering, inspects TLS, blocks malware, and enforces acceptable use.
The main design question is TLS inspection, because almost all traffic is encrypted. Decrypting it gives visibility and creates privacy, legal, and certificate management obligations. Most organizations decrypt selectively, excluding banking and health categories.
A CASB sits between users and SaaS applications and answers questions the network layer cannot: which cloud applications are in use, who is using them, what data is being uploaded, and how the applications are configured.
It typically works in two modes. Inline, which sees traffic in real time, and API based, which connects directly to the SaaS provider and can inspect data already stored there and check configuration.
This is the main commercial answer to shadow SaaS discovery, and increasingly to shadow AI discovery too.
Zero trust network access replaces the VPN with per application access, covered fully in ZTNA versus VPN.
Firewall as a service moves the branch firewall into the provider's cloud, handling non web traffic and outbound rules for sites that no longer need a physical appliance.
DLP identifies sensitive data and applies policy when it moves: blocking uploads, warning users, or logging. In an SSE platform it applies uniformly across web, SaaS, and private applications.
Set expectations honestly. DLP is very good at catching accidental exposure, which is most real data loss. It is not a reliable barrier against a determined insider who has time and knows the policy.
The major vendors are Zscaler, Netskope, Palo Alto Networks Prisma SASE, Cloudflare, Cisco, Cato Networks, and Fortinet.
The questions that separate them: where are the points of presence relative to your users, is policy genuinely unified or several acquired products behind one login, what does the client agent do to a laptop, how does it handle traffic it cannot decrypt, and what happens when the service is unreachable.
That last one deserves a real answer during evaluation, not after. You are putting a dependency in the path of all traffic.
You are trusting a provider with visibility into effectively all of your traffic, which is a significant concentration of trust and a compliance conversation in regulated industries.
Migration is slower than the sales cycle suggests, because the hard part is not the technology, it is discovering and rewriting years of accumulated firewall and proxy rules that nobody documented.
And it does not remove the need to understand networking. When something breaks, the person who can read a packet capture is still the person who fixes it.
Week 7 of the mentorship uses log data to do by hand what a CASB does automatically, which is the best way to understand what these platforms are actually doing.