Remote attestation is one of those concepts that reads simply in a one-paragraph description and becomes complicated the moment you try to implement it across a real cloud stack. The basic promise — a remote party can verify that a workload is running on trusted hardware in a known-good configuration — requires a chain of cryptographic evidence that runs from silicon physics up through firmware, hypervisor, and guest OS to the application itself. Each link in that chain is a different trust domain with different characteristics. This article walks through how that chain is constructed in practice, where each link can fail, and what the differences are between platform attestation (AMD SEV-SNP / Intel TDX) and discrete HSM attestation.
The Silicon Root: EK Certificate and TPM Endorsement Chain
For platforms using a TPM 2.0 — which covers most server environments not running AMD SEV-SNP or Intel TDX — the attestation chain begins with the Endorsement Key (EK). The EK is a 2048-bit RSA or ECC P-256 key pair whose public portion is signed by the TPM manufacturer in an Endorsement Key Certificate (EKcert). This certificate is typically stored in the TPM's non-volatile memory at manufacturing time and chains to the manufacturer's root CA.
The EK cannot sign attestation quotes directly — it is a decryption key, not a signing key. To produce attestation evidence, the TPM must create an Attestation Key (AK), formerly called an AIK in TPM 1.2. The AK is generated inside the TPM and can only be activated through a challenge-response with the EK: the Certificate Authority encrypts the AK activation credential with the EK public key; only a genuine TPM holding the EK private key can decrypt and activate the AK. This is the Privacy CA protocol defined in TCG TPM 2.0 Part 1 section on Identity Hierarchies.
For device identity in network contexts, TCG defines IEEE 802.1AR DevID: an Initial Device Identifier (IDevID) whose private key is generated by the TPM at manufacturing and whose certificate is issued by the device manufacturer, and a Locally Significant DevID (LDevID) issued by the network operator. In a server that has an IDevID-bearing TPM, the IDevID certificate provides a verifiable hardware-bound device identity for 802.1X network admission.
TPM Quote: Binding Platform State to the Key
Attestation evidence in TPM 2.0 is produced by TPM2_Quote(). The command takes a set of Platform Configuration Register (PCR) indices, a nonce from the verifier, and the handle of the signing AK. It returns a TPMS_ATTEST structure containing the PCR digest, the nonce, the firmware version (TPMS_CLOCK_INFO), and the name of the signing key — all HMAC'd and then signed by the AK. The PCR values reflect the cumulative SHA-256 (or SHA-384 in TPM 2.0 with SHA-384 banks) extend operations performed during boot: firmware measures each stage into PCRs, and the final PCR digest is a cryptographic commitment to the complete boot path.
The verifier checks the AK certificate chain back to the EKcert, checks the EKcert back to the TPM manufacturer root, and then verifies the Quote signature with the AK public key. If PCR values match a known-good reference measurement (a Golden Value from a trusted boot), the platform is attested. The nonce prevents replay.
What TPM attestation does not provide: it does not prove that the code currently executing is the same code that was measured during boot. PCR values reflect boot-time state, not runtime state. A platform that boots cleanly and then loads malicious code after the TPM Quote is generated passes attestation. This is the gap that runtime attestation (integrity measurement architecture, IMA, or Intel TDX RTMR) is designed to fill.
vTPM in Confidential VMs: AMD SEV-SNP vs. Intel TDX
AMD SEV-SNP and Intel TDX both provide VM-level confidential compute — the hypervisor cannot read guest memory — and both define their own attestation mechanisms that do not rely on a discrete TPM chip.
AMD SEV-SNP attestation is based on the AMD Secure Processor (AMD-SP), a dedicated ARM Cortex-A5 embedded alongside the main x86 die. At VM launch, the firmware calls SNP_LAUNCH_FINISH, which causes the AMD-SP to compute a measurement of the initial guest memory pages and record it in the Guest Context page. The guest can later request an attestation report via the SNP_GUEST_REQUEST GHCB protocol; this report includes the MEASUREMENT field (SHA-384 of the initial page contents), the guest policy, the platform version (TCB_VERSION reflecting microcode and firmware levels), and is signed by a VCEK (Versioned Chip Endorsement Key) whose certificate chains to AMD's KDS (Key Distribution Service) root. The guest can retrieve the VCEK certificate from AMD KDS over HTTPS using the chip-unique identifier in the attestation report.
Intel TDX attestation follows a structurally similar path. The TD (Trust Domain) initial measurement is recorded in MRTD; runtime measurements are in four RTMR registers that the TD can extend during execution. A TDX attestation quote is generated by the Intel quoting enclave (running in a separate TD) and signed by a per-platform Provisioning Certification Enclave key (PCK key) whose certificate chains to Intel's PCCS infrastructure. The quote structure is DCAP-compatible and verifiable offline against cached Intel collateral, which matters for air-gapped or latency-sensitive verification environments.
The practical difference between SEV-SNP and TDX attestation for platform integrators: SEV-SNP's VCEK is chip-unique and version-specific, meaning the certificate must be retrieved from AMD KDS for each TCB version update (microcode patch). TDX with DCAP caches the PCK certificates locally and allows offline verification, which simplifies deployment in regulated environments where outbound HTTPS to vendor infrastructure is restricted.
Workload Identity: Chaining from Platform to Application
Platform attestation proves the hardware and firmware state. Workload attestation extends the chain to prove that a specific application, with a specific configuration and code hash, is running inside the attested environment. The gap between these two is where most production confidential computing deployments stumble.
The standard pattern is a layered measurement: the host platform produces an SNP or TDX attestation report covering its initial VM image. The VM's boot firmware (OVMF in Linux guests) measures the kernel and initrd into TD RTMR registers. The workload itself, typically a container, has its image hash measured by the container runtime. The attestation verifier receives the full evidence bundle — platform report + boot measurements + workload measurements — and validates the entire chain.
An evaluation scenario: an infrastructure security team at a growing cloud services company evaluated confidential VM deployment for a key management service. Their requirement was that any key release operation must be conditioned on a valid attestation chain proving (a) the host is running a specific microcode TCB version, (b) the guest kernel is an approved version, and (c) the key management application container hash matches the signed release artifact. They implemented the chain using SEV-SNP attestation + IMA for kernel measurement + container image digest bound into the SNP guest policy. The attestation verifier — a separate service with no access to the key material — validates the chain before authorizing the key release. The entire verification path can be run offline against cached AMD KDS certificates, removing the KDS availability dependency from the key release critical path.
Where Attestation Chains Break in Practice
The most common production failure mode is not cryptographic — it is operational. Reference measurements (Golden Values) go stale when firmware updates are applied, causing previously-passing attestation to fail. Teams that do not have a systematic process for updating reference measurements after each approved firmware update will experience attestation failures that look, to the application layer, like infrastructure outages.
The second common failure is certificate chain validation under network partitions. If the verifier cannot reach AMD KDS or Intel PCCS to retrieve the endorsement certificate, and it has no locally-cached certificate, verification fails. The correct architecture pre-fetches and caches endorsement certificates as part of the fleet provisioning process, not at verification time.
We're not saying attestation is unreliable — the cryptographic primitives are sound and the specifications are well-defined. We're saying that the operational layer around attestation — reference measurement management, certificate caching, TCB version policy, and chain-of-trust documentation for auditors — is where production deployments actually fail. The silicon half of the problem is largely solved; the operational half is where engineering effort is still concentrated in most organizations.