Zero Trust, SASE, and SSE: what they mean for network architecture
Zero Trust, Secure Access Service Edge (SASE), and Secure Service Edge (SSE) are frequently used to describe a new wave of enterprise network architecture, but the terms are often conflated. Behind the buzzwords are concrete goals: delivering a more secure, faster, and more reliable experience for end users, applications, and networks. Understanding what each framework actually covers is essential for planning a modern network security strategy.
Zero Trust: trust nobody by default
Zero Trust is an IT security model that requires strict identity verification for every person and device attempting to access resources on a private network, regardless of whether they are inside or outside the network perimeter. This stands in contrast to the traditional perimeter-based model—often called “castle and moat”—where users gain access to resources once they are granted access to the network itself.
Simply put, traditional IT network security trusts anyone and anything inside the network. A Zero Trust architecture trusts no one and nothing by default.
SASE: the framework for Zero Trust
Gartner introduced SASE as the framework for implementing a Zero Trust architecture across an organization. SASE combines software-defined networking capabilities with network security functions, all delivered from a single cloud platform. This allows employees to authenticate and securely connect to internal resources from anywhere, and gives organizations control over traffic and data entering and leaving the internal network.
The Secure Access component of SASE involves defining Zero Trust security policies across user devices, applications, branch traffic, data center traffic, and cloud traffic. The Service Edge component ensures all traffic passes through these controls regardless of location, without requiring backhauling to a central hub where enforcement occurs.
SSE: a subset and stepping stone
SSE, also coined by Gartner, is a subset of SASE functionality focused specifically on security enforcement. SSE is a common stepping stone to full SASE deployment, which extends security controls to the corporate Wide Area Network (WAN) and adds software-defined networking capabilities such as traffic shaping and quality of service.
What actually makes up SASE
Common definitions of SASE list security functions like Zero Trust Network Access (ZTNA) and Cloud Access Security Broker (CASB), focusing on what a SASE platform does. These definitions are incomplete: they miss describing how the functions are achieved, which is equally important.
A complete definition of SASE builds on this list to include three distinct aspects: secure access, on-ramps, and service edge.

Secure access: the security functions
Secure Access functions operate across your traffic to keep users, applications, networks, and data secure. In an input/process/output (IPO) model, secure access represents the processes that monitor and act on traffic.

Zero Trust Network Access (ZTNA)
ZTNA makes it possible to implement a Zero Trust model by requiring strict verification for every user and device before authorizing access to internal resources. Compared to traditional VPNs, which grant access to an entire local network at once, ZTNA only grants access to the specific application requested and denies access to applications and data by default.
ZTNA can work with other application security functions, such as Web Application Firewalls, DDoS protection, and bot management, to protect applications on the public Internet.
Secure Web Gateway (SWG)
A Secure Web Gateway operates between a corporate network and the Internet to enforce security policies and protect company data. Whether traffic originates from a user device, branch office, or application, SWGs provide URL filtering, malware detection and blocking, and application control. As corporate traffic increasingly shifts from private networks to the Internet, SWG has become critical to protecting devices, networks, and data.
SWGs can work with other tools including Web Application Firewalls and Network Firewalls to secure both inbound and outbound traffic. They can also integrate with Remote Browser Isolation (RBI) to prevent malware from affecting corporate devices without completely blocking user access to Internet resources.
Remote Browser Isolation (RBI)
Browser isolation keeps browsing activity secure by separating the process of loading webpages from the user devices displaying them. Potentially malicious webpage code never runs on a user’s device, preventing malware infections and other attacks from impacting devices and internal networks.
RBI works alongside other secure access functions—for example, security teams can configure Secure Web Gateway policies to automatically isolate traffic to known or potentially suspicious websites.
Cloud Access Security Broker (CASB)
A CASB scans, detects, and continuously monitors for security issues in SaaS applications. Organizations use CASB for:
- Data security—ensuring files or folders are not shared publicly in Dropbox
- User activity—alerting to suspicious user permission changes
- Misconfigurations—keeping recordings from becoming publicly accessible
- Compliance—tracking and reporting who modified access permissions
- Shadow IT—detecting users signed up for unapproved applications with work email
API-driven CASBs leverage integrations with SaaS applications and take only minutes to connect. CASB can also be used with RBI to detect and prevent unwanted behaviors in approved and unsanctioned SaaS applications, such as disabling file downloads or copying text from documents.
Data Loss Prevention (DLP)
Data loss prevention tools detect and prevent data exfiltration—data moving without company authorization—or data destruction. Many DLP solutions analyze network traffic and endpoint devices to identify leakage or loss of confidential information such as credit card numbers and personally identifiable information (PII). DLP uses techniques including data fingerprinting, keyword matching, pattern matching, and file matching.
Firewall-as-a-service
Firewall-as-a-service, also called cloud firewall, filters potentially malicious traffic without requiring physical hardware within a customer network.
Email security
Email security prevents email-based cyber attacks and unwanted communications. It covers inbox protection from takeover, domain protection from spoofing, phishing prevention, fraud and malware blocking, spam filtering, and encryption of email contents.
Email security tools can be combined with other secure access functions including DLP and RBI—for example, suspicious links in emails can be launched in an isolated browser without blocking legitimate messages.
On-ramps and the service edge
The security functions above only matter if traffic can reach them. On-ramps provide the ways for different traffic sources—user devices, branch offices, data centers, or applications—to connect to the security controls. The service edge is the distributed cloud network that delivers those controls close to the user, avoiding thundering backhaul to a central location. A complete SASE platform brings all three aspects together, allowing organizations to implement Zero Trust principles across every user, device, and traffic flow.
Traffic on-ramps
Before secure access functions can be applied, traffic must first reach the service edge where those controls operate. On-ramps provide that path, originating from remote devices, branch offices, data centers, or the cloud. The right on-ramp depends on the source and type of traffic you need to connect.

Application-layer access
For web-based applications, a reverse proxy sits in front of web servers and forwards client requests. Combined with identity and endpoint security providers, this pattern grants controlled network access to web apps without exposing the underlying infrastructure.
When deployed as a reverse proxy, the security layer terminates the user's request and re-establishes it to the origin server, keeping the origin's address hidden. Cloudflare One leverages a reverse proxy that handles more than 1.39 billion DNS requests daily.
Private or non-web applications need a different approach. An application connector — a lightweight daemon installed in your infrastructure — creates an outbound-only connection to the service edge. This covers HTTP web servers, SSH servers, remote desktops, and other protocols without opening inbound ports that could invite attacks. Cloudflare Tunnel implements this model with an encrypted tunnel between the origin server and the nearest Cloudflare data center.
Device and network on-ramps
End-user devices such as laptops and phones need a device client, or roaming agent, that acts as a forward proxy. It directs some or all traffic from the device to the service edge for filtering and private network access. The WARP client from Cloudflare One is available for iOS, Android, ChromeOS, Mac, Linux, and Windows.
For branches, data centers, and clouds, options expand. Organizations can bring their own IPs or lease IPs, advertising ranges via BGP across the provider's Anycast network. Many existing hardware and virtual devices also support network tunnels using industry-standard protocols like GRE and IPsec. These establish network-level connectivity from a physical location to the service edge. Cloudflare One's Anycast GRE and IPsec tunnel options behave like traditional point-to-point tunnels but connect automatically to the entire Cloudflare network, simplifying management and redundancy. This also works well with existing SD-WAN equipment, enabling largely automated configuration.
For high-reliability, high-capacity needs, a direct connection via physical cross-connect, last-mile fiber, or virtual fabric gives the most predictable path. Cloudflare Network Interconnect (CNI) provides this through a direct physical link or a partner's virtual connection. Cloudflare for Offices extends CNI directly to physical premises.
The service edge underneath
Secure access functions must run somewhere. With SASE, that is no longer a hardware rack in a data center; it is a distributed network as close to users and applications as possible. However, not all service edges perform equally. A viable platform must offer speed, intelligence, interoperability, programmability, and visibility — because security filtering no longer has to come at the expense of performance.

Performance foundations
When the security and networking stack moves to a distributed edge, the usual trade-offs between enabling security functions and maintaining throughput disappear — provided the edge delivers on several fronts:
- Geographic dispersion: Edge locations should sit close to where users and apps actually are.
- Interconnectivity: The edge must interconnect with major transit, cloud, and SaaS networks for reliable routing to final destinations.
- Speed: Perceived performance covers last-mile connectivity, filtering overhead, and encryption/decryption steps; the whole path must be measured and tuned.
- Capacity: With SASE, capacity planning for security is handled at each edge location, with intelligent load balancing across the network.
Cloudflare One runs on a network spanning 270+ cities in over 100 countries, with 10,500+ interconnected networks and more than 140 Tbps of capacity.
Intelligence and shaping
The service edge also needs to react to live network conditions. Traffic shaping, quality of service (QoS), and telemetry-based routing prioritize bandwidth for critical applications and steer traffic around congestion and packet loss. Argo Smart Routing in Cloudflare One applies this at Layer 3 through 7, with further QoS capabilities planned.
Security functions depend on an up-to-date threat intelligence feed covering known and emerging attack types across the OSI stack. Third-party feeds are useful; native intelligence derived from the edge's own traffic is stronger. Cloudflare One ingests threat data from the 20M+ properties on its network and feeds it continuously into access policies.
Openness and automation
A SASE platform will replace many legacy components, but not all. It must remain interoperable with existing connectivity providers, hardware, endpoint protection tools, and SIEMs. It should also adopt new standards — TLS 1.3, HTTP/3, and others — as they mature, and be fully composable so components combine to drive better outcomes than point solutions alone.
Cloudflare One integrates with identity providers, endpoint protection platforms, SD-WAN appliances, interconnection partners, and SIEMs. A complete API and Terraform support let teams deploy and manage configuration as code.
Visibility restored
The old perimeter model gave IT and security teams visibility through taps at a handful of entry and exit points. As applications moved to the cloud and users left the office, that visibility fragmented. Because a SASE architecture routes all traffic through a service edge with a single control plane, analytics come back — through flow data, packet captures, and rich logs. Cloudflare One generates this data for every secure access component, available in its dashboard or forwarded to SIEM tools for deeper analysis.



