What is hardware attestation?

/learn/hardware-attestation

Hardware attestation is a report about a machine's state, signed by a key that lives inside the CPU and never leaves it. It lets someone who does not trust the operator of a machine still verify what is running on it — because the proof comes from the silicon rather than from the software being asked about.

The short version

Software can always lie about itself. Attestation replaces “this server says it is running the right thing” with a statement signed by a key the server’s operator cannot extract or forge — and then makes access to your data conditional on that statement checking out.

/learn/the-chain

Who signs what

A report is only as good as the chain behind its signature. Every link traces back to a key AMD holds and the verifier already knows — which is what makes the report something an outsider can check.

AMD Root Key
AMD's root of trust, RSA-4096. Compiled into the verifier at build time, so it is never taken from the evidence being checked.
AMD Signing Key
Signed by the ARK. An intermediate, so AMD can rotate the keys that sign individual chips without moving the root.
Versioned Chip Endorsement Key
P-384 ECDSA, unique to one physical CPU at one firmware version. Fetched live from AMD's key distribution service.
The attestation report
Signed by the VCEK. Carries the launch measurement and the firmware versions in the region the CPU signs.

root keys RSA-4096 PSS-SHA384 · leaf and report P-384 ECDSA

/learn/what-it-refuses

Attestation is the set of lies it refuses

The mechanism is easier to understand backwards. Each row is something an attacker would want a verifier to accept, and the one check that rejects it.

“Here is an attestation report I wrote myself.”
Certificate chain
SEV-SNP
The report signature must chain VCEK → ASK → ARK. The AMD root key is compiled into the verifier, not read from the evidence, so a self-signed report has nothing to chain to.
“Here is a genuine report — I captured it last week.”
Per-request quote
SEV-SNP
The SNP report itself is fixed at boot, so it proves nothing about now. Freshness comes from a TPM Quote signed per request over the caller's data, under a key anchored into that report.
“Trust the public key I attached to the evidence.”
Pinned signer
Software
verify() checks against a signer the caller supplies out of band, never the key embedded in the evidence. Attaching your own key just means the signature fails.
“I'll reuse this signature somewhere else it also fits.”
Domain separation
Software
The string ne-enclave-attestation-v1 is inside the signed bytes, so an attestation signature cannot be replayed as an audit-chain or snapshot-manifest signature.
“Same report — I just edited the firmware version it claims.”
Signed TCB fields
SEV-SNP
Firmware and microcode versions are inside the region the CPU signs. Editing one invalidates the report, and the verifier compares them against the versions policy expects.
“I'll send the same nonce again to replay a fresh exchange.”
Nonce ring
Software
The supervisor keeps the last 256 nonces per workspace and rejects repeats. It is in-memory only, so it stops naive replay within a session — not a determined attacker across hosts.

/learn/two-layers

Why one signature is not enough

An SNP report is fixed at boot. It proves what launched, but on its own it cannot prove that the thing answering you right now is that machine. Two layers, not one.

Layer 1 · what launched

The AMD-signed SNP report, read from vTPM NVRAM. Its report data anchors the vTPM’s attestation key into the hardware signature, so the two are bound to each other rather than merely presented together.

Layer 2 · answering now

A TPM Quote signed per request under that anchored key, covering the caller’s own data. A forged report fails layer 1. A captured, replayed one fails layer 2.

The point of doing both is key release. The control plane hands over a data key only when both layers check out against policy, so “decrypt the customer’s data” becomes an action the hardware has to vouch for rather than one an operator can simply perform.

/learn/status

What is actually verified today

“Hardware-attested” covers a lot of ground, and most of the industry says it without saying which parts. Here is the split for this runtime, as built.

Attestation capabilities and their verification status
Capability	Status	What that means
SEV-SNP on Azure DCasv5	Verified on silicon	vTPM + OpenHCL paravisor path, end-to-end on real hardware. The evidence primitive is verified; the confidential profile it belongs to is still preview.
Software fallback (Ed25519)	Shipped	Not hardware. A signature over a config measurement, for development and non-confidential tiers.
SEV-SNP via /dev/sev-guest	Unvalidated	The GCP, AWS and bare-metal path. Unit-tested against synthetic reports; not yet run on those clouds' silicon.
Hardware-bound key release	Not built	The gate is hardware-rooted, but the key is wrapped by a software KMS today.
Per-microVM attestation	Not built	Attestation covers the confidential VM, not each microVM inside it.
Intel TDX · Arm CCA	Not built	Planned for later phases. No code today.

What the evidence covers

Even on the verified Azure path, the measured trusted base is the paravisor and the firmware launch digest — not your agent’s code. Attestation proves which environment booted. It does not prove the code you later ran inside it was the code you meant to run.

Check the claims, not the adjectives.

The threat model states what the evidence covers and where it stops. Read that before you rely on any of this in a regulated review.

Read the threat model Confidential computing explained