What it means
Attestation provides a statement or evidence about some claimed state. In remote device or workload attestation, an attester supplies evidence to a verifier, which evaluates it against trusted reference information and an appraisal policy. Another system uses the result in its own decision. Freshness matters because yesterday's acceptable state may not describe today's device. The trust placed in keys, hardware, software measurements, and the verifier also matters. Broader organizational control attestations may be documented assertions rather than hardware-backed cryptographic evidence, so always clarify what kind of attestation is being offered.
The idea at a glance / Evidence
Trusted boot evidence is one input to access.
Keep signed evidence, scoped appraisal and separate resource permission visible together.
Synthetic workstation D163 measures boot image B163 at 08:00 UTC. D163 signs E163 containing that digest and verifier challenge N163 at 09:00. Verifier V163 accepts the bound key, recent challenge and approved reference, returning scoped R163. ResearchDesk accepts that result at 09:00:10. Its independently authenticated U163 may read dataset F163, but may not change it.
READ THE PICTURE
Evidence, trust and a bounded decision
ResearchDesk accepts R163 for D163’s selected boot image. U163’s read succeeds, but its write is refused; F163 remains unchanged.
Keep in mindTrust in the attester key, measurement mechanism, reference and verifier is assumed; the lab signs JSON, not a TPM quote. A current nonce dates signing, not the original measurement. The result covers the selected boot image, not current runtime safety, all software or future behavior. Device evidence does not grant a user every operation. Result-time checks assume synchronized UTC clocks.
Read the complete example
- Evidence, trust and a bounded decision. ResearchDesk accepts R163 for D163’s selected boot image. U163’s read succeeds, but its write is refused; F163 remains unchanged. E163 binds D163, boot time 08:00 UTC, image B163 SHA-256 35077e39a87bfa8c343d6746f4971fe735b829a2f4b6ddeb3b4ddc02fc80333d, and unpredictable challenge N163, signed at 09:00. At 09:00:10 V163 validates the configured attester key, challenge deadline and approved digest; the trusted measurement mechanism is assumed. Its signed R163 binds D163/N163, the selected boot-image result, ResearchDesk audience and 09:05 expiry. ResearchDesk checks its trusted verifier, subject, audience, challenge and result freshness before using it. U163’s ordinary session is independently valid, with read-only F163 permission: read returns 200; write returns 403 and leaves the dataset unchanged. A fresh nonce proves recent signing, not that the 08:00 measurement was just taken or that runtime behavior is safe. This illustrative signed-JSON exercise is not a hardware attestation implementation.
Trust in the attester key, measurement mechanism, reference and verifier is assumed; the lab signs JSON, not a TPM quote. A current nonce dates signing, not the original measurement. The result covers the selected boot image, not current runtime safety, all software or future behavior. Device evidence does not grant a user every operation. Result-time checks assume synchronized UTC clocks.
Diagram references: RFC 9334: evidence, appraisal, freshness and relying parties · OWASP: enforce permission on every request
AN ILLUSTRATIVE SCENARIO
Approved boot evidence, refused dataset write
D163 signs an approved boot digest and fresh challenge. V163 appraises that evidence and issues scoped R163. ResearchDesk checks the result, then separately enforces U163’s read-only F163 permission: read succeeds, write is refused. F163 stays unchanged. The current challenge dates signing, not the earlier boot measurement, and the result does not establish safe runtime behavior.
Put it to work
- Define the claim that matters, such as approved software state, and who will produce, verify, and rely on the evidence. Identify trust anchors and reference values rather than accepting an unexplained green status.
- Validate the evidence's authenticity, relevance, and freshness using the supported attestation process. Establish the appraisal policy and document limitations, including what the measurements do not reveal about runtime behavior.
- Use the result within an explicit access or workflow policy. Decide how failures, stale results, changed measurements, and verifier outages are handled, with accountable exceptions where the business requires them.
How to check your work
Test acceptable, changed, stale, and missing evidence. Confirm the verifier distinguishes them, the relying service applies its intended policy, and an otherwise unauthorized user remains denied even when the device's attestation is valid.
Connect the ideas
- Zero trust
An architecture approach that grants no implicit trust from network location or asset ownership and evaluates access to resources using identity, device, and other context.
- Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
- Provenance
The recorded origin, collection method, transformations, and completeness limits of a piece of evidence.