Secure Boot Isn't "Just Turn It On" — What Embedded Engineers Actually Miss

Secure boot gets pitched as a single switch in the reference manual. It isn't. It's a chain — every link verifies the next one, and the chain only matters if it terminates at something you actually trust. Most embedded teams I've worked with implement the first link, get a green build, and ship.

That worked, professionally and legally, for about fifteen years. Under the EU Cyber Resilience Act, it won't.

The chain, in order

A correct secure boot does four things, in this sequence, with no gaps:

1. Immutable ROM verifies the first-stage bootloader against a public key fused into the silicon.
2. First-stage bootloader verifies the second-stage / RTOS image against a key it carries — not the same key.
3. The application image is verified before its reset vector executes.
4. Anti-rollback counters prevent a signed-but-vulnerable older image from being re-flashed.

If any link is missing, the chain isn't broken — it's absent. A signed bootloader that boots an unsigned application is a wrapper around an attack surface, not a defense.

Where teams actually stop

In my experience reviewing field firmware for motor-control and gateway products, the cutoff is almost always between step 2 and step 3. The reasoning sounds familiar:

"The bootloader is signed and the bootloader will only flash signed images, so the application is implicitly trusted."

Implicit trust is the entire problem. The application sits in the same flash region the bootloader does. Anything with JTAG, a flash programmer, or an unbounded firmware-update path writes there directly. The bootloader's signature check on incoming updates is irrelevant to a write that bypasses the bootloader.

A minimal verification

// In the bootloader, BEFORE jumping to app_entry()
if (!verify_signature(APP_FLASH_BASE, app_header.length,
                      app_header.signature, &app_pubkey)) {
    enter_recovery_mode();
    // do not return
}

// Anti-rollback: app version must be >= fused minimum
if (app_header.version < otp_read_min_app_version()) {
    enter_recovery_mode();
}

jump_to(app_entry);

Two checks. Both have to be present. Both have to be in the bootloader, not in the application. An application cannot prove its own integrity for the same reason a person cannot prove they aren't lying.

The CRA reporting clock

Under Article 14 of the CRA, a manufacturer has 24 hours to send an early-warning notification of an actively exploited vulnerability to ENISA and the CSIRT of the member state where the manufacturer is established. Seventy-two hours for the full notification. Fourteen days to confirm whether mitigation is available.

A half-implemented secure boot turns one CVE into a fleet-wide reporting event. If your update channel is the only verification surface and that channel is bypassable, every device with the affected image is in scope.

What to do on Monday

• Diagram your chain of trust. ROM → BL1 → BL2 → app. Mark every link with the key it uses and where that key lives.
• For every link without a verification step, write down the threat model that justifies skipping it. If you can't, it's a gap.
• Add anti-rollback. OTP fuses or a monotonic counter — pick one and burn it.
• Test the failure path. A debugger-attached flash write of a tampered image must drop you into recovery, not into a brick and not into the tampered image.

Secure boot isn't "turn it on." It's "build the chain, test the chain, and accept that the chain is now part of your bill of materials."