Zero trust: subjects, objects, and the decision in between

Why this matters

This lesson closes domain 2 and is its capstone: every preceding objective contributes something zero trust needs. Attestation supplies trustworthy device identity. Data perimeters supply the resource boundary. Segmentation supplies the containment underneath. Federation and workload identity supply the subject. Continuous authorization supplies the idea that a decision expires.

CompTIA's published bullet for the objective is one line — "Zero trust concepts: defining subject-object relationships" — and that phrasing is unusually precise. Zero trust is not a product, a network design, or the absence of trust. It is a model in which a subject's access to an object is decided per request against current evidence, and the architectural work is defining what the subjects are, what the objects are, and what the decision consults.

The exam tests whether you can distinguish the model from its marketing, place the decision and enforcement points correctly, and describe an adoption that is a programme with stages rather than a purchase.

The lesson

The subject-object relationship as the unit zero trust actually governs

The model's unit is a triple: a subject, an object, and an action, evaluated in a context.

A subject is whatever requests access: a user, a device, a workload, a service, an automation identity. Two properties matter. A subject must have an identity that can be verified rather than asserted — which is why lesson twenty-two's attestation and lesson nineteen's workload identity are preconditions. And a subject is frequently a composite: a particular user on a particular device, and both halves carry evidence.

An object is what is being accessed: an application, an API, a dataset, a record, an administrative function. The granularity of objects determines the granularity of policy, and this is where most implementations stop too early. An object defined as "the finance application" permits a policy no more precise than the network rule it replaced. Objects defined as its administrative functions, its reporting interface and its bulk export capability permit policies that mean something.

The action matters because read, write, delete and export warrant different decisions on the same object. Bulk export is the canonical example: a subject entitled to read individual records may not be entitled to extract all of them, and a model that does not separate the actions cannot express that.

So the architectural deliverable of a zero trust programme is an inventory of subject-object-action relationships with a policy for each — which is a large piece of work and is the honest reason adoption takes years. It is also why the programme begins with the inventory from lesson five and the classification from lesson seven: you cannot write policy about objects you have not enumerated or classified.

The contrast to hold: perimeter models govern paths — this network may reach that network. Zero trust governs relationships — this subject may perform this action on this object, now, given this evidence.

Policy decision point and policy enforcement point, and where each can live

The mechanism has two named components and the separation between them is the most examinable structural fact in the objective.

The policy decision point evaluates the request against policy and the available signals, and returns a decision. It is logically central, so that policy is authored and reasoned about in one place.

The policy enforcement point sits in the path of the request and applies that decision — permitting, denying, or permitting with conditions. It is necessarily distributed, because it must be wherever requests happen.

Enforcement points in a real estate include an identity-aware proxy in front of applications, the application itself where it is capable, an API gateway, a service mesh sidecar from lesson twenty, a cloud platform's own authorisation layer, and an agent on the endpoint.

Three consequences follow:

• Policy is written once and enforced many times, which is what makes the model coherent across a heterogeneous estate. An estate with five enforcement points and five policy sources has five policies, and the gaps between them are where access is actually granted.
• Every path to an object must pass an enforcement point, or the object is reachable by a route that consults no policy. This is the same "weakest path" observation as lesson twenty-three's zone egress, and it is the commonest practical failure — the application protected by a proxy that is also reachable directly on its own address.
• The decision point's availability is critical, and its failure mode must be decided deliberately. Fail-closed is secure and turns a decision-point outage into a total outage; fail-open preserves availability and removes the control at the moment it may be under attack. Caching decisions for a short bounded period is the usual compromise, and the length of that period is a security parameter worth stating.

Signals that feed a decision: identity, device, behaviour, location, sensitivity

The decision point's quality is the quality of its signals, and the useful ones group into five families.

• Identity. Who the subject is, how strongly they authenticated, what groups and entitlements they hold, whether the credential shows signs of compromise, and how recently authentication occurred.
• Device. The posture evidence from lesson twenty-two — attested boot state, management enrolment, patch level, encryption, protection status — with its forgeability ordering intact. Hardware-rooted device identity is the strongest single signal available.
• Behaviour. Whether this request is consistent with this subject's history: the resources normally accessed, the volume, the time, the pattern. This is the domain 4 baselining material consumed as an authorisation input, and it is what catches a valid credential in the wrong hands.
• Context. Network location, geography, impossible travel, time of day. Weak signals individually — location is easily manipulated — and useful in combination.
• Object sensitivity. The classification of what is being requested, which determines how much evidence is required. This is the signal that makes the model proportionate rather than uniformly obstructive.

The decision is then a function of all of these, and its outputs should be richer than allow or deny: permit, permit with conditions (require step-up authentication, restrict to read-only, prohibit download, limit volume), permit with elevated monitoring, or deny. The conditional outcomes are what make zero trust usable, because a binary model on real signals produces either constant friction or permissive policy.

Two cautions worth carrying. Signal quality varies enormously and a policy weighting a forgeable signal heavily is worse than one ignoring it, because it produces confidence rather than caution. And every signal is a dependency: if the device posture service is unavailable, the decision point must have a defined behaviour, and "treat missing evidence as satisfactory" is the failure mode that quietly disables the model.

Per-request evaluation versus session-scoped trust, and the cost of each

The purest form of the model evaluates every request. Reality requires compromise, and understanding the trade is the practical skill.

Per-request evaluation re-runs the decision for each access. Strongest — revocation is immediate, a change in posture takes effect at once, and a stolen session is useful only until the next evaluation. Costs: latency on every request, load on the decision point, and an outsized dependency on its availability.

Session-scoped trust decides once and issues a token valid for a period. Cheap and fast, and it reintroduces exactly the weakness zero trust exists to remove — a decision made on evidence that has since changed. A device that fails posture five minutes after authenticating retains access until its token expires.

The practical architecture, and the one scenarios reward, is short-lived tokens with continuous evaluation: sessions measured in minutes to an hour rather than days, re-evaluation triggered by signal changes as well as by the clock, and the ability to revoke an existing session rather than only to refuse a new one. That last capability is the one most implementations lack and the one that matters during an incident.

Risk-adaptive scoping completes it: token lifetime and evaluation frequency vary by object sensitivity. Routine access to low-sensitivity resources gets a longer session; administrative action on restricted data gets per-request evaluation with step-up authentication. That is the same proportionality principle lesson eighteen applied to control strategies, and it is what keeps the model affordable in both latency and friction.

Zero trust as an architecture programme with stages, not a product to purchase

The closing point of the domain, and the one CAS-005 tests most reliably, because the marketing version is pervasive.

No product implements zero trust. Products implement enforcement points, decision points, identity, posture and telemetry — all necessary, none sufficient. What makes an estate zero trust is the policy governing subject-object relationships and the evidence feeding it, and those are yours to define.

A defensible programme sequence, each stage delivering value alone:

1. Identity first. One identity provider, strong authentication everywhere, privileged accounts separated, joiners-movers-leavers working. Without this nothing above it is meaningful, and most of the benefit of the whole programme is available here.
2. Device identity and posture. Attested identity where the hardware allows it, enrolment and compliance everywhere else, and posture available as a signal.
3. Enumerate and classify objects. The applications, APIs and datasets, with sensitivity and owners — lessons five and seven, consumed here.
4. Enforce per-application access for the highest-value objects first, replacing network access with brokered, policy-evaluated access.
5. Add contextual and behavioural signals, and conditional outcomes.
6. Shrink the network's role, retiring broad VPN reach as applications move behind enforcement points — and keeping it for the legacy tail, deliberately and with a documented plan, rather than pretending it is gone.
7. Extend to workloads, applying the same model to service-to-service access with workload identity and mesh enforcement.

Two properties of that list are the examinable part. It is ordered by dependency, so attempting stage four without stage one produces enforcement points making decisions on evidence that does not exist. And every stage is useful on its own, which is what allows a multi-year programme to survive changing priorities — a design requiring completion before delivering value will not be completed.

The honest closing statement, and the one worth carrying into domain 3: zero trust does not remove the need for segmentation, encryption, monitoring or patching. It changes the basis of access decisions from network position to evidence, and everything else in this course still has to be there underneath it.