Device Posture, and the Cost of Checking Again

Device Signals · July 6, 2026 · 10 min read

Once network location stops granting authority, something has to take its place as evidence about the endpoint. The usual answer is device posture: is this machine managed, patched, encrypted, running the expected controls, free of whatever the organisation defines as unacceptable. Feed those signals into the access decision and the same credential yields different outcomes depending on where it is presented from.

The reasoning is sound. What tends to go unexamined is where posture comes from and what it costs to keep it current, and both of those determine whether the signal is doing real work or merely appearing in a policy document.

Where the signal originates

Almost every posture signal is produced by software running on the device being assessed, and reported by that device to the decision point.

This is worth sitting with, because it inverts the usual assumption about evidence. The subject of the assessment is also its author. An endpoint that reports “disk encryption enabled, patch level current, agent healthy” is making a claim about itself, and the decision point’s confidence in that claim is bounded by its confidence that the reporting path has not been tampered with — on a machine whose integrity is precisely what is in question.

When the device is genuinely healthy, this is fine; a healthy device reports accurately. The problem is the case the control exists for. An attacker with sufficient privilege on the endpoint is in a position to influence what the endpoint says about itself. The signal is least reliable exactly when it matters most, which is the same structural weakness that afflicts every self-attesting control.

Hardware-backed attestation narrows this considerably, because a measurement chain rooted in a secure element is far harder to forge than a value read from a configuration file. It narrows it; it does not close it. Attestation typically proves properties of the boot path and the presence of key material, not that the running user session is uncompromised. And the coverage is uneven — strong attestation from some platforms, weak self-report from others, nothing at all from unmanaged devices, which is often the population you were most worried about.

The practical stance is to grade the signal by how it was obtained. “This device holds a key in hardware and produced a valid attestation” and “this device’s management agent sent us a JSON object” belong in different confidence tiers, and policy should be able to distinguish them.

Posture is a fact with a timestamp

The second structural issue is freshness. Posture is not a property; it is a measurement, and measurements age.

A device that satisfied policy at nine in the morning may have been handed to somebody else, joined a hostile network, had a control disabled, or been compromised outright by ten. If the access decision consulted a posture record written at nine and the session persists all day, then the enforcement point is acting on a claim whose subject may no longer resemble it.

This is the honest origin of “continuous verification”. It is not a slogan about vigilance. It is an acknowledgement that any evaluated decision is a snapshot, and that the useful question is how quickly the system notices when the snapshot stops being true.

What continuous actually costs

“Continuously verify” is easy to write into a strategy and expensive to implement, and it is worth enumerating why, because every implementation ends up negotiating with these costs whether or not it admits to it.

Every check is in the request path. A decision that consults live signals adds latency to something a user or a service is waiting on. Multiply by request volume and the decision point becomes a high-throughput, low-latency service on the critical path of the entire estate — a very different engineering problem from the batch-shaped identity systems most organisations start with.

The decision point becomes a dependency of everything. Once policy evaluation is in the path, its availability is your availability. Which forces the question nobody enjoys: what happens when it is unreachable? Fail closed and an identity outage becomes a total outage. Fail open and the control evaporates precisely during the disruption an attacker might have caused. Most estates end up with cached decisions and a tolerated staleness window, which is a reasonable answer and should be named as the compromise it is rather than presented as continuous.

Signals must be collected continuously too. Re-evaluating policy against a posture record that is itself refreshed twice a day gives you continuous evaluation of stale inputs. Real freshness means agents reporting frequently, which means telemetry volume, storage, and a collection pipeline whose own outages silently degrade the control.

Revocation is harder than issuance. Bearer tokens are validated by signature, which is why they scale — no call back to the issuer. That same property means an issued token remains valid until it expires, regardless of what has since become true about the principal or the device. You can shorten lifetimes, which increases issuance load and re-authentication frequency; you can introspect at the enforcement point, which reintroduces the round trip you were avoiding; or you can distribute revocation events, which means building and operating a distribution system that has to be more reliable than the thing it protects. There is no option that is both cheap and prompt.

And there is a friction budget. Every additional interruption of a human being is paid for in behaviour rather than money — people route around controls that impede work, and the routes they find are less visible than the control they avoided.

Which is why most systems are periodic

Put those together and the common landing point becomes predictable: a full evaluation at session establishment, cached decisions with a bounded lifetime, re-evaluation on a timer or on specific events — a new resource, a sensitive operation, a changed network, a posture signal crossing a threshold.

That is a sensible architecture. It is also not continuous, and the distinction is operationally meaningful. It means there is a window, of known length, in which a change in the world is not reflected in access decisions. The width of that window is a real security parameter, and a programme that can state it in seconds or minutes understands its own control. A programme that says “continuous” usually has a window it has not measured.

Using posture without over-trusting it

Three habits make the signal genuinely useful rather than decorative.

Treat it as one input among several, weighted by how it was obtained, rather than a gate that turns the decision into a binary. Posture combined with a phishing-resistant credential, a plausible session and a scoped request is a strong picture; posture alone is a self-report.

Prefer signals the device cannot conveniently lie about — hardware-held keys, attested boot state, certificates the endpoint cannot export — over configuration values it simply asserts.

And record the freshness alongside the value. A decision log that says the device was compliant is much less useful than one that says it was compliant according to a measurement taken four minutes earlier through a hardware-backed path. The first is a claim. The second is evidence, and you can reason about how much of it you have.