Security+ 801 Countdown, T-21: Zero Trust Drops the NIST Plane Vocabulary

Zero trust is a security model in which no request for access is trusted because of where it comes from. A user on the office network, a laptop with an internal IP address, and a service running in the data center all start from zero: each request must be authenticated, authorized, and checked against policy before it is granted, and the grant lasts only as long as the policy keeps holding. NIST SP 800-207, the reference document for the model, frames zero trust as “least privilege per-request access decisions” on a network “viewed as compromised” (NIST 2020). The model exists because the perimeter model made the opposite assumption: whatever reached the inside of the network was treated as trustworthy, so a phished password or an infected laptop inherited the trust of the whole segment it landed on.

SY0-801 places “Zero Trust principles” under Defense in depth in objective 1.1 and adds a new “Zero Trust architecture” bullet to objective 3.2 with three sub-bullets, User authentication, Device management (Health, Inventory), and Application access control (CompTIA 2025). Because 3.2 is a “Given a scenario” objective, expect stems that describe a user, a device, and an application and ask which control enforces zero trust. This post works from the principles to the reference architecture that implements them, then to the three sub-bullets, and finally to a real policy engine and its logs, because the exam will test the mechanism rather than the slogan.

The principles: seven tenets and the slogans around them

CompTIA does not define “Zero Trust principles,” so the standard to learn is NIST SP 800-207 (August 2020), which lists seven tenets (NIST 2020):

1. Every data source and computing service is a resource.
2. All communication is secured regardless of network location.
3. Access is granted per session.
4. Access is set by dynamic policy, including the asset’s observable state.
5. The enterprise monitors the posture of every asset it owns or uses.
6. Authentication and authorization are dynamic and enforced before access.
7. The enterprise collects data to improve its posture.

Read together, the tenets describe a loop rather than a checklist. A resource (tenet 1) is anything worth protecting, so a file share and a payroll database are subject to the same per-request decision. Communication to a resource is secured no matter where it starts (tenet 2), so an internal address earns nothing. The grant is scoped to one session (tenet 3) and computed from a policy that includes the current state of the requesting device (tenet 4), which is only possible if the enterprise watches device posture continuously (tenet 5) and performs authentication and authorization before each access rather than once at login (tenet 6). The telemetry all of this produces feeds back into policy (tenet 7).

“Never trust, always verify” and “assume breach” are industry shorthand rather than defined terms in 800-207, the CISA maturity model, or OMB M-22-09, but the ideas behind them are standard: 800-207 assumes a network “viewed as compromised,” and M-22-09 calls “assuming that any component can be compromised” “a key zero trust principle” (OMB 2022). Tenet 2 carries most of the weight in practice. 800-207 does accept an implicit trust zone behind each gateway, the region in which a subject that has passed one enforcement point is trusted to the level of that gateway (its example is an airport boarding area past screening), but it says the zone “must be as small as possible.” Because the SY0-801 objectives nest the principles under Defense in depth, treat zero trust as a property of each layer rather than a replacement for layering; the layers themselves are covered at T-36.

The reference architecture: who decides, who executes, who enforces

In 800-207 the requester is a subject: the user, the application or service acting for the user, and the device it runs on, evaluated together. The thing requested is a resource. Between them sits the policy decision point (PDP), which has two halves. The policy engine (PE) “makes and logs the decision,” running a trust algorithm over the request, the subject and asset databases (including each device’s observable status), and threat intelligence. The policy administrator (PA) executes that decision, opening or shutting the path and issuing any session token. In front of the resource sits the policy enforcement point (PEP): the PA configures the PEP over the control plane, application traffic then flows encrypted on the data plane, and the PEP monitors the connection until the PA tears it down on time-out, failed reauthentication, or a security event.

The two planes are the architecture’s way of keeping decision traffic apart from application traffic. The control plane is the channel between the PA and the PEP; the data plane is the path the application’s packets take once the PEP opens it. Two cautions. The zero trust planes are not the planes of software-defined networking, where a controller programs forwarding; here the control plane carries access decisions, not routes. And the PE and PA, not the PE and PEP, make up the PDP; the PEP is the component the PDP steers.

The SY0-801 objectives do not use these component names, but the three sub-bullets under Zero Trust architecture describe the inputs and outputs of exactly this loop: user authentication and device state are what the policy engine evaluates, and application access control is what the PA and PEP produce.

User, device, and application: the three sub-bullets

Each sub-bullet names one input to, or one output from, the decision. User authentication is proof of the identity behind the request; in a zero trust design it is strong, contextual (user risk, location, device), and re-evaluated during the session rather than settled once at login. Device management has the two halves the objective names in parentheses: Inventory asks whether the device is known and enrolled, and Health asks whether it meets policy right now. The two are independent, so a device can be managed and noncompliant at the same time. Application access control is the grant itself: access to one application through a proxy or gateway, as opposed to access to a network.

CompTIA never says “pillar,” but CISA’s Zero Trust Maturity Model Version 2.0 (April 2023) is the clearest map of this territory. It has five pillars, Identity, Devices, Networks, Applications and Workloads, and Data, plus three cross-cutting capabilities and four maturity stages (CISA 2023). The three SY0-801 sub-bullets line up with three pillars: User authentication is Identity, Device management is Devices, and Application access control is Applications and Workloads. Networks and Data are handled by SY0-801 objectives 3.1 and 3.3. CISA’s landing page now marks ZTMM “Archived Content,” so treat it as a reference model rather than current direction.

Stage	Identity: authentication	Devices: compliance	Applications: access
Traditional	Passwords or MFA, static access	Little or no visibility	Local authorization, static attributes
Initial	MFA plus locale or activity checks	Self-reported characteristics	Per-request context with expiration
Advanced	Phishing-resistant MFA begins	Verified insights at first access	Automated decisions, enforced expiration
Optimal	Continuous phishing-resistant validation	Continuous, for the device’s lifetime	Continuous, on real-time risk

Health is the Devices column of that table. Inventory matches ZTMM’s Asset and Supply Chain Risk Management function, and it is the precondition for Health, because an enterprise cannot check the compliance of a device it does not know it owns. OMB Memorandum M-22-09 (January 26, 2022), with goals due by the end of FY 2024, turned the same three columns into federal requirements: phishing-resistant MFA for staff, contractors, and partners; a “complete inventory of every device” plus EDR; and “at least one device-level signal alongside identity information” (OMB 2022). Its rule for applications is the one-line summary of the third sub-bullet: “Users should log into applications, rather than networks.” MFA mechanisms themselves are covered at T-11.

Conditional Access as a working policy engine

Microsoft calls Entra Conditional Access “Microsoft’s Zero Trust policy engine” (Microsoft 2026), and it is the most common place a candidate will see the three sub-bullets expressed as configuration. A Conditional Access policy has three parts: the users and applications it applies to, the conditions under which it fires (such as a user risk level), and the grant or session controls it imposes. Below are four policies as plain logic, in real Graph and Entra vocabulary with illustrative group and app names.

CA01  Block high-risk users
  users:      All users          exclude: break-glass accounts
  apps:       All resources
  condition:  userRiskLevels = high
  grant:      block

CA02  Employees need an enrolled, healthy device
  users:      grp-employees      exclude: break-glass accounts
  apps:       All resources
  grant:      mfa AND compliantDevice

CA03  Contractors reach exactly one app
  users:      grp-contractors-acme
  apps:       All resources      exclude: Payroll Portal
  grant:      block

CA04  Contractor access to Payroll Portal
  users:      grp-contractors-acme
  apps:       Payroll Portal
  grant:      authentication strength = Phishing-resistant MFA
  session:    signInFrequency 4 hours

Policies run after first-factor authentication, every matching policy must pass, and a matching block ends evaluation. So a high-risk contractor stops at CA01 no matter what CA04 would allow, and a contractor opening any app other than the Payroll Portal hits CA03. Mapped to the objective, CA01 and CA04 are User authentication, CA02 is Device management, and CA03 with CA04 is Application access control. Two traps matter here. One policy cannot combine “Require multifactor authentication” with “Require authentication strength,” which is why CA04 uses the strength control alone. And the device platform condition comes from “user agent strings that can be changed,” so it is a convenience filter and never a health signal. Start new policies in report-only mode (enabledForReportingButNotEnforced) so the sign-in logs show what would have happened before anyone is locked out.

When CA02 fails, the Graph sign-in record shows which half of Device management broke (trimmed; real field names, illustrative values):

{
  "userPrincipalName": "r.alvarez@example.com",
  "appDisplayName": "Payroll Portal",
  "conditionalAccessStatus": "failure",
  "status": { "errorCode": 53000 },
  "deviceDetail": { "isManaged": true, "isCompliant": false },
  "appliedConditionalAccessPolicies": [
    { "displayName": "CA02 Employees need an enrolled, healthy device", "result": "failure" },
    { "displayName": "CA01 Block high-risk users", "result": "notApplied" }
  ]
}

isManaged true with isCompliant false means the laptop passed Inventory (it is known and enrolled) and failed Health; error code 53000 is AADSTS53000, DeviceNotCompliant. What Health means in practice is whatever the Intune compliance policy says it means: settings such as Require BitLocker, Require Secure Boot, a minimum OS build (the patch floor), and a ceiling on the Defender for Endpoint machine risk score. In 800-207 terms, Conditional Access is the policy engine, Intune compliance is one of its data sources, and the token or proxy session it issues is the PA and PEP outcome.

Three scenarios to rehearse

A contractor who needs one application

The classic choice is between a remote-access VPN and per-app access through a PEP, such as an identity-aware proxy (a reverse proxy that authenticates the user and evaluates policy before forwarding each request to the application behind it) or 800-207’s resource portal:

Question	Remote-access VPN	Per-app access
What the contractor gets	An internal address and routes to 198.51.100.0/24	An HTTPS session to one app
Reconnaissance	Anything routable can be scanned	Resources “may not even be discoverable” without the PEP
Device check	Usually once, at tunnel setup	Per request; continuous only with an agent
After a phish	Lateral movement as far as ACLs allow	Every other app still denied

VPN stays in SY0-801 3.2 under Secure communication/access, so it is not wrong by default; it is wrong when the stem says “only one application” or “without placing the device on the network.” SSE and ZTNA products are covered at T-20.

An unhealthy device during a session

The sign-in record above is the per-request version of the check. NIST SP 1800-35 (June 2025) goes further: in scenario F-4, compliance fails during an active session and access is terminated; in F-5, the remediated device’s new request is granted (NIST 2025). That pair is tenets 3 through 6 running as designed, with the PA tearing down a session it had already approved. NAC posture checks gate network admission at connect time (covered at T-14); this gate sits on every application request and keeps running after the first grant.

Replacing the VPN

Centralize identity, require phishing-resistant MFA at the application layer, add a device signal, publish each app behind a PEP, and retire network-level trust. M-22-09 required this within one year for at least one authenticated FISMA Moderate system not yet internet-accessible, which is the right scale to think in: 800-207 says wholesale technology replacement cannot achieve zero trust, so the migration happens one application at a time.

What you need to know for SY0-801

• Principles (1.1): no implicit trust from location, per-request decisions, bounded sessions, dynamic policy, and continuous monitoring; 800-207’s tenets are the reference, and the slogans are accurate shorthand for them, so do not reject an option just because it uses one.
• User authentication: strong, contextual (user risk, location, device), and re-evaluated during the session.
• Device management: Inventory asks whether a device is known and enrolled; Health asks whether it meets policy right now. Managed and noncompliant is possible.
• Application access control grants one application through a proxy or gateway; a VPN grants a network.
• The PE decides, the PA executes, and the PEP enforces; PE plus PA is the PDP. SY0-701 named these components and SY0-801 does not, but the mechanism is what the three sub-bullets test.
• Cues: “only the billing app” means per-app access; “missing patches or disk encryption” means deny until remediation; “phished password on the attacker’s laptop” means phishing-resistant MFA plus a compliant device.
• Distractors: platform filters (spoofable), 802.1X for an app-access question, and “buy a ZTNA product,” which 800-207 says wholesale technology replacement cannot achieve.

Check yourself

These are original practice questions, not exam items.

1. A hospital’s outside billing firm needs the claims web application and nothing else. Security wants no internal IP addresses on the firm’s laptops and a fresh access decision on every request. Which approach best meets these requirements?

• A. A remote-access VPN with an ACL that limits the firm to the claims server’s subnet.
• B. The claims app published behind an identity-aware proxy that requires phishing-resistant MFA and evaluates each request.
• C. A guest VLAN with a captive portal for the firm’s laptops.
• D. A shared service account restricted to the claims application.

Answer: B. The proxy is a PEP that grants one application, per request, without network placement. The VPN and guest VLAN both put laptops on an internal network, and a shared account destroys accountability.

2. An analyst reviews a failed sign-in: conditionalAccessStatus is failure, errorCode is 53000, isManaged is true, and isCompliant is false. Which SY0-801 Zero Trust architecture item failed?

• A. Inventory, because the device is not enrolled.
• B. Health, because the enrolled device no longer meets compliance policy.
• C. User authentication, because MFA was not completed.
• D. Application access control, because the user is not assigned to the app.

Answer: B. isManaged true means the device is known and enrolled, so Inventory passed; isCompliant false with AADSTS53000 is a failed compliance check. A missing MFA step returns a different code, such as AADSTS50076.

3. An attacker phishes an employee’s password, tricks the employee into approving a push prompt, and signs in from a personal Windows laptop that was never enrolled in MDM. Which Conditional Access control would have blocked that sign-in?

• A. A device platform condition that allows only Windows.
• B. A grant control that requires a compliant device.
• C. A sign-in frequency of four hours.
• D. A password rotation requirement every 90 days.

Answer: B. An unenrolled laptop cannot be compliant, so the grant fails despite the stolen credentials. The platform condition reads a spoofable user agent and would pass a Windows laptop anyway; sign-in frequency only forces a reauthentication the attacker can complete.

This is T-21 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-20: SSE Replaces SASE as Secure Access Is Rebuilt. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

CISA (Cybersecurity and Infrastructure Security Agency). 2023. Zero Trust Maturity Model. Version 2.0. See also the landing page, now marked “Archived Content.” Accessed October 12, 2026.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

Microsoft. 2026. “What Is Conditional Access?.” Microsoft Learn. Last updated April 27, 2026. See also “Build a Conditional Access Policy,” “Conditional Access Authentication Strengths,” “Device Compliance Settings for Windows in Intune,” “Microsoft Entra Authentication and Authorization Error Codes,” and the Microsoft Graph grant controls and signIn references. Accessed October 12, 2026.

NIST (National Institute of Standards and Technology). 2020. Zero Trust Architecture. By Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly. NIST Special Publication 800-207.

NIST (National Institute of Standards and Technology). 2025. Implementing a Zero Trust Architecture: High-Level Document. NIST Special Publication 1800-35.

OMB (Office of Management and Budget). 2022. Moving the U.S. Government Toward Zero Trust Cybersecurity Principles. Memorandum M-22-09.