Your IoT device sits in someone's home, a factory floor, or a roadside cabinet. An attacker with physical access can desolder the flash chip. A network attacker who compromises your OTA server can push malicious firmware. Without secure boot, the device happily runs whatever code it finds. We implement secure boot on every production device we ship. Here's the architecture.

How the chain of trust works

Think of it as a relay race of verification. Each stage checks the next before handing off control.

The ROM bootloader — burned into silicon at the factory, immutable — verifies the first-stage bootloader. The first-stage bootloader verifies MCUboot (our second-stage bootloader). MCUboot verifies the application firmware.

If any verification fails, execution stops. The device doesn't boot. It doesn't run unverified code. It doesn't fall back to an unsigned image. It stops.

The ROM bootloader is the root of trust because it can never be modified. It holds a public key (or a hash of one) and knows how to verify a digital signature. Everything else in the system is software that could theoretically be replaced — so everything else needs to be verified.

MCUboot in practice

MCUboot is the standard open-source bootloader for Cortex-M. We use it on every project. It handles image signing (ECDSA-P256), image encryption, A/B slot management for OTA, and automatic rollback.

The signing workflow plugs into CI/CD. The pipeline builds the firmware binary, sends it to an HSM (hardware security module) for signing, and produces a signed image. The device holds the corresponding public key. At boot, MCUboot reads the image header, computes SHA-256 of the image, and verifies the signature.

If it fails, MCUboot checks the secondary slot. If that fails too, it enters recovery mode — a minimal bootloader that only accepts signed images over BLE or UART. The device never executes unverified code. Ever.

This has caught real problems for us — corrupted flash sectors, incomplete OTA downloads, even a case where a manufacturing test fixture was accidentally flashing debug firmware onto production devices. Secure boot caught it at the factory, not in the field.

Key management: the actually hard part

The cryptography is the easy part. Key management is where teams get burned.

Where is the signing key stored? An HSM. Never a developer's laptop. Never a shared drive. Never committed to git (yes, we've seen this).

Who can sign production firmware? A defined, audited group with multi-person approval. Not "anyone with access to the build server."

How do you rotate keys if one is compromised? Your bootloader needs to support multiple public key slots or a key revocation mechanism. Design this before you ship.

What if you lose the key? You lose the ability to update every device in the field. Forever. Have a backup. Test the backup. Test the restore procedure.

We use cloud KMS for signing key storage. The CI/CD pipeline requests a signature — the private key never leaves the HSM. Key rotation is built into our image format from day one.

Physical hardening

Secure boot protects against software attacks. Physical attacks need physical countermeasures.

Our production checklist: Read-out protection (RDP Level 2 on STM32) prevents flash readback through debug interfaces. Write protection on bootloader flash sectors means even if an attacker gets code execution, they can't modify the bootloader. Debug interface disable: JTAG and SWD are off in production firmware. Secure element (ATECC608B) stores device-unique private keys in tamper-resistant hardware. And physical measures: debug headers are depopulated or epoxy-filled on production boards.

For higher-security applications, the STM32L5 and STM32U5 families offer TrustZone-M — hardware isolation between a secure world (bootloader, keys, crypto) and a non-secure world (application). Even if the application is compromised, the secure world stays protected.

Is this overkill for a consumer sensor? Maybe. Is it overkill for an EV charger handling payment data? Absolutely not.

Key Takeaways

• Secure boot = relay race of verification. Each stage checks the next. Failure means no boot.
• MCUboot handles signing, encryption, OTA slots, and rollback. Use it.
• Key management is harder than cryptography. Use HSMs. Plan for rotation. Test your backups.
• Physical hardening complements secure boot: RDP, debug disable, secure elements, TrustZone.