Secure boot in IoT is a security mechanism that guarantees a device will run only firmware signed by a trusted manufacturer. In an ecosystem of billions of connected sensors, gateways, and controllers, secure boot is the first line of defense against firmware tampering, supply-chain attacks, and permanent device takeover. Without a chain of trust anchored in hardware, even the best transport encryption will not protect a fleet from manipulation at the bootloader level.
In short: secure boot in IoT is a hardware-anchored chain of trust in which each boot stage cryptographically verifies the signature of the next, so the device refuses to run unauthorized or modified firmware.
What is secure boot in IoT?
Secure boot is a process in which a device, before executing the next software stage, checks its digital signature against a public key stored in immutable memory. If the signature is invalid, the boot is halted.
Its foundation is the so-called Root of Trust (RoT) — a trusted anchor implemented in hardware that cannot be overwritten by software. This is what distinguishes secure boot from an ordinary checksum: it protects not only integrity but also the authenticity of the code. The mechanism is complementary to X.509 certificate-based device authentication, which secures the connection to the cloud.
How does the chain of trust work during boot?
The chain of trust is a sequence in which each verified component authenticates the next before handing over control. Trust propagates from immutable ROM code all the way to the user application.
- ROM code / Boot ROM — the first, factory-programmed, non-overwritable stage; it computes a hash and verifies the bootloader signature.
- Second-stage bootloader — once verified, it starts and checks the signature of the actual application firmware.
- Application firmware — executed only after successful validation; it can additionally verify data partitions and models.
Common cryptographic schemes are RSA-3072 with PSS padding or ECDSA on the P-256 curve, with hashes computed using SHA-256. Verifying one stage on a Cortex-M-class microcontroller typically takes tens to hundreds of milliseconds — an acceptable overhead at device startup.
Root of Trust: the hardware foundation of security
The Root of Trust is a hardware element that stores an immutable key or its hash, providing the anchor point for the entire chain of trust. Without a hardware RoT, secure boot can be bypassed.
In practice, the RoT is implemented in several ways that differ in cost and resistance:
- eFuse / OTP — one-time-programmable bits that store the hash of the public key (e.g., the SHA-256 of an RSA key); irreversible and inexpensive.
- Secure Element (SE) — a dedicated chip (e.g., ATECC608, SE050) resistant to physical attacks that stores private keys.
- TPM 2.0 — a module used in gateways and Linux-class devices, combining boot measurement with secure key storage.
For edge devices it is worth combining the RoT with local processing — we describe this approach in more detail in the context of edge computing in IoT.
Secure boot vs. encrypted flash — what's the difference?
Secure boot protects the authenticity and integrity of the code, whereas flash encryption protects its confidentiality. These are two complementary mechanisms that should work together in a production device.
Flash encryption makes it impossible to read the firmware after physically removing the memory chip or via a debug interface. On the ESP32 platform, AES-256 in XTS mode is used with a key stored in eFuse, and JTAG access is then blocked. Secure boot alone does not hide the code — which is why protecting intellectual property requires enabling both features at once. These topics are part of a broader approach to IoT security and compliance.
Anti-rollback and secure OTA updates
Anti-rollback is a safeguard that prevents installing an older, vulnerable firmware version even if it is correctly signed. It is implemented with a monotonic version counter stored in eFuse.
Without rollback protection, an attacker could restore a version from before a security patch and exploit a known vulnerability. That is why secure boot must work together with the process of OTA updates at fleet scale: the update package is signed, verified on the device, and the version counter is incremented only after a successful install. The distribution channel is additionally secured with TLS — we cover the details in our article on TLS 1.3 and X.509 certificates.
How to implement secure boot on the ESP32 and STM32?
Implementing secure boot starts with generating a signing key pair, writing the hash of the public key into eFuse, and signing the firmware image in the build pipeline. The process is irreversible, so it requires rigorous key management.
On the ESP32, this is done with Secure Boot v2 (RSA-3072 PSS or ECDSA) together with the espsecure.py tool integrated into ESP-IDF. On the STM32 family, the X-CUBE-SBSFU package and the RSS and Secure Firmware Install (SFI) mechanisms are used. In both cases, private keys should reside in a hardware HSM, not on a developer's workstation. We also touch on practical firmware aspects for these chips in our post on TinyML on the ESP32-S3. The most common deployment mistakes are:
- not enabling flash encryption alongside secure boot (the code remains readable),
- storing signing keys outside an HSM,
- skipping the anti-rollback counter during OTA updates.
Frequently asked questions (FAQ)
How does secure boot differ from flash memory encryption?
Secure boot verifies the digital signature of the firmware, ensuring its authenticity and integrity — the device will not run modified code. Flash encryption protects confidentiality, making it impossible to read the firmware after physical access. In a production IoT device, both mechanisms should be enabled at the same time.
Can secure boot be implemented on low-cost microcontrollers?
Yes. Chips such as the ESP32 (Secure Boot v2) or STM32 with the X-CUBE-SBSFU package support secure boot with no additional hardware cost, using eFuse as the Root of Trust. For higher security requirements, a Secure Element or a TPM 2.0 module is added.
How does secure boot protect against supply-chain attacks?
Because only firmware signed with the manufacturer's key will pass verification, replacing the software in the factory, in transit, or via an update is detected and blocked. Combined with anti-rollback, this also prevents flashing an older, vulnerable version.
Summary and key takeaways
Secure boot in IoT is the foundation of device security: a hardware Root of Trust, cryptographic signature verification at every boot stage, encrypted flash for confidentiality, and anti-rollback to protect against version downgrades. Implemented correctly — with keys in an HSM and a coherent OTA process — it protects a fleet from takeover for the entire life of the product.
At FSS we design secure IoT devices end to end: from hardware and PCB, through firmware with secure boot and encrypted flash, to the cloud backend. If you are planning to deploy an attack-resistant fleet, explore our offering for custom IoT device design and let's talk about a security architecture tailored to your product.