How it works
Evidence, reference values and appraisal
Seven parts stand between "it booted" and "release the key". Each one can fail quietly.
Attestation is a chain of small steps: measure, sign, compare, decide. Most problems come from one weak step. This page goes through each one: what it is, how it is made, what goes wrong and what you have to decide.
The seven parts
1. Measurement
A record of what was loaded, taken before it runs.
- How it is made or used
- Each component is hashed before it starts. The hash goes into a protected register and into a log. In a TEE, the processor measures the initial contents of the enclave or virtual machine when it is launched.
- What goes wrong
- Things loaded later are not covered unless you measure them too. Configuration, models and scripts are often left out.
- What you have to decide
- What exactly is measured, and what is not. This list is the real meaning of everything that follows.
2. Evidence
A signed statement by the device or workload about its own state.
- How it is made or used
- On request, the hardware signs the measurements together with a fresh number from the requester. It attaches the log and the certificates needed to check the signature. Platforms call the result a quote, a report or a token.
- What goes wrong
- Evidence without a fresh number can be replayed. Evidence that is not tied to the connection in use proves that some machine is fine, somewhere.
- What you have to decide
- What goes into the free field of the evidence, and whether it really ties the proof to the connection in use. A public key alone is not enough: the evidence can then be relayed.
3. Endorsements
Statements by the maker about the hardware: this key belongs to a genuine chip, at this security version.
- How it is made or used
- They come as certificate chains and signed version lists from the processor or TPM maker. The verifier fetches them and has to keep them current.
- What goes wrong
- Stale endorsements make a verifier accept hardware the maker has already withdrawn, or reject hardware that was just patched.
- What you have to decide
- Where endorsements come from, how often they are refreshed, and what happens while a refresh is failing.
4. Reference values
The measurements the verifier expects to see.
- How it is made or used
- For your own software they come from your build: each release produces the hashes of what it ships. For firmware and platforms they come from the vendor. Formats include CoRIM and the reference integrity manifests of the Trusted Computing Group.
- What goes wrong
- This is where most projects break. A release goes out, nobody updates the reference values, and attestation fails or is switched to accept anything.
- What you have to decide
- Who produces reference values, how they reach the verifier before the release does, and how an old value is withdrawn.
5. Appraisal policy
The rules the verifier applies when it compares evidence with reference values and endorsements.
- How it is made or used
- It says which measurements must match exactly, which versions are the minimum, which flags must be off and which platforms are acceptable at all.
- What goes wrong
- A policy that only checks the signature accepts any genuine machine running anything. A policy that is too strict blocks every patch.
- What you have to decide
- What must match, what may vary, and who is allowed to change the policy.
6. Attestation result
The verifier's verdict, in a form another party can act on.
- How it is made or used
- Often a signed token with a short life. It can carry a plain yes or no, or graded claims such as 'approved software, hardware patched, configuration unknown'.
- What goes wrong
- A result with a long life becomes a second, weaker credential. A plain yes hides what was actually checked.
- What you have to decide
- How long a result is valid, what it says, and whether the relying party re-checks or trusts the verifier.
7. Decision
What the relying party does with the result.
- How it is made or used
- It releases a key, issues a credential, opens a connection or assigns work. Binding the decision to the result is what gives attestation its force.
- What goes wrong
- If the secret can be had another way, by an administrator or from a backup, the attestation is decoration.
- What you have to decide
- Which secrets and actions depend on attestation, and that there is no way around it.
What is compared with what
A verifier does more than check a signature. This is the usual list.
| In the evidence | Compared with | Typical rule |
|---|
| Signature and certificate chain | The maker's root and endorsements | Must verify, and must not be revoked |
| The fresh number | The one the verifier sent | Must be identical |
| Security versions of hardware and firmware | The minimum the policy sets | Equal or higher |
| Measurements of code | Reference values from the build | Exact match with an approved release |
| Signer of the code | The expected signing key | Exact match |
| Debug and migration flags | The policy | Debug off, migration as agreed |
| Configuration and launch policy | The required settings | Exact match, or within stated limits |
| Event log | The measurements it claims to explain | The log must replay to the signed values |
| The connection binding in the free field | The connection in use | Must match |
| Time of the evidence | Now | Within the freshness window |
What evidence means, and what it does not
| What you see | What it tells you | What it does not tell you |
|---|
| A matching measurement | The expected code was loaded. | That the code is free of flaws, or that it is still what runs an hour later. |
| A valid signature from the hardware | A genuine chip of this kind produced the evidence. | Where the machine is, or who can touch it. |
| An up-to-date security version | Known flaws up to that version are patched. | That no unknown flaw exists. |
| Debug mode off | The protected memory cannot be read with the vendor's debug features. | That the software does not leak its own data. |
| A fresh number that matches | The evidence was made for this request. | That the connection you are using ends at that machine, unless the evidence is bound to that connection. |
Where teams ask for help
These are the smaller pieces of work around an attestation protocol. Each can be done alone, or as part of a Reattestation Review.
- Decide what to measure. A list of what your evidence must cover, including configuration, models and scripts.
- Produce reference values from your build. Each release emits them, signed, in a format your verifier reads.
- Keep endorsements current. Where they come from, how they are cached, and alarms for when a refresh fails.
- Write the appraisal policy. Exact matches, minimum versions and flags, written down and versioned like code.
- Choose and run a verifier. Your own, a cloud provider's or an independent one, and what each choice means for trust.
- Design the attestation result. What the relying party sees, how long it is valid, and when it must be renewed.
- Bind secrets to results. Key release and credentials that cannot be had any other way.
- Test that it says no. Negative tests: a changed binary, an old version, a replayed quote. Each must be refused.
- Keep evidence for audit. What to store, for how long, and how to show it to an auditor.
The terms on this page follow the IETF RATS architecture. Formats are explained under EAT and CoRIM and quote, report and token. How each platform produces evidence is in the platform guide.
Written 12 November 2026. Platforms differ in detail; check the source for yours.
Working on your attestation protocol? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.