The premise of remote attestation sounds solid. A TPM chip sits on your motherboard, measures every piece of code that runs during boot, and records those measurements as a chain of hashes in Platform Configuration Registers (PCRs). A remote party queries those PCRs, verifies the quote against a known-good set of values, and concludes that the system booted exactly the software it was supposed to. The hardware is the anchor; the math is clean.
The problem is that this model fails at practically every layer below the bootloader. This piece from Unmitigated Risk works through why the attestation story for servers has a wide gap between theory and practice. The scheme is internally consistent; the difficulty is that no component in it answers for who measures the measurer.
What TPM Attestation Actually Measures
TPMs accumulate measurements via PCR extension: PCR[n] = SHA256(PCR[n] || new_value). The initial PCR values are all zeros. Each component in the boot chain is expected to hash itself and extend the relevant PCR before passing control forward. By the end of boot, PCR values represent a rolling hash of everything that ran. Remote attestation uses the TPM’s endorsement key to sign a quote of those PCR values, which a remote verifier compares against expected values derived from known-good firmware and software.
The TCG PC Client Platform Firmware Profile specification defines which PCRs cover what: PCR 0 covers the Core Root of Trust for Measurement (CRTM) and firmware, PCRs 1-7 cover various firmware data structures, PCRs 8-15 are handed to the OS. The scheme is detailed and thoughtful on paper.
The problem is not the cryptographic machinery. The problem is that the thing doing the first measurement is never itself measured.
The BMC Boots First
On any modern server, the Baseboard Management Controller boots before the main CPU. The BMC is its own computer: it runs an ARM or MIPS core, its own firmware, its own OS (typically a stripped Linux variant), and it has persistent out-of-band access to system hardware via the LPC bus, I2C, IPMI, and often a dedicated NIC. Dell iDRAC, HPE iLO, Supermicro IPMI, and Lenovo XClarity are all BMC implementations.
The BMC can read and write system firmware flash. It can modify UEFI before the main CPU ever sees it. It can intercept memory, manipulate PCI devices, and inject code into the firmware volumes that UEFI will subsequently load and execute. If the BMC firmware is compromised, an attacker can alter everything the TPM will subsequently measure, or condition the environment to produce a known-good PCR set from manipulated code.
The TPM does not measure the BMC. The BMC firmware is never part of the SRTM (Static Root of Trust for Measurement) chain. NIST SP 800-193 acknowledges the BMC as a trust boundary and recommends firmware resilience controls, but there is no standardized mechanism to remotely attest BMC state alongside UEFI state in a unified, verifiable report. If you are running TPM-based remote attestation and your BMC is running modified firmware, your attestation tells you nothing meaningful about what your system actually booted.
The UEFI Attack Surface Is Not Just a CVE Problem
The UEFI firmware that eventually receives control is millions of lines of C. The PI (Platform Initialization) specification from the UEFI Forum defines an execution sequence: SEC, PEI, DXE, BDS, TSL, and RT phases. Each phase loads drivers, initializes hardware, and extends the PCR chain. The DXE phase alone can load hundreds of EFI drivers from firmware volumes embedded in flash.
LogoFAIL, disclosed in late 2023 by Binarly, demonstrated that BMP, GIF, JPEG, and PNG image parsers embedded in UEFI firmware contained memory corruption vulnerabilities exploitable during the DXE phase, before Secure Boot verification runs on the bootloader. An attacker with write access to the firmware logo partition could achieve code execution that predates and controls all subsequent PCR measurements. LogoFAIL affected devices from dozens of vendors because they all shared the same IBV code from AMI, Insyde, and Phoenix.
BlackLotus, a UEFI bootkit confirmed in 2023, bypassed Secure Boot on fully patched Windows 11 systems by exploiting CVE-2022-21894, a logical flaw in the Windows Boot Manager. It persisted in the EFI System Partition, survived OS reinstallation, and disabled kernel-level defenses. Both attacks would produce TPM PCR values reflecting exactly the modified boot path. A remote verifier would reject the quote because the values would not match expected baselines, but an attacker who controls the measurement origin controls what gets measured in the first place.
DRTM: The Approach That Actually Addresses This, Rarely Used
Intel and AMD both offer DRTM (Dynamic Root of Trust for Measurement) specifically to escape the problem of trusting the full UEFI chain. Intel’s implementation is TXT (Trusted Execution Technology); AMD’s is SKINIT. The approach starts a late-launch measurement chain from a clean state, independent of whatever the normal boot sequence did. The GETSEC[SENTER] instruction (Intel) or SKINIT instruction (AMD) resets the relevant PCRs, loads a signed Authenticated Code Module from CPU-authenticated memory, and starts measuring from that point forward.
DTRM largely sidesteps the UEFI measurement problem. If you use TXT or SKINIT, you do not need to trust the hundreds of EFI drivers that loaded before the late launch. The ACM is CPU vendor-signed, measured in tamper-evident fashion, and its PCR extension cannot be spoofed by anything running at UEFI privilege.
The deployment story is poor. TXT requires BIOS configuration, a matching ACM for your specific CPU stepping, and software such as tboot or a DRTM-aware hypervisor. AMD SKINIT has similar requirements. Very few production servers use DRTM. Cloud providers rarely enable it. The documentation is dense, tooling is sparse, and misconfiguration silently degrades to no protection at all.
Confidential Computing Moves the Trust Boundary Without Eliminating It
Intel TDX (Trust Domain Extensions) and AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) offer cryptographic attestation for virtual machine workloads. With SEV-SNP, the AMD Secure Processor measures the initial VM state and provides a signed attestation report including the VM’s measurement digest. A verifier checks the report against AMD’s certificate chain. With TDX, a Trust Domain gets a signed RTMR (Runtime Measurement Register) log from the Intel TDX module.
This is useful for confidential workloads, but it narrows rather than eliminates the trust problem. You are trusting AMD’s Secure Processor silicon and key management infrastructure, or Intel’s TDX microcode. The CacheWarp attack (2023) demonstrated microcode-level vulnerabilities on certain AMD processors allowing modification of encrypted guest memory, breaking SEV-SNP’s security model. If AMD’s attestation signing key were compromised, every SEV-SNP report ever issued would be suspect.
The CRTM still anchors somewhere. On commodity x86 hardware, that anchor is the CPU vendor’s fused keys and microcode. You can verify up to that layer; the layer itself is outside the verification picture.
What You Can Reasonably Do
The gap between attestation existing and attestation being trustworthy is primarily a gap in what gets measured, not in the cryptographic design.
For hardware selection: insist on Intel Boot Guard or AMD PSB (Platform Secure Boot) enabled with OEM-protected fused keys. These hash the initial UEFI block into the CPU during manufacturing, preventing firmware modifications that would still produce valid PCR measurements. Verify with your vendor that Boot Guard is in Verified Boot mode with OEM keys, not user-programmable keys, and that enforcement is on rather than just measurement mode.
For BMC hygiene: treat BMC firmware advisories as a separate patching pipeline from your OS. CVEs from Eclypsium, Binarly, and CERT/CC regularly cover BMC vulnerabilities that miss standard enterprise patch cycles. If your threat model includes supply-chain or physical access, configure BMC interfaces to the minimum required and monitor for unexpected firmware version changes.
For high-sensitivity workloads: DRTM-based stacks with TPM-sealed storage keys are operationally expensive but provide meaningfully stronger guarantees than UEFI-based attestation. A narrow set of workloads justify that cost.
Remote attestation via TPM is still worth doing. A quote that does not match expected values is a genuine signal and should trigger investigation. The asymmetry is that a matching quote is weaker evidence than it appears: the TPM faithfully records what was measured, without any ability to certify whether the measurement chain originated from a trustworthy point. Closing that gap requires either trusting your hardware vendor’s silicon unconditionally, deploying DRTM, or accepting that some portion of your boot chain will remain outside what you can independently verify.