Secure Boot: What Signature Verification Protects, and What It Doesn’t

Almost every hardware project we assess has a line item that reads "secure boot: enabled". It sits in the security concept, in the datasheet highlights, sometimes in the certification paperwork. And in almost every assessment we find the same gap: the team trusts the feature, but nobody has written down what the feature actually promises. Secure boot verifies signatures. That is a precise, narrow statement, and the distance between that statement and "the device only runs our software" is where real products fail.

This note is about that distance. Not about how to enable secure boot on a specific SoC, vendor documentation covers that, but about the properties a boot chain does and does not gain from signature verification. It is the first thing we reconstruct when we look at a device, and it is a useful exercise to run on your own product before someone else does.

What secure boot actually verifies

Secure boot is a chain of verifications, not a single switch. The boot ROM, mask-programmed silicon, contains, or measures trust against, a public key or its hash. It verifies the first loadable stage before executing it. That stage verifies the next one, and so on down to the operating system. Each link decides: do I have evidence that this next block is authentic, and do I trust the mechanism doing the verifying?

The important word is authentic. A signature check answers exactly one question: does this image come from whoever holds the corresponding private key, unmodified? That is what it protects. Click through the chain below and note how little of the boot process is actually covered by that question.

Two things stand out in real chains. First, the root matters more than the links: if the public key is not fused into OTP or eFuse but stored on the same flash as the images it verifies, the chain can be re-pointed at an attacker key. Second, chains have ends, and whatever loads after the last verified stage inherits trust it never earned.

The unsigned middle: configuration and device trees

The most common finding in boot chain reviews is not a broken signature algorithm. It is an unsigned device tree next to a signed kernel. The DTB describes the hardware: memory map, peripherals, console parameters, which nodes are enabled. A manipulated device tree can remap memory, disable a secure peripheral, redirect the console or change reserved regions, all without touching a single byte of signed code. The kernel boots, every signature verifies, and the attacker is already in the address space.

The same applies to boot arguments, configuration blobs, calibration data and firmware for external co-processors. If the boot chain copies it without verifying it, it is part of your attack surface, whatever the security concept says.

What signatures don't cover

Signature verification is deliberately blind to three questions that matter enormously in products:

• Currency. An old, legitimately signed image is as valid as the newest one. Downgrade protection is a separate mechanism, monotonic counters, and a separate engineering decision. We cover it in depth in Firmware Anti-Rollback.
• Scope. The signature covers exactly the bytes hashed at signing time. Kernel: signed. Device tree: often not. Root filesystem: only with verified boot (dm-verity), which is optional on most embedded Linux builds.
• Correctness of the verifier. The check itself is code. In 2026 alone, a U-Boot FIT signature verification bypass (CVE-2026-46728, fixed in the 2026.04 release) and a UEFI shim secure boot issue (CVE-2026-8863) demonstrated that the mechanism that enforces your trust boundary needs patching like any other component, except on a boot ROM, where you often cannot.

Secure boot vs. measured boot

Worth separating, because they answer different questions and products sometimes need both. Secure boot enforces: image fails verification, boot stops. Measured boot records: every stage hashes the next into a log or a TPM PCR, and the system, or a remote verifier, can later reconstruct what ran. Enforcement without measurement gives you no evidence trail; measurement without enforcement lets the attack proceed while documenting it. On products with a TPM, attestation of the measurement log to the backend is often the stronger architecture: the fleet can detect a manipulated device even if local enforcement has a gap.

The mistakes we find in reviews

Recurring, across vendors and product classes:

• Development keys shipped to production because the OTP was never burned, the chain verifies against a key the attacker also has.
• Secure boot enabled on the primary chain, while a recovery or field-service mode loads images with verification disabled.
• Verification results logged, but failures only logged, the boot continues anyway.
• A signed bootloader that happily loads kernels from USB or SD for "field diagnostics", outside the verified path.
• One product family, one signing key, no revocation story, a key event on the signing infrastructure becomes a recall-scale event across every device ever produced.

What to verify on your own product

Strip the marketing and answer six questions with evidence, not with the reference manual:

• Where exactly is the root public key stored, and can it be changed without silicon work?
• Which artifacts in the boot path are signed, kernel, DTB, initramfs, rootfs, co-processor firmware?
• What happens after the last verified stage?
• Is there a path, recovery, diagnostics, RMA, that bypasses verification?
• How would you rotate the signing key on deployed devices?
• When the verifier itself has a CVE, which of your products are affected, and how do you know?

If the answers are written down and boring, your secure boot is probably real. If they require a call to the silicon vendor, it is a checkbox, and the checkbox is doing more harm than good, because it stops everyone from asking further questions.