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 is allowed to execute, and it refuses anything that fails. Measured boot is about evidence: it records what executed so that someone can check later, but it blocks nothing.
Once you hold those two questions apart, most of the confusion clears. They are not competing answers to the same problem, they are answers to different problems, and a high-assurance design usually needs both because preventing bad code and proving what ran are separate needs.
Secure Boot Enforces
Secure boot verifies each stage against a trusted key and refuses to run anything that fails the check. The ROM verifies the bootloader, the bootloader verifies the kernel or application, and a failed signature halts the chain. The decision is local, immediate, and final: unsigned or modified code does not execute.
This is the control that keeps an attacker’s firmware off the device. Its strength is that it acts before the bad code ever runs, so a tampered image is stopped at the door. Its limit is that, having made its decision locally, it has nothing to say to anyone else about what happened.
What Secure Boot Cannot Do
Secure boot proves nothing to a third party. A backend server talking to the device has no way to know, from secure boot alone, whether the device is running the firmware it should. 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. If a server is about to hand a device sensitive data or network access, it wants proof of the device’s state, and secure boot, for all its strength as a local gate, cannot supply that proof. This 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. The result is a tamper-evident log of exactly what ran, in order.
Because the registers can only be extended, never overwritten, the recorded chain of measurements is resistant to a later cover-up. Malware that loads after boot cannot rewrite the measurement of the code that loaded it. The log is a faithful record of the boot, 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 Ties It Together
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.
This is how a fleet can refuse to enroll, or refuse to hand data to, a device whose boot state does not match. The TPM’s signature proves the quote came from genuine hardware, and the PCR values prove what booted. Together they give a remote party the assurance that secure boot, acting alone and locally, never could.
How the Two Work Together
The cleanest mental model is that secure boot is local enforcement and measured boot is remote evidence. Secure boot decides, on the device, whether code is allowed to run. Measured boot records what actually ran so a backend can verify it later through attestation. They operate at the same moments in boot but serve opposite ends.
A fleet that gates cloud access on device integrity wants both: secure boot to keep bad code off the device, and measured boot to prove to the server that it worked. Using one where you needed the other is the classic mistake, and it leaves either unprotected devices or unverifiable ones.
When Secure Boot Alone Is Enough
Not every product needs both. A device that simply must not run tampered firmware, and that no remote system needs to make trust decisions about, is well served by secure boot on its own. Adding a TPM and an attestation backend to such a product is cost and complexity for an assurance nobody consumes.
The deciding question is whether anything off the device needs proof of its state. If the answer is no, secure boot is the control that matters and measured boot is overkill. If the answer is yes, secure boot alone leaves a gap that only measurement and attestation can close.
When You Need Measured Boot
Measured boot earns its place when a remote party makes decisions based on device integrity: a server that releases keys only to devices in a known-good state, a network that admits only attested devices, or a regulator that requires evidence of what software a device ran. In each case the value is the portable, verifiable proof.
It also helps after an incident. Because the measurement log is tamper-evident, it can show whether a device booted compromised code even when the device itself cannot be trusted to report honestly. That forensic value is a real, if secondary, reason fleets adopt it.
The Hardware Underneath
Measured boot leans on a hardware element that can store measurements securely and sign quotes, a discrete TPM, a firmware TPM, or an equivalent secure subsystem. Secure boot leans on a hardware root of trust that holds or anchors the verification key, usually a ROM and a fused key hash. The two often share underlying hardware but use it differently.
Knowing which hardware a device has tells you which of these models is even possible. A part with no TPM-like element can do secure boot but cannot do meaningful measured boot, and a design that wants attestation has to budget for that hardware up front rather than bolting it on later.
Using Them Together in Practice
In a combined design, the boot flow does both jobs at each step: it verifies the next stage’s signature and refuses to continue if it fails, and it also measures that stage into a PCR before launching it. Secure boot keeps the device honest locally, and the measurements let a backend confirm, remotely, that it stayed honest.
That combination is what high-assurance products converge on, because preventing and proving are different needs and neither substitutes for the other. Choosing based on the question you actually need answered, rather than treating the two as interchangeable, is what keeps a design from shipping with a control that does not match its threat model.
A Side-by-Side on One Boot
Watching both mechanisms act on the same boot makes the distinction concrete. Secure boot, at each handoff, checks the next stage’s signature and halts if it fails, a yes-or-no gate. Measured boot, at each handoff, hashes the next stage and extends the hash into a PCR, then 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 to anyone off-device. Seeing them side by side on one boot is what makes clear why high-assurance designs run both rather than choosing.
A Decision Guide
Choosing between them, or deciding to use both, comes down to a few questions. Does anything off the device need to make a trust decision about its state? If yes, you need measured boot and attestation. Must the device refuse to run tampered code locally? If yes, you need secure boot. For most connected products that gate cloud access on integrity, both answers are yes.
The cost side matters too: measured boot needs a TPM or equivalent secure element to hold measurements and sign quotes, plus a backend to verify them, while secure boot needs a hardware root of trust and a key-management process for signing. A simple device that only must reject bad firmware is well served by secure boot alone; adding attestation infrastructure it has no consumer for is wasted complexity. 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.