The promise of measured boot is appealing: every component in the boot process leaves a cryptographic fingerprint, recorded in tamper-resistant hardware, and a remote party can later ask for proof of what ran. It sounds like a solved problem. After years of TPM 2.0 deployments, mandatory Secure Boot on Windows hardware, and cloud providers shipping virtual TPMs, you might expect that verifying a server’s boot state would be routine. It is not, and the original analysis at Unmitigated Risk lays out the structural reasons why. The gap is worth unpacking in detail, because the failure is not one of missing hardware. The hardware is mostly there. The failure is in the layers above it.
What Measured Boot Is Actually Doing
A TPM contains a set of Platform Configuration Registers, or PCRs. These are not storage; they can only be updated by extending them: new_value = SHA256(old_value || new_data). The boot firmware starts measuring at power-on. PCR 0 gets the firmware code, PCR 2 gets expansion ROMs, PCR 4 gets the bootloader, PCR 7 captures Secure Boot state and policy. By the time the OS starts, PCRs 0 through 7 encode a hash chain representing everything that ran before userspace.
The TPM can then produce a quote: a signed attestation of the current PCR values, signed by an Attestation Key that is itself certified back to the TPM’s manufacturer key (the Endorsement Key Credential). That quote is cryptographically bound to the hardware. A remote verifier can check the signature and trust that those PCR values are real.
But here is what a quote does not tell you: whether those PCR values are good.
The Reference Value Problem
Verification requires more than a measurement. You need a reference, some known-good set of PCR values to compare against. Where do those come from?
For a simple case, imagine you build your own firmware, your own bootloader, and your own kernel. You compute the expected PCR values yourself, seal them in your attestation service, and check incoming quotes against them. This works. It is also not how any real infrastructure operates.
In practice, your firmware comes from AMI, Insyde, or Phoenix. Your bootloader is GRUB or systemd-boot, shipped by your Linux distribution. Your kernel comes from upstream. Each component has its own versioning, patch cadence, and signing authority. Getting accurate, timely reference measurements for the full stack requires every vendor in that chain to publish signed reference values, in a format your attestation service can consume, covering every version combination that any of your machines might be running.
No such ecosystem reliably exists. The IETF RATS (Remote ATtestation procedureS) working group, through RFC 9334, defines an architecture for exactly this problem, with “Reference Value Providers” as a formal role. The architecture is sound. The deployed infrastructure is sparse. Most attestation deployments in the wild either skip reference value checking entirely, or only check a handful of PCRs they control directly.
PKFail: When the Root of Trust Ships with a Test Key
In July 2024, Binarly researchers published PKFail, a disclosure showing that hundreds of device models from Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo, and Supermicro had shipped with the AMI reference Platform Key, a key explicitly labeled “DO NOT TRUST” in its common name field. That key had leaked from a private GitHub repository in 2023.
The Platform Key is the root of the UEFI Secure Boot hierarchy. Whoever holds it can sign arbitrary UEFI images, which the firmware will trust unconditionally. A machine running PKFail-affected firmware has no meaningful Secure Boot protection, regardless of what PCR 7 contains. The measurement still happens. The quote still looks fine. The trust anchor is gone.
This is not a TPM design flaw. The TPM faithfully recorded what ran. The problem is that the foundation the entire chain rests on, the firmware vendor’s key management, turned out to be unreliable for a significant fraction of deployed hardware. You cannot audit that from outside the vendor’s organization. You could not detect it from PCR values alone.
Cloud Attestation and the Hypervisor Layer
Cloud providers have done real work here. AWS Nitro, Google Confidential VMs (using AMD SEV-SNP), and Azure’s vTPM implementation all provide attestation mechanisms. They are worth using. They are also not a complete solution to the original problem.
A virtual TPM is provided by the hypervisor. A quote from a vTPM attests to what the hypervisor measured about the guest. The hypervisor’s own boot is attested by the hardware TPM on the physical host. The hardware TPM is attested by… the cloud provider’s internal infrastructure, which you as a customer cannot independently audit.
AMD SEV-SNP pushes this further. The SEV-SNP attestation report is signed by a Versioned Chip Endorsement Key (VCEK) derived from secrets burned into the CPU itself, certified by AMD’s hardware root. The launch measurement covers the initial guest memory state. This is a meaningfully stronger model because the CPU hardware, not just a software hypervisor, is attesting. But the reference values for what the guest firmware and kernel should look like still need to come from somewhere authoritative.
Intel TDX follows a similar architecture. Both are genuinely useful for confidential computing workloads where you need to verify the initial state of a trust domain. Neither eliminates the reference value problem; they just move it to a better-defined place.
The Firmware Audit Problem
Below all of this sits UEFI firmware, often 10 to 16 MB of C code, built from vendor-specific forks of the EDK II reference implementation. This code runs before any measurement happens, except for the measurement of itself.
If firmware is compromised before signing, the TPM faithfully records the compromised firmware’s hash. Secure Boot still executes. PCR 0 contains a measurement of code that has a backdoor in it. The quote looks normal to any verifier that does not have an independent reference for what PCR 0 should contain for that specific firmware version on that specific board revision.
Firmware-level implants like BlackLotus (discovered in 2023, the first publicly known UEFI bootkit to survive OS reinstalls and bypass Secure Boot) and CosmicStrand (attributed to a Chinese threat actor, persisting in UEFI firmware of Gigabyte and ASUS motherboards) demonstrate that this attack surface is real and exploited. BlackLotus specifically exploited CVE-2022-21894, a Secure Boot bypass that required a lengthy Microsoft revocation process to address across the installed base.
What Systemd-stub and UKI Help With, and What They Do Not
One of the more practical developments in the Linux boot attestation space is the Unified Kernel Image (UKI) format, supported by systemd-stub. A UKI bundles the kernel, initrd, kernel command line, and OS release information into a single signed UEFI binary. Booting a UKI gives you a clean, attestable measurement: PCR 11 contains the kernel and initrd, PCR 12 captures the kernel command line, and PCR 15 captures the OS release metadata.
This is a real improvement for the post-firmware layers. If you build and sign your own UKIs, you control the reference values for those PCRs. Combined with TPM-bound LUKS encryption where the disk encryption key is sealed to a PCR policy, you can ensure the disk only unlocks on the intended software stack.
The firmware layer is still outside your control. PCRs 0 through 7 still depend on trusting the firmware vendor’s supply chain, the hardware OEM’s key management, and the distribution of Secure Boot policy. UKIs help you lock down your slice of the boot chain; they do not give you independent verification of the layers beneath.
The Structural Gap
The article’s central claim holds up under scrutiny. Verification requires three things: a trustworthy measurement mechanism, a trustworthy set of reference values, and a trustworthy chain connecting the two. Measured boot with TPM provides the first. The second requires an industry-wide infrastructure of signed reference value feeds from firmware vendors, OS vendors, and bootloader maintainers that does not yet exist at production scale. The third requires that infrastructure to be timely enough to cover your actual running software versions.
The RATS framework provides the vocabulary to describe what that infrastructure should look like. Projects like Keylime, an open-source TPM-based remote attestation system, show what deployment can look like when you control enough of the stack. Hardware vendors publishing SWID tags with reference measurements would help. The TCG has specifications for all of this. Deployment is lagging the specifications by years.
The result is that most production environments running Secure Boot and TPM-based measured boot have the recording infrastructure in place and the verification infrastructure only partially built. The measurements exist. The infrastructure to give them meaning is still being assembled.
That asymmetry is the actual problem, and it is worth naming precisely. We did not fail to build the hardware. We built it, shipped it at scale, and then did not complete the software and operational work that makes the hardware meaningful for independent verification.