A compromised laptop's agent reports disk encryption on and EDR running. What did the access gateway actually verify, and what does distrusting it cost?
answer
- the reporter is the suspect
- signed transport, self-composed content
- key possession is identity, not health
- a filter, not a proof
- distrust is paid for in narrower access
basics
~20 sOnly that something holding the device's credential sent a document containing those claims. The values are the endpoint's own word, and an attacker with code on it can write any of them. Distrusting them costs a narrower grant.
solid answer
~50 sThe gateway verified transport and identity, not health. It confirmed that a party holding the device credential opened the session and sent a posture document; everything inside that document was composed by software running on the machine under suspicion. An attacker with code execution on the host can patch the agent, hook the calls it uses to read that state, or simply emit a report with the values policy wants to see. So the correct reading is "a device claiming to be healthy", not "a healthy device". The price of taking that seriously is real: that device can only be given what you are willing to lose to a lying endpoint — a thinner grant, less data landing locally, a slower path for its user. That trade, not the posture schema, is the actual control.
go deeper
Be ready to separate three things out loud: who sent it, whether it arrived intact, and who wrote what is inside. Only the last one is the posture claim, and the endpoint wrote it.
Explain the mechanics of how a claimed value is produced — an agent reading operating-system state and serialising it — and why code execution on the host puts an adversary on the same side of that read.
Show the consequence in a design: which access tier a claimed-signal device may reach, what data is not allowed to land on it, and how you tell that story to the person whose work slows down.
Own the framing that a posture schema is a filter with a stated confidence, not evidence. Be able to say which signals you would fund hardware to make provable and which you would rather remove from the decision entirely.
## What actually crossed the wire A posture check has three separable parts, and interviews here fail because candidates collapse them. 1. **Channel authentication.** The session was established by a party in possession of a device credential. If that key lives in hardware and cannot be exported, this is a meaningful fact: *this* machine, not a copy of it, is on the far end. 2. **Integrity in transit.** The report was not modified by a third party between the endpoint and the gateway. 3. **The content of the report.** `disk_encryption: on`, `edr_service: running`, `os_patch_level: 2026-08`. These strings were produced by software on the endpoint. Only the third part is what the policy is deciding on, and it is the only part with no cryptographic backing whatsoever. The reporter is the suspect. Nothing about signing the transport, or even signing the report with the device key, changes who composed the values. ## What an adversary does with that An attacker who has code execution on the host — which is the exact scenario posture checking claims to defend against — sits on the same side of the boundary as the agent. Depending on privilege they can: - patch or replace the agent binary, or its configuration, so it reports fixed values; - intercept the operating-system calls the agent uses to read encryption or service state and return the answers the policy wants; - suppress the agent entirely and emit the report themselves using the device credential the agent was using; - leave everything intact and simply re-enable the checked property for the duration of the check. None of this is exotic. It is the ordinary consequence of asking a machine to grade its own homework. The signals stay useful as **hygiene** telemetry — they catch honest drift, the unpatched laptop, the user who turned something off — but honest drift is not the threat model the gateway is invoked for. ## The distinction that carries the interview **Possession of a key is identity, not health.** A device certificate held in hardware answers "which device is this?" strongly and answers "is this device compromised?" not at all. Candidates routinely present mutual TLS with a device certificate as the fix and it is not; it raises the bar for an outsider forging a report *about* a device they do not control, while doing nothing about the device lying about itself. **Hardware-rooted facts are a short list.** A hardware root of trust can sign a measurement of what loaded at boot and can prove possession of a key that never leaves it. It cannot vouch for whether a service is running right now, whether this month's patches are installed, or whether a screen lock is configured. Those remain claims, on every device, forever. **An inference can be stronger than a claim.** If the volume key is sealed to boot-time measurements, the fact that the volume unlocked at all implies an unmodified boot chain. That is an architectural property you designed in, not a string the agent typed. ## The price, which is the half candidates skip Saying "the report is unverified" is free. Acting on it is not. Once you accept that a class of signals cannot be proven, you have to decide what those devices may reach, and every option costs somebody something: | Response | Who pays | | --- | --- | | Give claimed-signal devices a thinner grant | the user, in productivity and workflow | | Require attestable hardware for sensitive access | a budget owner, in refresh cost | | Keep data off the endpoint entirely (rendered access) | run cost, latency, and user friction | | Accept the claimed signals as-is | the risk owner, who must sign for it knowingly | The answer an interviewer is listening for is not "posture checks are useless". It is that a posture check is a **filter, not a proof**: it removes the careless and the unlucky, it does not remove the adversary, and the design must be sound when every claimed field is a lie. ## How to say it in one breath "The gateway verified who was speaking and that the message arrived intact. Everything inside the message is the endpoint's own word, and the endpoint is the thing I am worried about. So that device gets what I can afford to lose."
- Does putting the posture report inside a mutually authenticated session fix it?No. Mutual authentication proves which key spoke and that the message was not altered on the way. The values were still composed on a machine the adversary controls. It does stop an outsider fabricating a report about a device they do not hold, which is worth having — but it is a different problem from the endpoint lying about itself.
- If the values can be faked, why collect them at all?Because most non-compliance is not adversarial. Claimed posture catches the laptop that fell off patching, the user who disabled a control, the build that shipped misconfigured — real hygiene work at low cost. Keep them for that, and keep them out of the decision that guards data you cannot afford to lose to a compromised endpoint.
- What would you actually change in the design after accepting this?Split access by what the device can prove. Signals that are hardware-rooted or architecturally implied can gate the sensitive tier; purely claimed signals gate the ordinary tier, and the ordinary tier is scoped so a lying endpoint gets something you can live with. The schema stays; what it is allowed to authorise shrinks.
It is a health declaration filled in by the passenger. The passport check proves who handed it over; nobody took a temperature.
saying these in an interview costs you the question
- Says a signed posture report proves the values inside it
- Presents a device certificate as evidence the device is healthy
- Assumes an agent running with high privilege cannot be tampered with
- Claims the gateway can independently re-check the reported values
- Treats posture checking as a defence against an already-compromised host