Attestation is a signed statement that something is in a known state. You'll find it in confidential computing, in measured boot, in build provenance and in device identity.
It's useful, and it's routinely described in a way that hides what it does.
The chain always terminates¶
An attestation is a signature. Verifying it means checking it against a key. Trusting that key means either you hold it yourself, or it's signed by another key, which recurses.
Every chain ends at a root you trust for reasons outside the system:
- A silicon vendor's provisioning key, trusted because you trust the vendor's key management and their supply chain.
- A CA root, trusted because it shipped in your OS and you never looked.
- Your own root, trusted because you generated it and you believe your own key management.
There's no attestation without a root, and no root that justifies itself. The technology doesn't create trust; it propagates it from wherever you decided to put it. Systems designed without grasping that tend to get trusted a good deal more than they've earned.
The useful question¶
Not "is this attested" but "what does this attestation claim, who signed it and what would make that signature meaningless?"
- Measured boot attests to what was loaded. Not that what was loaded is safe. A measurement matching a known-vulnerable version is a perfectly successful attestation of a bad state.
- Build provenance (SLSA and similar) attests that an artefact came from a particular source and a particular builder. Not that the source is any good; see xz, where the provenance would have been immaculate.
- Device identity attests that a key lives in particular hardware. Not that the device is uncompromised at the software level.
The pattern holds: attestation establishes identity and integrity of a measurement, never virtue. Almost every overstatement you'll read comes from muddling those two.
Revocation, which is where it gets hard¶
If a root key is compromised, every attestation under it becomes worthless. Revocation at scale is one of the properly unsolved operational problems in this area. CRLs and OCSP both have well-documented difficulties, and in many implementations a hardware root cannot be rotated at all.
Which makes a hardware root of trust a single point of catastrophic failure with no recovery path: a building held up by a single wall, with no plan for the day someone drives into it. That trade belongs in the design discussion, not the post-incident review.
What attestation makes possible¶
A fleet of machines in places you cannot visit: a substation, a wind turbine, a clinic in a town with one road into it. Each boots, measures itself and proves to your control plane what it is running before it is handed a key or allowed to join the network. A tampered device fails to join, and it fails remotely. What becomes cheap is trustworthy infrastructure in places with no staff. That reaches a lot of people who currently get worse service because their infrastructure is unsupervisable.
Build provenance is the one that changes a working engineer's day. "Where did this binary come from" has been unanswerable in practice for the whole history of the industry, which is why supply chain attacks work. An attested build chain turns it into a lookup: this artefact, from this commit, by this builder, with these inputs. The class of incident that gets smaller is the one where you spend four days establishing whether you are affected rather than fixing it.
And for people on bad connections or none: attestation lets you trust a device without trusting the network it arrived over. If the machine can prove its own state, you do not need a protected path to reach it.
Who signs the keys¶
A key you do not hold is not your root of trust. Follow the chains on a modern machine and see where they terminate: the silicon vendor's provisioning key, fused at manufacture and held under their revocation policy and jurisdiction; the OS vendor's signing key, which decides what may boot; the cloud's attestation service, the only thing that will vouch for the instance you rented. Three or four companies sign the statements the industry's security posture rests on.
These are revocation powers as well as signing powers. A vendor who can decide a firmware level is no longer acceptable can decide your fleet is no longer attestable, on their schedule, for commercial reasons as easily as security ones. We have seen the pattern in device ecosystems where an attestation check becomes the enforcement point for which software may run: framed as integrity, functioning as a licence, identical mechanism either way.
Then privacy. Device identity rooted in silicon is an unforgeable, unchangeable identifier for a piece of hardware and, by extension, its owner. That is because the design is built so it cannot be spoofed, rotated or lied about. That is what you want for a substation and what you do not want for a personal device. The property that makes a fleet manageable makes a population trackable.
Open hardware roots of trust exist, are inspectable and can be provisioned with keys you generate. What they cannot do is vouch for the memory encryption on a CPU you did not make. So the open position today is split: hold your own root for everything you can, and where the vendor's root is unavoidable, record it as a named dependency rather than pretending it is a property of the maths.
Here at AxisOps that is the rule: our own signing keys for everything we attest about our own infrastructure, plus an explicit list of the vendor roots we cannot avoid. Proving your own machine trustworthy should not be a service you rent from the company that made the chip. Run your own CA, hold your own keys and verify attestations yourself.
Where it earns its place¶
Despite all of the above, the alternative is worse: without attestation you're trusting the same parties with no way to check anything at all.
The discipline is to write down, for any system that uses it:
- What the root is.
- Who controls it.
- What the attestation claims.
- What happens if the root is compromised.
A design that can't answer those four is using attestation as a feeling rather than as a control. It's the same discipline as reproducible builds: replace a trust relationship with a checkable property, and be clear about which relationship you're still carrying.