What does a device-compliance claim carried into an access decision assert, and what does it never assert?

## What the claim is made of When an access decision includes 'device is compliant', that phrase is the compressed output of a checklist evaluated somewhere else, at some earlier moment, and carried into the decision as an assertion. Typical contents: the operating system build and patch level, whether full-disk encryption is on, whether the device is enrolled in management, whether a security agent is installed and reporting, whether a screen lock and a firewall are enforced, sometimes whether the device holds a certificate issued to it. Every item on that list is a **property of the machine's configuration**. That is worth stating flatly, because the word 'compliant' does a lot of quiet work in conversation and people hear it as 'clean' or 'safe'. ## The two things it cannot say **It cannot say the device is uncompromised.** A machine can be perfectly patched, fully encrypted, correctly enrolled and reporting healthily while an adversary is operating on it. Nothing on the checklist is a statement about who is currently driving the session; the checks are about state, and the state is genuinely good. This is why 'compliant but compromised' is a phrase worth having: it names the case where the control did its job and the outcome is still bad. **It cannot say the state still holds right now.** The claim was computed at an evaluation moment and then carried. Depending on the design that might be seconds ago or hours ago - a claim minted at sign-in and valid for the life of a token is common, and it means the decision engine is honouring an answer about a machine that may have changed since. In interviews this is the mechanic people most often skip: they describe posture as if it were re-measured synchronously on every request, and usually it is not. A useful way to hold it: | The claim says | The claim does not say | | --- | --- | | These settings were correct | Nobody else is on this device | | At the last evaluation | At this instant | | The device is managed by us | The person at it is the account holder | ## The knobs, and what each costs There are only two real levers, and both are paid for by someone. **Freshness.** You can shorten the claim's lifetime, or re-evaluate on sensitive requests. The price is decision traffic, latency on the request path, and interruption - the user who is re-prompted in the middle of a task, the offline or poorly connected device that cannot refresh and simply fails. The sensible design is per sensitivity tier rather than global: a read-only internal document store tolerates a stale claim; a production write path or a bulk data export should be decided against a fresh one, and the small population with those grants absorbs the friction. **Strictness.** You can add checks. Each one narrows the qualifying population, which is genuinely valuable - it removes the unmanaged laptop and the machine three OS versions behind. But each also creates a group that legitimately cannot pass: a build machine that cannot take the agent, a lab device pinned to an old image for a supported product, a contractor's device you do not manage. Those become exceptions, and an exception list is a standing carve-out. An adversary does not need to defeat the posture control if there is a documented population sitting outside it - and exception lists grow, are rarely revisited, and are almost never owned by anyone with the authority to say no. ## Where this sits against the rest of the model The device signal exists because network position was taken away as evidence, so the decision needs something else to lean on. It leans on two things: who the subject is, and what the device is. Both are assertions produced by systems, and both are true statements about a narrow question. The mistake is to read their conjunction as 'this request is safe'. It means 'a valid credential was presented from a device that met a checklist recently', which is a much smaller claim and is exactly what you should write down when someone asks what the control guarantees. ## Answering well Define the claim (configuration, evaluated at a moment, carried with a lifetime). Name the two non-claims (not uncompromised, not necessarily current). Then show you know it costs something: state a freshness interval tied to sensitivity, and admit that stricter checks buy you an exception list you will be maintaining for years. A candidate who says 'we require compliant devices' and stops has described a checkbox; one who says what the checkbox asserts and what it costs has described a control.