SASE vs SSE vs ZTNA, Explained for Security Leaders

TL;DR: Secure access service edge (SASE) combines software-defined wide area networking (SD-WAN) with cloud-delivered security under one policy, security service edge (SSE) is that security half without the networking, and zero trust network access (ZTNA) is one part of SSE that grants access to a specific private application. They nest inside one another rather than compete. None of them is zero trust itself, which is a strategy. Products deliver pieces of it.

What is SASE?

Secure access service edge (SASE) joins software-defined wide area networking (SD-WAN) with cloud-delivered security services and runs both under one policy. Palo Alto Networks describes it as a model that "merges software-defined wide area networking (SD-WAN) with security capabilities, including secure web gateway (SWG), cloud access security broker (CASB), firewall as a service (FWaaS), and zero trust network access (ZTNA) into one platform" (Palo Alto Networks).

Those security parts are the same ones the security service edge (SSE) section breaks down. SASE adds SD-WAN to them.

Facts to carry away

• Gartner introduced the SASE concept in 2019 (Palo Alto Networks).
• SSE came after it. Palo Alto Networks dates SSE to Gartner's 2021 Roadmap for SASE Convergence report (Palo Alto Networks), and Zscaler also gives 2021 (Zscaler).
• Zscaler calls SASE "a framework, not one specific technology" (Zscaler). No single product is SASE on its own.
• Zscaler reads the creation of SSE as an admission that SASE "represented too big of a change for organizations to implement all at once" (Zscaler).

Why the edge matters

The word edge refers to where inspection happens. Palo Alto Networks says placing the services at the network's edge, "closer to where users and devices connect," helps reduce latency and improve performance (Palo Alto Networks).

A worked example makes the difference plain. Take a branch office in one city and a headquarters in another. A user at the branch opens a software-as-a-service (SaaS) app.

In the older design, that request leaves the branch, crosses the wide area network to headquarters, passes the security stack there, goes out to the internet, and returns by the same route. Zscaler describes this as backhauling traffic "to a central location and through a number of disjointed security appliances" (Zscaler). The user waits on a round trip to another city for an app that may be hosted closer to the branch than headquarters is.

In a SASE design, the SD-WAN device at the branch sends the request to the provider's nearest point of presence. Inspection happens there, and the request goes straight on to the app.

The second gain is policy. Palo Alto Networks says the approach "ensures consistent application of security policies across the enterprise and centralizes control" (Palo Alto Networks). The branch user and the same user working from home hit the same rules.

In our reading, the example points to a simple check: map where a provider's points of presence sit against your own branch and remote-worker locations before you count on the latency gain.

What is SSE, and how is it different from SASE?

Security service edge (SSE) is the security half of secure access service edge (SASE). Remove the networking layer from SASE, the software-defined wide area network (SD-WAN), and what remains is SSE. Fortinet's glossary reduces it to a formula: SD-WAN + SSE = SASE.

Every definition in this section comes from vendor material. The companies that sell these products also draw their boundaries. Read the categories as working labels, not standards. Our glossary covers related terms.

The usual parts

Palo Alto Networks says SSE consolidates ZTNA, cloud SWG, CASB, and FWaaS. Here is what each part does, as vendors describe it.

Where the definitions disagree

The lists do not match exactly. Fortinet dates Gartner's introduction of SSE to 2022, which differs from the date given earlier in this guide.

In our reading, gaps like these are a reason to get each vendor's component list in writing before comparing quotes.

The practical difference

Palo Alto Networks says SSE is not concerned with network optimization or routing. It works over the network you already have. Put simply, SSE changes how traffic is inspected. SASE also changes how that traffic travels.

Zscaler frames the creation of SSE as an admission that SASE represented too big of a change for organizations to take on all at once. LevelBlue's blog points SSE at firms that already have a solid networking foundation (like existing SD-WAN).

We think the choice often depends less on the acronym than on who owns the network contract today and when it renews. Check that date before a vendor briefing.

What is ZTNA, and where does it sit inside SSE?

Zero trust network access (ZTNA) is the part of the stack that decides who reaches which private application. Its job is narrow. A user asks for one app, the service checks who they are and what device they are on, and access is granted to that app alone.

Fortinet's glossary describes ZTNA as a service that provides secure remote access to specific services, applications, and data, with that access based on clearly defined access-control policies. The key word is specific. The grant is scoped to a resource, not to a network segment.

Identity and device first, location second

The same Fortinet page says SASE access is meant to be delivered based upon the identity of the user or device, real-time context and security/compliance policies, and lists among its core traits access based on who versus where. ZTNA is where that principle meets private applications. Being on the office network earns a user nothing by default.

In practice, a finance analyst on a managed laptop might reach the payroll app. The same analyst on an unmanaged home tablet might be refused, or be offered a narrower session. The decision is made per request, per app.

One component of SSE, not a rival term

ZTNA is not an alternative to security service edge (SSE) or SASE. It sits inside SSE as one of its primary parts, alongside the web and cloud-app controls covered in the previous section. In our reading, buying ZTNA on its own is a common first step, and in our reading that is part of why the three acronyms get treated as competing choices when they nest inside one another.

How it differs from a VPN

A virtual private network (VPN) typically puts the remote device on the corporate network, and the user can then try to reach whatever that network exposes. Zscaler contrasts this with older designs that require backhauling traffic to a central location and through a number of disjointed security appliances. It goes further and calls ZTNA "an upgrade and replacement for the entire inbound stack" rather than a different kind of VPN.

For a security leader, the practical check is simple. Pick three internal apps and ask your team whether a remote contractor could see them on the network today, before signing in to any of them. If the answer is yes, that is the exposure ZTNA is designed to remove. More terms are defined in the glossary.

How SASE, SSE and ZTNA relate to zero trust

Zero trust is a strategy, not a product. Secure access service edge (SASE), security service edge (SSE) and zero trust network access (ZTNA) are ways to deliver parts of that strategy. The Cybersecurity and Infrastructure Security Agency (CISA) offers a useful public reference for drawing that line.

CISA describes zero trust as a set of concepts aimed at "least privilege per-request access decisions" made "in the face of a network viewed as compromised" (CISA). Its stated goal is to make access control enforcement as granular as possible. CISA also says zero trust may require a change in an organization's philosophy and culture. We think that sentence matters most here, because no product ships a culture change.

The maturity model as a map

CISA's Zero Trust Maturity Model (ZTMM) has five pillars and three cross-cutting capabilities. It gives examples at four stages: traditional, initial, advanced and optimal. The pillars are identity, devices, network, data, and applications and workloads.

Mapping these products against the pillars shows how much they cover and where they stop.

The pattern is clear in our reading. These products are strongest where a user reaches an application. They are weaker on the pillars that live inside endpoints, code and data stores.

What to check before buying

Version 2.0 added a new maturity stage called "Initial" to help gauge maturity pillar by pillar. That gives a leader a practical method:

• Score each pillar at its current stage before talking to vendors.
• Ask each vendor which pillar functions its product moves forward, and by how many stages.
• Expect uneven results. A ZTNA rollout can advance the network pillar while identity stays traditional.

CISA calls its model one of many roadmaps, and other frameworks can do the same job. The point stands either way: the strategy sets the target, and products fill in pieces of it.

SASE, SSE, ZTNA and VPN compared side by side

The table puts the four terms side by side. Definitions come from vendor explainers. The ownership, replacement and fit columns are our reading.

In our reading, the vendors disagree on where the hybrid workforce sits. Palo Alto Networks places SSE with businesses prioritizing security for remote workforce without complex network management (source). Fortinet says SASE provides the hybrid workforce with consistent enterprise-grade cybersecurity (source). We think the deciding factor is the branch estate. With few sites, SSE alone may be enough.

A worked example: SD-WAN under contract until June

Take a hypothetical retailer whose SD-WAN contract runs until a June renewal. Zscaler describes SSE as a response to SASE being too big of a change for organizations to implement all at once (source). The sequence below follows that idea.

1. Read the SD-WAN contract and note the renewal notice period and any early-exit terms.
2. Buy SSE now for remote staff. It runs on the existing network, so the SD-WAN keeps routing.
3. Steer branch internet traffic from the SD-WAN edges to the SSE service, a few stores at a time.
4. Retire VPN access app by app, as the migration section described.
5. Before the notice date, write SASE requirements. Include the MPLS circuits you want to drop.
6. At renewal, choose between keeping the SD-WAN alongside the SSE or moving both to one provider.

Single vendor or several

• One policy model: can a single rule apply at the branch edge and for a remote user?
• Whether logs from both parts land in one place in the same format.
• Whether you can replace the SD-WAN or the SSE without rebuilding the other.
• Whether contract end dates line up, so the next decision is not forced early.
• Which team signs off on changes to each part.

How to move from VPN to ZTNA without breaking access

Our phasing below is our own view. It takes its yardstick from the CISA (Cybersecurity and Infrastructure Security Agency) Zero Trust Maturity Model (ZTMM) covered earlier, not from a vendor playbook.

The case for moving rests on the trust model. CISA describes the old way of validating a user as linear: "users would provide their credentials, the system would verify the user, and then the user was granted access and considered a trusted entity within the network." Zero trust instead runs on "a continuous cycle of credentialing, verifying, and authorizing a user’s identity." A virtual private network (VPN) login is the linear version. Zero trust network access (ZTNA) is meant to be the cycle.

Five steps

1. Inventory first. List every private app reached over the VPN, who uses it and how it authenticates. CISA says a typical federal plan "will assess an agency’s current cybersecurity state and plan for a fully implemented ZTA." In our reading, that order works outside government too. Build the list from VPN logs, not from memory. Logs surface the apps nobody mentions in interviews.
2. Pick a low-risk group. Choose users with few apps, managed devices and a patient manager. In our reading, an internal IT team is a common choice. Leave out finance at quarter close and anyone tied to legacy thick-client software.
3. Run ZTNA alongside the VPN. Keep both live during the pilot. LevelBlue, which sells these services, says Security Service Edge (SSE) can be "deployed rapidly as a cloud-delivered security layer over your existing systems." Treat that as a vendor claim to test in your own pilot.
4. Retire VPN access app by app. Once an app has run cleanly over ZTNA for an agreed period, remove its VPN route for the pilot group, then widen to the next group. Document a rollback path for each app. Switch off the VPN itself only when the inventory shows nothing left on it.
5. Score progress against the maturity stages. Rate each ZTMM pillar before the first wave and again after each one, so the board sees movement in stages rather than in licenses bought.

The trap to avoid is cutting the VPN on a calendar date instead of on the inventory. In our reading, a fixed deadline pushes teams to move apps they have not tested, and the first outage costs the program its sponsors.

For sequencing this work alongside other early priorities, see our first 90 days plan. Terms used here are defined in the glossary.

What to check before you buy SSE or SASE

Before you sign for Security Service Edge (SSE) or secure access service edge (SASE), run each proposal through the same questions. This checklist is our own view. It applies to any provider, and the order of rows is not a ranking or a priority.

Why data and logging carry weight

The Cybersecurity and Infrastructure Security Agency (CISA) describes zero trust as a shift from a location-centric model to a more data-centric approach. In our reading, that makes data protection the place to test hardest. Knowing where traffic is inspected tells you little about what happens to a file once it leaves.

The same CISA page says this approach provides the visibility needed to develop, enforce and evolve security policies. We think logs are where that visibility either exists or does not. Ask for raw events, not only dashboards.

Board and audit

In our reading, directors want to know what changed, not which product was bought. Keep the evidence plain: coverage of users and applications, open policy exceptions, and incidents the controls caught. Our glossary entry on board cybersecurity oversight covers the oversight role in more detail.

Federal buyers have a reference point. CISA says version 2.0 of its maturity model incorporates alignment to OMB M-22-09, the Office of Management and Budget memo published in January 2022. A provider can be asked to show which of its controls map to that memo.

Exit before entry

Exit terms are easiest to settle before signature. We think one export test belongs in every pilot: pull the policies and a week of logs, then check whether another tool can read them.

If a provider resists that test, note it. In our view, the answer tells you more about the contract than the sales deck does.

Who owns SASE when networking and security converge

SASE (secure access service edge) folds network transport and security policy into one service.

In our reading, the technology is rarely the source of friction. We think ownership disputes tend to start when the network team holds the SD-WAN (software-defined wide area network) contract, the security team writes the policy that runs over it, and neither signed off on the other's half.

Read the reporting line before you pick a model

Where the CISO sits shapes which model is realistic. A CISO who reports to the chief information officer (CIO) shares a manager with the network team, so a split model can be settled one level up. A CISO who reports to the CEO, legal or a risk function has more distance from networking. In our reading, that makes a security-led model easier to argue for, though escalations across the two teams take longer.

Our reporting lines report shows how these lines break down across the CISOs we track. Check where your own structure falls before you commit to a model. The CISO reporting structure guide and the CISO, CIO, CSO and CTO comparison cover the roles in more detail.

Name the owners in writing

CISA's maturity model is built for federal agencies under Executive Order 14028, which "requires that agencies develop a plan to implement a Zero Trust Architecture (ZTA)." The same document says all organizations should review and consider its approaches. In our reading, a plan with no named owner per decision tends to stall at the first outage.

Write down, before contract signature:

• who approves policy changes in the SSE layer
• who owns SD-WAN circuits and branch rollouts
• who holds the vendor contract and the renewal date
• who is paged when access fails, and who decides whether to fail open or closed
• who signs off on policy exceptions

We think a workable answer for most structures is security owns the access decision, networking owns the path. Security decides who may reach what. Networking keeps the path fast and available.

What this guide does not cover

This guide does not rank or recommend vendors, compare pricing, or test any product's performance. It also leaves out the zero trust areas that usually sit outside these products, such as endpoint management, secure development and data classification. Where it describes Cybersecurity and Infrastructure Security Agency (CISA) guidance or contract terms, it is not legal or financial advice.