The Measurement Chain
You've learned that the platform sets an attestation ceiling and that each layer has a reproducibility grade. Now comes the critical connection: the attestation ceiling must carry through an unbroken chain of measurements all the way up to your application. If any layer in the chain fails to measure the layer above it, the chain fractures — and your attestation collapses.
How the chain works
When a TEE boots, each layer is measured into hardware registers before execution:
On Intel TDX, the initial measurement goes into MRTD — a register locked at boot that captures the firmware's identity. Subsequent layers extend into RTMR registers (Runtime Measurement Registers), each recording what was loaded at that stage.
The chain is simple in principle: firmware measures OS, OS measures application. Each measurement extends a hardware register that cannot be rolled back. The attestation quote includes all these registers, so a verifier can check the entire boot sequence from silicon to application.
Boot-time vs. runtime
There is a fundamental distinction between what was measured at boot and what's happening now:
Boot-time measurements (MRTD, RTMR at launch) prove: "this exact code was loaded into this environment." They are a snapshot of initial state.
Runtime measurements (RTMR extensions, IMA event logs) attempt to track: "this is what happened after boot." They are an ongoing record — but only if something is actively extending the registers.
A valid attestation quote proves the initial state was correct. It says nothing about whether the application has been compromised, reconfigured, or replaced since boot — unless the system actively measures runtime changes and the verifier checks those extended measurements.
Most production systems rely primarily on boot-time measurements. Runtime measurement (Linux IMA, dm-verity, event logs) exists but adds complexity and is not universally deployed. Know which you're using.
Measurement Chain Fracture
Here's where it gets dangerous. The platform might have an A3 ceiling — silicon-rooted, direct attestation. But if any layer in the chain fails to measure the layer above it, the chain fractures. The application is left without hardware proof, and the system's effective attestation collapses to A0 — regardless of the underlying silicon.
In the KRAB model, this is written plainly: if A = 0, verifiability is zero.
The AWS SEV-SNP case
AWS SEV-SNP is the textbook example. The platform baseline is impressive:
- Attestation ceiling: A3 (Silicon-Rooted, Direct)
- Firmware: R4 (Nix-reproducible OVMF)
- The guest has raw access to
/dev/sev-guest, signed by AMD VLEK
But AWS uses closed-source tooling to modify the guest OS before launch without measuring it. The firmware is measured. The guest OS modification is not. The chain fractures at the OS layer.
The result: on paper, A3 hardware with R4 firmware. In practice, the effective runtime attestation of a typical workload collapses to A0 unless you apply custom in-guest mitigations to restore the chain.
This is the most instructive example in confidential computing. A3 hardware, R4 firmware, and the chain still breaks — not because of a hardware flaw, but because of an unmeasured software step between firmware and application.
Why this matters for your evaluation
When you evaluate a system's KRAB profile, check the measurement chain explicitly:
- Is the firmware measured by silicon? (This is MRTD / initial measurement — usually yes on any TEE platform)
- Is the OS measured by firmware? (Does the UEFI actually extend an RTMR or PCR with the OS hash?)
- Is the application measured by the OS? (Is there a launch measurement mechanism, or does the OS just run whatever's there?)
- Are there unmeasured steps between layers? (Like AWS's guest OS modification tool)
If any answer is "no" or "I don't know," the chain may already be fractured. No amount of R4 reproducibility or B2 binding will save you — the hardware proof stops at the fracture point.
An A3 platform ceiling does not guarantee A3 effective attestation. The chain must carry from silicon to your application without interruption. A single unmeasured layer collapses the entire system to A0.
To verify the measurement chain on your platform: request an attestation quote from inside the guest, then check which RTMR/PCR registers are populated and whether they correspond to each layer you expect. Empty or unexpected register values indicate a broken chain.