Zero Trust Network Access
Connects a verified user to one specific application, not the whole network. Access is re-checked continuously, so a session that turns risky can be cut off while it is still running.
In-depth briefs
30 articles · coming soonComparisonSASE vs Zero TrustDifferences in architecture and scopeComing soon
ComponentSASE ComponentsThe core building blocks of a SASE architectureComing soon
AdoptionManaged SASEOutsourcing SASE delivery and operationsComing soon
AdoptionSASE for MSPsHow service providers deliver SASEComing soon
The idea
What SASE is trying to fix.
Analyst firm Gartner coined the term SASE in 2019. The word describes a pattern more than a product, so two vendors can both say "SASE" and mean quite different things under the hood.
For decades the model was simple: staff sat in an office, applications lived in a data center down the hall, and a firewall guarded the one door between the office and the internet. Security was mostly a matter of controlling that door.
Then the applications moved to the cloud and the staff moved home. The traffic that used to stay inside the building now goes straight out to Microsoft 365, Salesforce, and a hundred other services.
Basically, your firewall sitting in your headquarters or one of your branch offices is underutilized, since the traffic it used to protect is no longer behind it.
The first fix was to route all of the organization's traffic back to that firewall over a VPN, inspect it there, then send it out to the internet. This is called backhaul, and technically it works. But it adds distance (latency) to every connection, turns the firewall into a performance bottleneck, and makes the user in Los Angeles wait for a round trip through a data center in Chicago to reach a service hosted twenty milliseconds away. People notice. They turn the VPN off. And then nothing is inspected at all.
The second fix was to bolt on point products: a web gateway here, a cloud access broker there, a zero-trust agent on every laptop. Each one solves a real problem. Together they mean four consoles, four policy engines, and four different answers to the question "is this user allowed to do this?"
SASE is the answer to these problems. Instead of hauling traffic back to one box, it delivers networking and security together, as a unified service, right where your users and workloads already are. Two jobs that used to need separate appliances are folded into one: moving traffic efficiently and inspecting and controlling it. The result is a single policy, applied at the nearest edge, for anyone connecting from anywhere.
The short version
SASE = networking + security, converged into one policy and enforced at the nearest edge instead of at a central chokepoint.
The architecture
The two halves of every SASE.
Before comparing vendors, it helps to see how a SASE platform is built. Underneath the acronyms, every SASE has two parts: a management plane and an enforcement plane.
Plane 1
The management plane
Where you author policy, and where telemetry from everywhere is aggregated into dashboards, reports, and alerts. It is the brain: it decides the rules and shows you what happened. It never touches a packet itself.
Plane 2
The enforcement plane
Where live traffic is actually inspected against those rules, and where the telemetry is produced in the first place. It is the muscle: every packet that gets allowed, blocked, or logged passes through here.
Both planes are always present. What differs between platforms is where each one runs, and that is the choice that shapes performance, cost, and control.
Where does enforcement happen?
In most SASE solutions on the market today, enforcement happens in the vendor's cloud. Traffic is routed to the nearest point of presence (PoP) the vendor operates, inspected there against your policy, then forwarded to its destination. The appeal is simple: the vendor owns and runs the inspection infrastructure, so you do not have to.
Where does management happen?
The management plane is almost always cloud-based, too: a console you log into to write policy and read reports, from wherever you are. Few people argue with keeping management in the cloud, and it stays cloud-delivered in nearly every model, including the distributed one described later.
The status quo
For the majority of SASE offerings today, both planes live in the vendor's cloud: management in a cloud console, and enforcement in cloud PoPs your traffic is routed through. That is the model most people picture when they say "SASE." The real question is whether enforcement has to live there.
The components
What is actually inside.
SASE is a bundle. The security half is often called SSE (Security Service Edge); add the networking half and you have SASE. These are the pieces most vendors agree belong in the box.
Secure Web Gateway
Inspects web traffic to block malicious sites, malware, and policy violations. A filter that follows the user wherever they connect from.
Cloud Access Security Broker
Sees which cloud apps are in use, including the ones IT never approved, and applies rules to sensitive actions inside them, like blocking an upload to a personal drive.
Firewall as a Service
Delivers stateful firewalling and intrusion prevention from the service edge, so a branch gets the same protection without a physical firewall in every closet.
Software-Defined WAN
The networking half. Picks the best path for each application across whatever links are available, and can replace expensive private MPLS circuits.
Data Loss Prevention
Classifies sensitive content and controls where it can go, so a customer list or a patient record does not quietly leave through email or a SaaS app.
Why bundle them
Chaining six separate products means traffic gets decrypted, inspected, and re-encrypted at each hop, while policy and context can become fragmented across products and consoles. A converged platform decodes the session once and lets every check read from that. Adding a control becomes a setting, not another box on the rack.
A different approach
A distributed, flexible architecture.
Enforcement does not have to live in the vendor's cloud. In a distributed architecture the management plane stays cloud-based, but enforcement moves out to wherever your traffic actually is.
Instead of routing every connection to a vendor PoP, a distributed platform runs its enforcement engine on infrastructure that is already close to the traffic: endpoints, branch gateways, firewalls, cloud VMs, containers, and compatible ISP or CPE devices. Policy and visibility are still authored and aggregated centrally, in one cloud console, so you manage everything in one place. Only the inspection moves.
That flexibility is the value. Traffic is inspected inline, where it originates, which shortens the path and keeps latency low. Sensitive traffic can stay on infrastructure you control, which helps with privacy and data residency. And you can adopt it in stages on gear you already own, without redirecting your whole network onto someone else's cloud.
Distributed vs. sovereign
These two words often get used interchangeably, but they are not the same. Distributed describes where enforcement runs. Sovereignty describes how much control you keep over where your traffic, inspection, policies, logs, keys, and data are processed and stored. A distributed architecture can enable sovereignty, but one does not automatically deliver the other.
Cloud-only vs. distributed: why architecture matters
Both are valid, and many organizations run a hybrid. The right choice depends on your environment, so read these as trade-offs. The middle column names the cloud-specific concerns to weigh.
| Consideration | Cloud-only | Cloud-specific concerns | Distributed |
|---|---|---|---|
| Traffic path | Traffic travels through the vendor's PoP before reaching its destination, which keeps routing uniform and predictable. | Even traffic between two nearby points detours out to a distant PoP and back. | Inspected close to its source or destination and can take a more direct path. |
| Performance | Consistent when users sit near a PoP. | A distant or congested PoP adds hops and latency, and the detour is mandatory. | Local inline inspection avoids the detour, provided each edge has adequate capacity. |
| Remote users | A vendor tunnel or proxy protects users anywhere, with no local software to maintain. | If a user drops the tunnel to regain speed, inspection stops with it. | Enforcement on the endpoint follows the user across home, mobile, and public networks. |
| Availability | The vendor handles redundancy and failover. | Losing the assigned PoP reroutes traffic farther away and can interrupt or degrade it. | Each edge retains its own policy, so there is less reliance on one central path. |
| Privacy & sovereignty | Simple to operate, since the vendor runs the inspection. | Traffic is decrypted inside vendor infrastructure; residency is limited to available PoP locations. | Inspection runs in an environment you select, giving more control over where data is handled. |
| Deployment | Turnkey once connected. | Requires tunnels, connectors, and migrating policy onto the vendor's network, often with a parallel run. | Reuses existing gateways, endpoints, cloud, and ISP/CPE devices without a full redesign. |
| Enforcement design | One consistent place to run security. | That single place is also a single chokepoint every packet must reach. | Security placed across endpoints, gateways, containers, cloud, and edges where needed. |
| Coverage | Broad global reach through an established PoP network. | Protection depends on traffic staying on the path to the cloud. | Extends to branches, cloud workloads, containers, legacy systems, IoT, and agentless devices. |
| Branches & IoT | Consistent branch policy delivered from the cloud. | Branch traffic must be routed to the cloud or secured with extra appliances. | Enforcement runs on the branch gateway or ISP/CPE device, protecting local users, servers, and IoT. |
| Cloud & containers | Managed centrally along with everything else. | Workload traffic may have to leave its environment to reach inspection. | Enforcement sits inside the customer's cloud, VPC, or container, close to the workload. |
| Cost model | Predictable subscription. | Mandatory PoP transit can add bandwidth and traffic-based charges. | Avoids mandatory PoP transit; use the enforcement infrastructure that fits your environment. |
| Management | Centralized management with centralized enforcement, which is operationally simple. | Reach and capacity are bounded by the vendor's PoP footprint. | Centralized management with distributed enforcement across many points. |
Distributed does not mean endpoint-only
A distributed platform can place enforcement at several points at once, all governed by one console and consistent policy:
- On the endpoint — protects remote and roaming users wherever they connect.
- At the network edge or gateway — protects branches, servers, legacy systems, IoT, and devices that cannot run an agent.
- On compatible ISP or CPE devices — lets ISPs and service providers deliver enforcement through existing customer-edge infrastructure.
- Inside a cloud or container — protects cloud workloads and traffic within a customer-controlled VPC or deployment.
- At the destination — inspects private-access traffic before it reaches the protected application.
- Through an optional hosted gateway — supports a static IP, centralized egress, or regional presence when a use case calls for it.
Why distributed enforcement matters
Users, applications, branches, devices, and workloads no longer sit behind one perimeter. When traffic originates everywhere, forcing every connection through a fixed central point can add routing, latency, dependencies, and bottlenecks. Enforcing closer to where traffic starts, or where the resource lives, can provide:
- More direct traffic paths and better performance
- Consistent protection for remote and roaming users
- Flexible enforcement across endpoints, branches, ISP/CPE devices, cloud workloads, containers, and gateways
- Greater control over where traffic is inspected
- Better resilience when a central service or connection is unavailable
- Easier alignment with sovereignty and regional requirements
- Faster deployment without replacing existing infrastructure
Where enforcement can run
Where a platform can enforce depends on its architecture. A cloud-only model inspects in the vendor's cloud, a distributed model inspects across your own edges, and a hybrid model uses both. The tags show which architectures each location fits.
| Location | Architecture | How it works | Best suited for |
|---|---|---|---|
| Vendor cloud PoP | Cloud-onlyHybrid | Traffic is redirected to infrastructure the SASE vendor operates, where inspection and policy enforcement happen. | Organizations that want the vendor to run the enforcement infrastructure, with users located near available PoPs. |
| Endpoint | HybridDistributed | Security runs directly on the user's device and inspects traffic before it leaves the endpoint. | Remote and roaming users who need protection without routing every connection through a central gateway or PoP. |
| Network edge / gateway / ISP device | HybridDistributed | Enforcement runs on a branch gateway, firewall, server, compatible ISP/CPE device, or other network edge. | Branches, customer premises, ISP-managed environments, servers, legacy systems, and IoT that cannot run endpoint software. |
| Customer cloud / container | HybridDistributed | Enforcement runs inside a customer-controlled VPC, cloud VM, or container, alongside the protected workload. | Cloud workloads, containerized apps, and organizations that want inspection to stay within their chosen cloud. |
| Dedicated hosted gateway * | Cloud-onlyHybridDistributed | Enforcement runs in a customer-specific gateway hosted by the provider or a service partner. | Organizations needing a static IP, centralized egress, regional presence, or a managed enforcement option. |
These are enforcement locations, not separate architectures. In a distributed model, policy and visibility stay centrally managed while enforcement is placed across endpoints, gateways, branches, cloud and container environments, compatible ISP/CPE devices, and other selected edges.
* What a dedicated or hosted gateway actually enforces varies by vendor. Some run the full security stack on the local or hosted appliance (for example, Zscaler); others use it mainly as a hosted egress or connectivity point with lighter inspection. Confirm what a given platform's gateway inspects before relying on it.
Adoption
Adopt SASE without a full rip-and-replace.
Moving to SASE does not have to begin with a network-wide migration. A distributed architecture lets you introduce protection where it is needed first and expand over time.
Traditional cloud-PoP rollouts often ask you to redirect traffic, stand up tunnels and connectors, migrate policy to the vendor's cloud, and sometimes replace existing security gear. That creates a long transition where the old and new environments must run in parallel. Enforcement added to infrastructure you already own can start smaller and grow.
| Phase | What the organization can do |
|---|---|
| 1 · Start with the immediate need | Begin with remote-user protection, secure private access, a branch office, a cloud workload, or another priority use case. |
| 2 · Use existing infrastructure | Add enforcement to compatible endpoints, gateways, ISP/CPE devices, cloud VMs, or containers without replacing the underlying environment. |
| 3 · Extend protection | Expand the same policies to more users, branches, devices, applications, and workloads as requirements grow. |
| 4 · Unify policy and visibility | Centrally manage policy and gain consistent visibility across the distributed enforcement points. |
| 5 · Retire redundant tools on your schedule | Replace legacy VPNs, appliances, or point products when it makes operational and financial sense, not as a prerequisite. |
In practice
Distributed SASE in practice.
To make the distributed model concrete, here is one platform built that way. It is an illustrative example, not an endorsement.
Zenarmor is an example of a distributed SASE architecture. Its enforcement engine can run on endpoints, network gateways, cloud environments, containers, compatible ISP and CPE devices, and other customer- or partner-selected edges, while policy and visibility are managed centrally through its Zenconsole management plane. That lets an organization place enforcement where it best supports performance, protection, control, and operational needs.
It pairs that deployment model with a single-app, single-stack, single-pass design: networking, access, and security run through one engine, so traffic is inspected once and policy is applied consistently across enforcement points. The result is less repeated processing, fewer fragmented tools, and lower management overhead.
"Traditional SASE architectures introduce integration challenges and operational blind spots due to their dependence on cloud-based PoPs. By eliminating PoPs and enabling direct, point-to-point secure connections with inline inspection, [a distributed] architecture reduces latency, accelerates deployment, and lowers operational complexity."
Before you sign
Questions that separate vendors fast.
Feature sheets look identical. Differences show up under load, across distance, and during failure. A few questions cut through the marketing quickly.
At which locations can enforcement run, and can it use our existing gear?
The core question. Can inspection run in a vendor PoP, on the endpoint, at a gateway, on a compatible ISP/CPE device, or inside our own cloud and containers? And can it reuse gateways and infrastructure we already operate, or does everything have to move onto the vendor's network?
Can different users, branches, and workloads use different enforcement points from one console?
Real environments are mixed. A platform worth its name lets you place enforcement where each case needs it (endpoint for roaming users, gateway for a branch, in-cloud for a workload) while still managing all of it under one policy and one console.
Must all traffic route through a vendor PoP, or can locally inspected traffic go direct?
If every connection has to detour through the vendor's cloud, you inherit that path's latency and dependencies. Ask whether traffic inspected locally can travel straight to its destination.
Who controls the infrastructure, and where do traffic, logs, keys, and policy data live?
This is the sovereignty question made concrete. Determine who operates the enforcement infrastructure and in which jurisdictions your traffic is decrypted and your logs, keys, and policy are stored. For regulated or public-sector work, that answer can decide the whole evaluation.
Are the same security capabilities available at every enforcement point?
Some platforms offer full inspection in the cloud but a thinner feature set on the endpoint or gateway. Confirm that the controls you care about (TLS inspection, DLP, app control) work consistently everywhere enforcement runs.
Which parts did you build vs. acquire or resell?
A platform stitched together from acquisitions often shows its seams: multiple consoles, inconsistent logs, and support teams that hand you off. One engine that decodes traffic a single time behaves more predictably than several products chained in a row.
What happens during an outage or network partition?
If a control plane or a PoP becomes unreachable, does enforcement keep working? Distributed models where each edge holds a compiled copy of policy can keep enforcing while disconnected; a design that phones home for every decision cannot.
How is encrypted traffic handled?
Almost all threats now arrive over TLS, so inspection has to reach inside encryption to be useful. But blanket decryption is a legal and ethical problem. Ask to see how inspection scope and exclusions (banking, health, and similar) are expressed as reviewable policy.
What does it cost to retire the old stack?
The subscription price is the easy number. Add migration labor, contract termination on the gear you are replacing, and the 60-to-90-day parallel run where you pay for both while policy is moved safely. That parallel-run cost is the line most plans forget.
"I have used many SSE and SASE solutions and none have been as simple to administrate as Zenarmor. There is nothing out there that comes close."
Neutral references
Further reading.
Independent, vendor-neutral resources for going deeper. These are third-party sources, grouped by what they are best for.
Definitional guideTechTarget: Complete SASE GuideDefinition, architecture, components, benefits, challenges, and SASE vs. SSE / SD-WAN / Zero Trust.Read ↗
Definitional guideIntelligent Visibility: What Is SASE?Legacy vs. SASE architecture, the five components, SASE vs. SSE, and single- vs. dual-vendor SASE.Read ↗
Definitional guideCharting Cyber: Vendor-Neutral SASEApproachable explanations of components, use cases, benefits, SSE, and common misconceptions.Read ↗
Standards & industryMplify Alliance: SASE HubIndustry standards, terminology, service attributes, Zero Trust, certification, and enterprise RFI resources.Read ↗
Independent testingCyberRatings.orgIndependent test reports on SSE, SD-WAN, ZTNA, and firewalls: security effectiveness and performance.Read ↗
Comparison & buyer guidanceGartner Peer Insights: SASEVendor listings, product summaries, comparisons, and verified customer reviews.Read ↗
Comparison & buyer guidanceSASECompareFeature matrices, vendor profiles, category comparisons, and vendor rankings.Read ↗
Comparison & buyer guidanceSDxCentral / CyberRatings: SASE RFPSASE evaluation criteria, RFP resources, and buyer guidance for structuring a selection.Read ↗
Links open third-party sites in a new tab. The source list is tracked in docs/sase-reference-sources.md.
Reference
The acronyms, decoded.
Keep this handy on your next vendor call.
SASESecure Access Service Edge. Networking and security converged into one edge-delivered service. Say "sassy."
SSESecurity Service Edge. The security half of SASE (SWG, CASB, ZTNA, DLP) without the networking (SD-WAN).
ZTNAZero Trust Network Access. Verified access to one app at a time, re-checked continuously. Replaces the always-on VPN.
SWGSecure Web Gateway. Filters and inspects outbound web traffic for threats and policy.
CASBCloud Access Security Broker. Visibility and control over the cloud and SaaS apps in use.
FWaaSFirewall as a Service. Cloud- or edge-delivered firewalling and intrusion prevention.
SD-WANSoftware-Defined WAN. Intelligent path selection across links; the networking layer of SASE.
DLPData Loss Prevention. Stops sensitive data from leaving where it should not go.
PoPPoint of Presence. A vendor-operated location where cloud-delivered SASE inspects your traffic.
BackhaulRouting traffic back to a central point before sending it on. The delay SASE aims to remove.