SASE and Zero Trust come up together constantly, and the SASE vs Zero Trust question usually comes from treating them as competing choices, which they are not.
Zero Trust is a security model: no user or device is trusted by default, and every request has to be continuously verified. Secure Access Service Edge (SASE) is an architecture that combines Software-Defined Wide Area Network (SD-WAN) networking with cloud-delivered security in a single service.
Zero Trust is also built into SASE, because Zero Trust Network Access (ZTNA), the component that checks identity and context on every connection, is one of SASE’s core parts. That makes Zero Trust both a principle that SASE follows and a component SASE includes. A SASE Zero Trust architecture applies these identity-based checks to every user, device, and application, whether it connects from the cloud, a remote site, or on-premises.
What is SASE?
Secure Access Service Edge (SASE) is a cloud-delivered architecture that combines wide-area networking and network security into a single service. Gartner introduced the term SASE in its 2019 report “The Future of Network Security Is in the Cloud.” SASE is usually described as cloud-delivered, but in hybrid and more distributed deployments, inspection and enforcement can also run closer to the traffic at branch appliances, gateways, private clouds, or endpoints.
SASE combines SD-WAN, Firewall as a Service (FWaaS), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), and Zero Trust Network Access (ZTNA) into one policy framework. SASE enforces policy at globally distributed points of presence (PoPs) or edge-deployed Policy Enforcement Points (PEPs). SASE identifies users and devices through identity, not through network location, which is why SASE is a natural way to deliver Zero Trust.
Gartner forecasts that a majority of enterprises will have explicit SASE adoption strategies by the mid-2020s, up from roughly 10% in 2020. These functions are described in more detail in SASE Solutions. The components below are how SASE turns Zero Trust from a principle into enforced policy.
What are the Core Components of SASE that Deliver Zero Trust?
The core components of SASE that deliver Zero Trust are the 5 converged functions listed below.
- SD-WAN: SD-WAN operates the software-defined networking layer, steering traffic from branches and users toward the nearest SASE point of presence. SD-WAN selects the paths that carry traffic to the point where Zero Trust policy is evaluated. Bandwidth allocation, path selection, and application prioritization happen dynamically, supporting consistent policy enforcement across distributed locations.
- FWaaS: Firewall as a Service functions like a cloud-hosted firewall, applying Layer 3 through Layer 7 inspection and removing dependence on on-premises appliances. Segmentation rules enforced through FWaaS support the Zero Trust assumption of breach. Inspection occurs at each traffic flow, blocking lateral movement, isolating compromised segments from the wider network.
- SWG: Secure Web Gateway filters web traffic, blocking malicious sites and enforcing acceptable use policy across the network. Continuous verification applies to outbound web sessions, checking each request against policy in real time, contributing to the Zero Trust tenet of “never trust, always verify.” Encrypted traffic inspection, content filtering, and malware detection happen at the gateway, preventing exposure before the connection reaches the destination.
- CASB: Cloud Access Security Broker operates a control point linking users to cloud applications, governing Software as a Service (SaaS) access and data movement. Least privilege extends to sanctioned and unsanctioned cloud services alike, through policy enforced by CASB. Visibility into shadow IT activity, data loss prevention, and encryption controls form the core functions delivered through the broker.
- ZTNA: Zero Trust Network Access operates the application-level access broker, replacing implicit network trust through per-session, identity-based authorization. ZTNA provides granular policy enforcement, verifying identity before granting session access. Session tokens, device posture checks, and contextual signals determine access decisions, updating continuously throughout the connection lifecycle.
What is Zero Trust?
Zero Trust is a security model that treats every user, device, and connection as untrusted until it is verified, regardless of network location. This verification must happen continuously, not just at the initial connection attempt.
John Kindervag introduced the Zero Trust model at Forrester Research in 2010. National Institute of Standards and Technology (NIST) formalized the model in Special Publication 800-207, Zero Trust Architecture, published in August 2020.
Zero Trust replaces the perimeter assumption, in which internal traffic is trusted, with per-request evaluation of identity, device posture, and context. Zero Trust is a set of principles that architectures such as SASE implement. The principles listed in the next section are the exact requirements that a SASE platform must satisfy to claim Zero Trust delivery.
What are the Core Principles of Zero Trust that SASE Enforces?
The core principles of Zero Trust that SASE enforces are the 5 rules listed below.
- Never trust, always verify: Never trust, always verify is the rule that every access request must be authenticated and authorized before it is granted. SASE applies the rule at every Point of Presence (PoP) for every session.
- Least privilege: Least privilege is the rule that a user receives access only to the specific application required, not to the network. SASE enforces least privilege through ZTNA application-level brokering.
- Microsegmentation: Microsegmentation is the division of the environment into small isolated zones that limit lateral movement. SASE implements microsegmentation through various methods including encrypted tunnels, FWaaS, and per-application access policies.
- Continuous verification: Continuous verification is the re-evaluation of identity, device posture, and risk during a session, not only at login. Security services integrated within the SASE architecture perform inline inspection of every session, enabling mid-session revocation.
- Assume breach: Assume breach is the design assumption that an attacker is already inside the environment. Zero Trust deployments limit the blast radius of a breach with a combination of microsegmentation, continuously validated authorization, and direct user-to-application access, ensuring that a compromised account or device doesn't gain broad access to the network.
ZTNA is the SASE component that puts all 5 principles into practice, which is why it gets its own section next.
What is Zero Trust Network Access (ZTNA) in SASE?
Zero Trust Network Access (ZTNA) in SASE is the mediation layer that brokers connections between verified users and specific private applications without exposing the network.
ZTNA evaluates identity from the identity provider, device posture from the endpoint agent, and context (location and time) before each connection is approved or denied. ZTNA operates on a default-deny basis, so an application is invisible to any user who lacks an explicit entitlement.
Gartner projects that ZTNA replaces the majority of remote access virtual private network (VPN) deployments in new implementations. ZTNA is one function of a SASE solution, not a standalone tool. The distinction between ZTNA and full SASE is covered in SASE vs ZTNA.
What is the Difference Between SASE and Zero Trust?
SASE provides the architectural framework for delivery, while Zero Trust is the governing access philosophy that framework enforces. SASE answers how services are delivered. Zero Trust answers whether an access request must be trusted. The table below compares SASE and Zero Trust across 6 decision-relevant attributes.
| Attribute | SASE | Zero Trust |
|---|---|---|
| Definition | Converged network and security architecture | Security principle for access decisions |
| Category | Delivery model and product category | Strategy and design philosophy |
| Scope | Networking (SD-WAN) plus security (Security Service Edge, or SSE, functions) | Identity-based security policy across all IT layers |
| Origin | Gartner, 2019 | Forrester (2010), NIST SP 800-207 (2020) |
| Form | Purchasable cloud service with PoPs | Not purchasable; implemented through tools |
| Enforcement point | Cloud PoP, or a distributed enforcement point (PEP) at the branch, gateway, or endpoint | Every policy decision point in the environment |
SASE adds networking to the security stack, but its scope is mainly about securing access. Zero Trust is broader: it applies to identity, data, and workloads across the whole enterprise, well beyond the access path SASE governs. The three questions below clear up where each one fits.
Is Zero Trust a Component of SASE or a Standalone Strategy?
NIST SP 800-207 defines Zero Trust Architecture without requiring SD-WAN or a cloud service edge. Zero Trust exists independently of SASE, a separation that NIST SP 800-207 establishes through its architecture components, threat assumptions, and deployment models.
Zero Trust principles are enforced across the SASE architecture, with ZTNA serving as the primary broker for private applications, while SWG, CASB, and FWaaS extend these same identity-driven policies to web, cloud, and network traffic.
An organization may pursue Zero Trust without SASE, but a SASE platform without Zero Trust principles is incomplete by Gartner’s own definition.
How Does Zero Trust Fit Within a SASE Architecture?
Zero Trust fits within a SASE architecture as the access-enforcement logic that every SASE component applies to every session. ZTNA acts as the primary enforcement layer by brokering user-to-application connections on a default-deny basis.
The identity provider feeds authentication signals, the endpoint agent feeds device posture, and the SASE PoP or PEP combines them into a per-session trust decision.
Firewall as a Service (FWaaS) and Secure Web Gateway (SWG) extend the same decision logic to network and web traffic, so contextual, granular Zero Trust policies follow the user across every channel. The functional split between the full architecture and its access layer is explained in SASE vs ZTNA.
The Zero Trust Policy Enforcement Point (PEP) is not fixed; it varies depending on the SASE architecture deployed, ranging from the network edge to the application layer or the organization's gateway. Single vendor platforms enforce policy at a unified PoP, evaluating identity, device posture, and session context in one pass.
Multi-vendor architectures split enforcement across separate SD-WAN, ZTNA, and PEP-based platforms, evaluating every access decision inside vendor-operated cloud data centers, cloud-based PoPs, or even on-premises gateways acting as PEPs.
Distributed SASE architectures, including Zenarmor, run the ZTNA enforcement stack directly at the point of access, on the endpoint, the network edge, or an organization's gateway. This distributed approach applies the same "never trust, always verify" decision without routing the session through an external inspection cloud, removing the latency of the PoP detour and keeping the trust evaluation inside organizational boundaries.
The principles of Zero Trust stay identical across PoP-based platforms and distributed architectures, and the difference is who controls the policy decision point: the vendor’s cloud or the organization’s own infrastructure. SASE and Zero Trust integrate tightly because they share several design assumptions.
What are the Similarities Between SASE and Zero Trust?
The similarities between SASE and Zero Trust are the 3 shared design assumptions listed below.
- Identity-centric access: Identity-centric access is the use of user and device identity, not IP address, as the basis of every access decision. SASE and Zero Trust treat identity as the new perimeter.
- Cloud delivery: Cloud delivery is the enforcement of policy from cloud-native infrastructure rather than fixed data-center appliances, whether that runs in a provider's PoP or at a distributed edge. SASE is built around this model, and cloud-based Zero Trust deployments adopt it for scale.
- Least privilege: Least privilege is the restriction of access to the minimum required resource. SASE and Zero Trust models reject broad network-level access in favor of application-level grants.
Identity is the strongest of these overlaps, so it is worth comparing how each handles it.
How Do SASE and Zero Trust Handle Identity?
SASE and Zero Trust handle identity as the primary input of every access decision, but they consume it at different layers. Zero Trust defines the requirement that every request must be tied to a verified identity with contextual attributes (device posture, location, and risk score).
SASE consumes that requirement operationally by integrating with an Identity Provider (Microsoft Entra ID or Okta) over Security Assertion Markup Language (SAML) 2.0 or OpenID Connect. The SASE PoP evaluates the identity assertion at session start and re-evaluates it continuously during the session.
Because identity matters so much to both, the next question is whether SASE and Zero Trust work as one system.
Can SASE and Zero Trust Work Together?
SASE and Zero Trust are complementary, not competing. Zero Trust provides the governing security philosophy, built on "never trust, always verify" and least privilege, that dictates how access decisions are made.
SASE is the converged platform that puts these principles into practice through integrated security services, including ZTNA, SWG, CASB, and FWaaS. While Zero Trust defines the "what" (policy), SASE provides the integrated infrastructure to execute that policy consistently.
Organizations that adopt SASE gain a unified framework for this enforcement; conversely, organizations that pursue Zero Trust without a converged platform must manually integrate and manage a patchwork of separate point products.
Does SASE Require Zero Trust?
Yes, SASE requires Zero Trust because Gartner’s SASE definition includes ZTNA as a core component and identity-driven policy as a core attribute. A SASE platform that grants network-level implicit trust does not meet the SASE definition, regardless of its feature list.
Does Zero Trust Require SASE?
No, Zero Trust does not require SASE, because NIST SP 800-207 defines Zero Trust Architecture independently of any delivery model. An organization implements Zero Trust with standalone ZTNA, identity governance, endpoint controls, and microsegmentation tools. SASE provides a unified enforcement framework for distributed workforces, integrating identity-centric security policies across web, cloud, and private access at the network edge.
Is SASE the Same as Zero Trust?
No, SASE is not the same as Zero Trust. SASE is a purchasable architecture; Zero Trust is a security model. SASE's role is the converged delivery of network and access security.
Zero Trust's role is the governing mandate that applies wherever data exists, regardless of whether it's behind a SASE gateway, inside a cloud workload, or sitting in a database. SASE delivers Zero Trust at the network and access layer.
What are the Benefits of Combining SASE and Zero Trust?
The benefits of combining SASE and Zero Trust are the 3 measurable outcomes listed below.
- Reduced attack surface: Reduced attack surface is the removal of exposed VPN gateways and open inbound ports, because ZTNA makes applications invisible to unauthorized users. Fewer exposed services directly lower the exploit paths available to attackers.
- Unified policy management: Unified policy management allows for the consistent application of granular, identity-driven access rules across web, SaaS, and private applications. This eliminates the policy gaps and fragmentation that appear when perimeter and security tools are managed separately, a gap analyzed in SASE vs Traditional Security.
- Simplified access: Simplified access replaces backhauled VPN connections with direct, brokered, per-application connections. Users connect via the nearest Policy Enforcement Point (PEP), which reduces latency while ensuring access rights remain scoped to the minimum required resource.
These benefits depend on getting the sequence right, which the adoption steps below lay out.
When Should an Organization Adopt Zero Trust Within SASE?
An organization should adopt Zero Trust within SASE when identity infrastructure, remote access pressure, and cloud application usage reach the readiness conditions in the 4 steps below.
- Assess identity maturity. Confirm that a central identity provider with multi-factor authentication (MFA) covers at least the workforce applications in scope, because Zero Trust policy quality equals identity signal quality.
- Define policy. Map every user group to the specific applications it requires, which converts the principle of least privilege into a written entitlement matrix.
- Operationalize ZTNA policy. Integrate the ZTNA service with the identity provider to enforce the defined access rules on a default-deny basis. This converts access requirements from written policy into active, identity-verified connections.
- Conduct a pilot. Deploy to a low-risk user group to validate identity integration, connectivity, and performance before expanding to broader or high-risk user segments.
Validate readiness by confirming that the pilot group reaches its applications without any network-level access, which is documented among the primary SASE Use Cases. Organizations still running a perimeter model follow the longer migration path below.
How Should an Organization Migrate from a Perimeter Model to Zero Trust SASE?
Migrating from a perimeter model to a SASE solution with Zero Trust is a 6-step process that replaces implicit network trust with identity-based access delivered from the cloud edge.
- Inventory applications, users, and traffic flows. Identify critical vs. non-critical flows to understand what the perimeter currently protects.
- Consolidate identity. Establish a single source of truth for identity with MFA enforced (the foundation for all access decisions).
- Run parallel deployment. Deploy ZTNA alongside the existing VPN. Publish low-risk applications first to validate connectivity without removing the legacy fallback.
- Iterative migration by application group. Migrate user access by application service rather than "big bang" user groups. Validate performance and accessibility wave-by-wave.
- Refine policy and enable advanced inspection. Only after connectivity is stable, move from "Log-only" or "Permissive" modes to full enforcement (SWG/CASB/FWaaS policies). This is the stage for tuning friction out of the system.
- Decommission legacy infrastructure. Systematically remove VPN concentrators and perimeter firewall rules once all traffic flows are verified on the new architecture.
Success is verified when sessions lack network-level access and logs capture identity, posture, and application-level decisions. The result is a Zero Trust architecture delivered through SASE. Organizations with residency constraints can achieve this same result locally using distributed enforcement platforms like Zenarmor, avoiding the need for cloud inspection.