Measured Boot vs Secure Boot
Secure boot and measured boot get conflated constantly, but they answer different questions. Secure boot asks should this code run. Measured boot asks what code actually ran. A solid system often wants both, and confusing them leaves a design with neither doing its job properly.
Two Questions, Not One
The fastest way to keep these straight is to anchor each to its question. Secure boot is about permission, it decides in the moment whether a stage may execute and refuses anything that fails. Measured boot is about evidence, it records what executed so someone can check later, but it blocks nothing.
| Secure Boot | Measured Boot | |
|---|---|---|
| The question | Should this code run? | What code actually ran? |
| What it does | Verifies each stage against a trusted key | Hashes each stage into a tamper-evident register |
| On a bad stage | Halts, refuses to execute | Records the mismatch, runs anyway |
| Proves state to a remote party | No | Yes, via a signed attestation quote |
| Hardware it needs | Root of trust and a fused key hash | TPM or equivalent, plus an attestation backend |
They are not competing answers to the same problem; they are answers to different problems, which is why a high-assurance design usually needs both. Preventing bad code and proving what ran are separate needs, and the table above is the whole distinction at a glance.
Secure Boot Enforces, and Its Blind Spot
Secure boot verifies each stage against a trusted key and refuses to run anything that fails: the ROM verifies the bootloader, the bootloader verifies the kernel, and a failed signature halts the chain. The decision is local, immediate, and final, so unsigned or modified code does not execute. This is the control that keeps an attacker’s firmware off the device, because it acts before the bad code ever runs.
Its limit is that, having made its decision locally, it has nothing to say to anyone else. A backend server has no way to know, from secure boot alone, whether the device is running the firmware it should, because the check happened on the device, in the past, and left no portable evidence behind. That blind spot matters for fleets that gate access on integrity, and it is the gap measured boot fills.
Measured Boot Records
Measured boot does not block anything. Instead, each stage computes a cryptographic hash of the next stage before launching it, and extends that measurement into a secure register that cannot be rewound, usually a TPM Platform Configuration Register. Because the registers can only be extended, never overwritten, the recorded chain resists a later cover-up: malware that loads after boot cannot rewrite the measurement of the code that loaded it. The log is a faithful, tamper-evident record of exactly what ran, in order, whatever booted.
Reading the Measurements
On a device with a TPM, the measurements live in the PCRs and are readable with standard tooling. Comparing them against known-good values tells you whether the device booted the software you expect.
# read the boot measurements from the TPM's PCRs
tpm2_pcrread sha256:0,1,2,3,4,7sha256: 0 : 0x3D458CF5...A1 # firmware/ROM 4 : 0x9B2E77C0...8F # bootloader 7 : 0x0F1A33B2...4C # secure boot policy # compare against golden values; a mismatch means something changed
A PCR that matches the golden value means that stage booted unchanged; a mismatch means something in the boot path differs from what you expect, which is the signal a verifier acts on. The numbers are evidence, and evidence is exactly what secure boot could not provide.
Attestation Carries the Proof Off-Device
Those measurements become useful off-device through remote attestation: the device sends a signed quote of its PCR values, the TPM signs that quote with a key only it holds, and a backend verifies the signature and compares the values against known-good references before trusting the device. The signature proves the quote came from genuine hardware and the PCR values prove what booted, which together let a fleet refuse to enroll, or refuse to hand data to, a device whose boot state does not match, the assurance secure boot acting alone never could give.
Both on One Boot
Watching both mechanisms act on the same boot makes the distinction concrete. At each handoff, secure boot checks the next stage’s signature and halts if it fails, a yes-or-no gate; measured boot hashes the next stage, extends the hash into a PCR, and continues regardless, leaving an immutable record. One blocks; the other remembers.
# the same boot, both mechanisms running at each stage verify(stage_n+1) # SECURE BOOT: halt if signature invalid pcr_extend(hash(stage_n+1)) # MEASURED BOOT: record, then continue # result: device runs only signed code AND can prove what it ran
A device doing both runs only signed code and can later prove, to a remote verifier, exactly what it ran. Remove secure boot and a tampered stage executes but is still recorded as different; remove measured boot and bad code is blocked but the device can prove nothing off-device. Seeing them side by side on one boot is what makes clear why high-assurance designs run both rather than choosing.
Which Do You Need?
Not every product needs both, and the deciding question is whether anything off the device needs proof of its state. If the answer is no, a device that simply must not run tampered firmware is well served by secure boot on its own, and adding a TPM and an attestation backend is cost and complexity for an assurance nobody consumes. If the answer is yes, secure boot alone leaves a gap that only measurement and attestation can close.
Measured boot earns its place when a remote party makes decisions based on integrity, a server that releases keys only to known-good devices, a network that admits only attested ones, or a regulator that requires evidence of what ran, and its tamper-evident log has forensic value after an incident too. The cost is real, a TPM or equivalent to hold measurements and sign quotes, plus a backend to verify them, so the threat model, not the impulse to use every feature, sets the answer.
Where This Fits
Helping a team choose between secure boot, measured boot, or both, and verifying that the chosen model actually works, is part of a product security assessment and a threat-modeling engagement. If you want guidance on the right boot-integrity model for your product, that is the kind of work we do at Berkner Tech.
