Zero Trust Architecture: Identity, Device Health, and Application Access(OBJ.3.2)

A finance analyst opens the expense application at 8:05 on a Tuesday. In the half second before the page loads, the identity provider has confirmed her passkey, the device management service has confirmed that her laptop is a company asset with current patches and a running EDR agent, and a gateway has opened a connection to that one application and nothing else. If any of those answers had come back differently, she would have seen a block page or a read-only view instead.

The Zero Trust principles lesson explained why network location stopped earning trust. This lesson covers the machinery that replaces it. On the CompTIA Security+ SY0-801 exam, Zero Trust architecture sits under objective 3.2, which gives you scenarios and expects you to manage a security architecture that protects the infrastructure. You'll see how a request flows through decision and enforcement points, what user authentication, device management and application access control each contribute, how conditional access policies combine them, and how microsegmentation applies the same thinking between servers.

Every request passes an enforcement point that asks a decision point for an answer

A Zero Trust architecture splits access into two jobs. A policy decision point evaluates each request against policy and returns an answer. A policy enforcement point sits in the path between the requester and the resource and carries that answer out: it opens the connection, limits it or refuses it. The resource is never reachable except through an enforcement point.

A request moves through the design in a fixed sequence:

1. A user on a device asks for a resource. The request reaches an enforcement point first, which might be an access proxy, a gateway, an agent on the endpoint or the application's own sign-in page.
2. The enforcement point passes the request's details to the decision point.
3. The decision point gathers signals: the identity provider reports who the user is and how strongly they authenticated, device management and EDR report whether the device is known and healthy, risk analytics report anything unusual, and the policy for that resource says what it requires.
4. It returns allow, deny or allow with conditions, such as step-up MFA or read-only access.
5. The enforcement point applies the answer and keeps reporting, so the decision can be revisited if a signal changes.

Here is that flow in a gateway's log:

09:12:41 pep=access-proxy-02 subject=akhan@corp.example device=LT-2291 resource=expense-app
09:12:41 pdp signals: auth=passkey mfa_age=3m inventory=enrolled compliance=compliant edr_risk=low
09:12:41 pdp decision=ALLOW session_ttl=8h conditions=none
09:12:42 pep session-open subject=akhan resource=expense-app:443

NIST SP 800-207 describes the same design with finer-grained names. A policy engine makes the decision, a policy administrator carries it out by setting up or tearing down the session, and the two together form the policy decision point. NIST also separates a control plane, where decisions are made, from a data plane, where application traffic flows. An attacker who compromises a laptop is on the data plane and should have no path to change policy. The SY0-801 objectives don't list those labels; what you need is to recognize the flow when a scenario describes it.

Notice where implicit trust remains: only in the short hop between the enforcement point and the resource. That is why enforcement points are placed as close to resources as possible.

User authentication is the first signal, and its strength counts

Every decision starts with identity, so the identity provider (IdP) is part of the architecture, not a side system. Users authenticate to the IdP, and applications trust its signed tokens through single sign-on. That centralization is what lets one policy cover hundreds of applications. It also makes the IdP a top target that needs its own hardening; federation protocols are covered in the identity and access management section.

Zero Trust treats how a user authenticated as a signal, not just whether they did. A password alone proves little, because passwords are phished and reused. A one-time code or a push approval is stronger, but a phishing proxy can relay the code, and a tired user can approve a push they didn't start. Phishing-resistant methods, such as FIDO2 security keys, passkeys and certificate-based smart cards, bind the login to the real site and resist both. A policy can therefore accept any MFA for the cafeteria menu but require a phishing-resistant method, used within the last hour, for the payroll administration console.

Authentication covers non-human identities too. Services, scripts and workloads authenticate with certificates, managed identities or short-lived tokens, and the decision point evaluates their requests the same way. Service accounts are covered later in this section.

Sessions don't last forever. Access tokens typically expire within about an hour, and sign-in frequency rules force a fresh authentication for sensitive applications. A token stolen from a browser is worth far less when it expires quickly and when the decision point also checks that it is still being used from the same healthy device.