Lesson 1.8.3 — Zero Trust and SASE/SSE

Domain 1.0 | Networking Concepts — 23% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Explain the Zero Trust security model and its core guiding principles
• Identify the three components of NIST’s Zero Trust Architecture and the role each plays
• Explain how ZTNA differs from traditional VPN access
• Explain SASE and the networking and security functions it converges into one cloud-delivered service
• Distinguish SSE from SASE and identify which scenario each fits

Key Terms

Explanation

This lesson closes out Module 1 by tying together a lot of what you’ve already learned. You’ve seen cloud deployment models, cloud connectivity options, SD-WAN and VXLAN, and security appliances as separate topics. Zero Trust and SASE are what happen when you smash all of that together into a single delivery model.

Why Perimeter Security Stopped Being Enough

Every network eventually runs into the same uncomfortable question: once someone is inside, why do we keep trusting them? For decades the honest answer was “because they got past the firewall, so they must be fine.” That assumption is exactly what Zero Trust throws out, and it’s why Zero Trust, SASE, and SSE now show up together on the N10-009 exam — they’re three pieces of the same architectural shift, not three unrelated buzzwords.

The old model — sometimes called “castle-and-moat” — put all the defenses at the network edge. Firewalls and VPN concentrators sat at the perimeter, and once traffic crossed that line, it was largely trusted by default. Three things broke that model at roughly the same time:

• Cloud adoption. Applications and data moved off-premises, so there was no longer a single perimeter to defend.
• Remote and hybrid work. The “inside” of the network stopped being a physical location.
• Lateral movement in breaches. Attackers who compromised one endpoint could move freely once inside, because internal traffic wasn’t scrutinized the way perimeter traffic was.

Zero Trust is the architectural response to all three.

Zero Trust: Core Concept and Principles

Zero Trust is a security model built on one governing idea: never trust, always verify. No user, device, or application is trusted by default, regardless of whether it’s sitting inside the traditional network boundary or connecting from the outside. Every access request gets evaluated on its own merits, every time.

A few principles do most of the work:

• Least privilege access. Users and devices get the minimum access required to do their job, nothing more.
• Microsegmentation. Instead of one flat internal network, resources are broken into small, isolated segments with policy enforced between them. If an attacker compromises one segment, they can’t simply walk into the next one.
• Continuous verification. Trust isn’t granted once at login and then assumed for the rest of the session. Identity, device posture, location, and behavior are checked continuously, and access can be revoked mid-session if something looks wrong.
• Assume breach. Zero Trust designs operate on the assumption that an attacker is already somewhere in the environment.

Zero Trust Architecture (ZTA) Components

NIST’s Zero Trust Architecture model (SP 800-207) breaks the enforcement logic into three logical pieces, and this is a mapping the exam likes to test:

[See Diagram: Zero Trust Access Flow]

How A Zero Trust Access Request Moves From PEP To PE To PA

Picture a remote employee trying to open an internal finance application. Instead of a VPN dropping them onto the internal LAN, the request hits a PEP, which forwards the context (who they are, what device they’re on, is the device patched, is MFA satisfied) to the Policy Engine. The PE checks that against policy, the PA instructs the PEP to allow or deny, and only the specific application session is granted — not broad network access. That last part is the key difference from a traditional VPN, and it’s the technology usually called ZTNA (Zero Trust Network Access).

ZTNA replaces the old “VPN drops you onto the network” model with “you get a broker-mediated tunnel to one specific application.” Even if a ZTNA-connected device is compromised, the blast radius is one application, not the whole subnet.

SASE: Secure Access Service Edge

SASE (pronounced “sassy”) is a term coined by Gartner in 2019 to describe the convergence of networking and security functions into a single, cloud-delivered service. The core insight behind SASE is that if users, apps, and data are all over the place — branch offices, home offices, multiple clouds — then routing everyone’s traffic back to a central data center just to inspect it is backwards. Inspection and policy enforcement should happen close to wherever the user actually is, at cloud points of presence distributed globally.

SASE bundles together capabilities that used to live in separate boxes:

• SD-WAN — intelligent, application-aware WAN routing
• SWG (Secure Web Gateway) — filters and inspects outbound web traffic
• CASB (Cloud Access Security Broker) — enforces policy on traffic to and from SaaS applications
• FWaaS (Firewall as a Service) — cloud-delivered next-gen firewall inspection
• ZTNA — the identity-and-context-driven access model described above

How SD-WAN, SWG, CASB, FWaaS, and ZTNA Converge At A SASE Point Of Presence

The whole point is that a branch office or a remote worker connects to the nearest SASE point of presence, and all of that security stack is applied consistently, without backhauling traffic to a central hub first. It’s the cloud-native evolution of the traffic management appliances covered earlier in this module — the functions haven’t changed much, but where and how they’re delivered has changed completely.

SSE: Security Service Edge

SSE (Security Service Edge) showed up a couple of years after SASE, largely because vendors and analysts noticed that a lot of organizations wanted the security half of SASE without necessarily replacing their existing WAN infrastructure. SSE is essentially SASE minus the networking (SD-WAN) piece — it’s the security-focused subset.

SSE typically includes:

• Secure Web Gateway (SWG)
• Cloud Access Security Broker (CASB)
• Zero Trust Network Access (ZTNA)
• Sometimes Firewall as a Service (FWaaS)

Think of it this way: SASE = SD-WAN + SSE. If a company already has a mature SD-WAN deployment and just wants to modernize its security stack, SSE lets them do that without ripping out the WAN layer. If they’re building both from scratch, or their WAN needs an overhaul anyway, full SASE makes more sense.

What SASE Includes That SSE Does Not — And Why That Difference Matters

A useful way to keep these straight for the exam: Zero Trust is the philosophy, ZTNA is one specific technology that implements it, and SASE/SSE are delivery architectures that package ZTNA alongside other services.

Where This Fits in Real Deployments

A mid-size company migrating off legacy MPLS and a stack of branch firewalls onto SASE typically keeps a lightweight SD-WAN device at each site for local breakout and WAN optimization, while all security inspection, CASB policy, and ZTNA brokering happens in the cloud provider’s global point-of-presence network. Users at headquarters, users at a branch office, and users working from a coffee shop all get identical policy enforcement, because the enforcement point isn’t tied to a physical location anymore — it follows the user through the cloud fabric. This ties directly into the cloud connectivity concepts from earlier in the module, and the shift away from fixed physical enforcement points echoes the modern network architectures lesson as well.

This wraps up Module 1 — Networking Concepts. Next up is Module 2, Network Implementation, starting with routing fundamentals.

Recognition-Level Verification Concepts

A few patterns are worth recognizing on sight:

• A session that gets re-evaluated and revoked mid-stream because device posture changed, rather than only checked at login, is continuous verification in action.
• An access log showing a broker-mediated tunnel scoped to one specific application, rather than a full network-level connection, points to ZTNA.
• Traffic inspected at a nearby cloud point of presence instead of backhauled to a central data center is the signature of SASE.
• An organization keeping its existing SD-WAN while adding cloud-delivered SWG, CASB, and ZTNA is adopting SSE, not full SASE.

Common Exam Traps

• Zero Trust is a philosophy, not a specific product. ZTNA is the technology that implements it for application access — don’t treat the two terms as interchangeable.
• SASE = SD-WAN + SSE. This is the single most tested relationship in this lesson — know it cold.
• The three ZTA components have distinct jobs: the Policy Engine decides, the Policy Administrator executes (issues/revokes credentials), and the Policy Enforcement Point sits in the actual data path. Mixing up which one issues the session token is a common trap.
• Continuous verification means trust can be revoked mid-session — it is not a one-time check performed only at login.
• SASE applies inspection near the user at a cloud point of presence, rather than backhauling traffic to a central site — this is the core reason SASE exists in the first place.