Zero Trust, SASE, and SSE Concepts
Key Takeaways
- Zero trust removes implicit trust based on network location; access is explicit, contextual, and continuously evaluated.
- Core zero trust ideas are least privilege, strong identity, device posture, microsegmentation, continuous monitoring, and policy enforcement.
- Zero trust separates the control plane (policy decision point) from the data plane (policy enforcement point).
- SASE bundles networking and security; SSE is the security-only subset and commonly includes SWG, CASB, ZTNA, and DLP.
- When a scenario needs least-privilege remote access to one private app, ZTNA usually beats a full-tunnel VPN.
Zero Trust Is an Approach, Not a Product
Zero trust is an architecture philosophy that removes implicit trust derived from network location. No request is trusted simply because it originated inside the corporate LAN. Instead, every access decision is made explicitly from identity, device posture, the application requested, data sensitivity, context, and risk. CompTIA aligns its zero-trust language with NIST SP 800-207, so the exam expects the formal building blocks below.
Zero Trust Principles
| Principle | Meaning | Example |
|---|---|---|
| Verify explicitly | Authenticate and authorize every request | MFA plus a device-compliance check |
| Least privilege | Grant only what the task needs | A user reaches one app, not a whole subnet |
| Assume breach | Limit blast radius and monitor constantly | Microsegmentation plus EDR telemetry |
| Continuous evaluation | Access can change as risk changes | Session blocked the moment a device falls out of compliance |
| Strong identity | Users and workloads are provably known | SSO, federation, service identity, certificate auth |
Control Plane and Data Plane
NIST splits zero trust into two cooperating engines. The Policy Decision Point (PDP) lives in the control plane and decides whether to allow a request; it is made of a Policy Engine that evaluates rules and a Policy Administrator that issues the verdict. The Policy Enforcement Point (PEP) lives in the data plane and physically allows, blocks, challenges, throttles, or logs the session. Knowing PDP versus PEP is a frequent SY0-701 distractor.
A PDP may weigh: user identity and group, device health (encryption, EDR, patch level), location and impossible-travel signals, the application requested, data classification, session risk score, authentication strength, and time-of-day or behavior patterns.
ZTNA Versus Traditional VPN
| Feature | Remote-access VPN | ZTNA |
|---|---|---|
| Access model | Often network-level | Application-specific |
| Trust basis | Authenticated user joins the network path | Identity, device, and policy per app |
| Blast radius | Can expose many internal services if poorly scoped | Limits the user to approved applications |
| Best fit | Admin networks, legacy protocols, site-to-site | Remote workforce reaching specific apps |
Exam trap: VPN is not always wrong. But when the requirement is least-privilege remote access to a specific private application, Zero Trust Network Access (ZTNA) is the stronger answer because it never drops the user onto a flat internal network.
SASE and SSE Components
Secure Access Service Edge (SASE) converges wide-area networking and cloud-delivered security into one service. Security Service Edge (SSE) is the security-only subset, dropping the SD-WAN transport piece.
| Component | Belongs to | Purpose |
|---|---|---|
| SD-WAN | SASE only | Intelligent traffic routing across WAN links |
| Secure Web Gateway (SWG) | SASE / SSE | URL filtering, web and malware controls |
| Cloud Access Security Broker (CASB) | SASE / SSE | Visibility and policy for sanctioned and shadow SaaS |
| Zero Trust Network Access (ZTNA) | SASE / SSE | App-specific private access |
| Firewall as a Service (FWaaS) | SASE / SSE | Cloud-delivered firewall policy |
| Data Loss Prevention (DLP) | SASE / SSE | Detect and restrict sensitive-data movement |
The quick mnemonic: SSE = SWG + CASB + ZTNA (+ FWaaS/DLP); SASE = SSE + SD-WAN. If the answer choice includes SD-WAN, it is describing SASE, not SSE.
PBQ-Style Scenario
A company has remote employees, unsanctioned SaaS usage, and private internal apps. Today everyone uses a full-tunnel VPN, then browses to SaaS and internal systems. The team wants app-level access, SaaS visibility, and consistent web filtering. A defensible target design:
- Federate identity through the IdP with MFA.
- Use ZTNA for private apps so users get only their approved applications.
- Use CASB to discover and govern SaaS, including shadow IT.
- Use SWG for web filtering and malware inspection.
- Require device-posture checks before sensitive access.
- Stream policy and access logs to centralized monitoring.
Wrong direction: "Place every user on the internal network and trust them after login." That keeps the obsolete perimeter model and breaks least privilege.
Design Review Checklist
- Is access based on identity and context, not subnet alone?
- Are users restricted to required applications only?
- Are devices health-checked before sensitive access?
- Is sensitive data protected across SaaS and web channels?
- Are policy decisions logged at the PEP?
- Are exceptions documented and time-bound?
Zero-trust questions reward the option that narrows access while increasing verification and visibility.
Microsegmentation and the Implicit Trust Zone
A central NIST SP 800-207 idea the exam tests is the implicit trust zone behind a PEP: once a request is authorized, the area it can reach should be as small as possible. Microsegmentation shrinks that zone to a single workload or even a single service, so a compromised host cannot move laterally to its neighbors. Compare three granularities:
- Subnet segmentation isolates broad groups of hosts; lateral movement within the subnet is still possible.
- VLAN or security-group segmentation tightens that to functional tiers, such as web versus database.
- Microsegmentation applies identity-aware policy down to the individual workload, the smallest practical blast radius.
Two more tested distinctions: the agent-based ZTNA model installs a connector on the device and is best for managed endpoints, while the service-based (clientless) model brokers access through a portal and suits unmanaged or third-party devices. And remember that zero trust is a journey, not a switch; organizations typically start by federating identity and adding MFA, then layer device posture, microsegmentation, and continuous evaluation over time. An exam answer that demands ripping out every existing control overnight is almost always wrong.
A remote employee needs access to one internal HR application but should not receive broad access to the internal network. Which technology best fits?
Which services are commonly part of Security Service Edge? Choose three.
Select all that apply
Which statement best describes zero trust?