In 2016, a piece of malware called Mirai assembled a botnet from hundreds of thousands of ordinary connected devices (cameras, routers, DVRs) and used them to knock major internet services offline. The devices weren’t exotic targets. They were ordinary products whose makers had treated security as someone else’s problem.
A decade later, the lesson still hasn’t fully landed. Connected devices ship every day with no verified boot process, no hardware root of trust, and firmware that anything can overwrite.
Secure boot, the mechanism that ensures a device only runs firmware its manufacturer actually signed, is the foundation the rest of embedded security stands on. Building it in from the first design decision rather than bolting it on later is a core principle of modern embedded development, where designing security in costs a fraction of retrofitting it later.
Regulation has now made that foundation mandatory, and the first enforceable deadline is closer than most teams realize. Here’s what secure boot involves, what skipping it costs, and what the calendar looks like.
What secure boot actually does
Secure boot establishes a chain of trust that starts in hardware and extends up through every layer of software. When the device powers on, immutable boot code, burned into the chip and impossible to alter, verifies the cryptographic signature of the next stage before running it. That stage verifies the next, and so on, up to the application firmware. If any link fails verification, the device refuses to run the unsigned code. The result is a simple, powerful guarantee: the device will only execute software the manufacturer signed with a private key that never leaves their control.
The anchor for all of this is a hardware root of trust: a secure element, a TPM, or a built-in feature like Arm TrustZone that stores keys and performs verification in a way software can’t tamper with. Without a hardware anchor, a determined attacker can eventually subvert the checks, because software-only protection can be rewritten by software.
Secure boot, verified boot, and measured boot
These three get used interchangeably and they are not the same thing.
| Term | What it does | What it gives you |
|---|---|---|
| Secure boot | Verifies each stage’s signature and refuses to execute anything that fails | Prevention. Unsigned code does not run |
| Verified boot | Often used synonymously with secure boot, though some platforms use it for a variant that allows fallback to a known-good image | Prevention plus recoverability, depending on implementation |
| Measured boot | Records cryptographic hashes of each stage into a TPM or equivalent, without blocking execution | Detection and attestation. The device can prove to a remote server what it booted |
Why skipping it is so expensive
The absence of secure boot doesn’t announce itself. The device works, ships, and sells and the cost arrives later, larger.
- Malware persistence. Without verified boot, an attacker who compromises a device can replace its firmware and survive every reboot and factory reset. The device is theirs permanently, and as Mirai showed, a fleet of such devices becomes infrastructure for attacks on everyone else.
- Cloning and IP theft. Unprotected firmware can be extracted, copied, and loaded onto counterfeit hardware. Your engineering investment becomes a competitor’s starting point, and the counterfeits carry your brand’s reputation without your quality.
- Recall-scale remediation. A security flaw discovered in a fleet with no secure update path and secure boot and secure OTA are two halves of the same system, and a gap in either can force a physical recall, which is orders of magnitude more expensive than the engineering that would have prevented it.
The Compliance Clock Is Already Running
Security by design has moved from best practice to legal requirement, and the dates matter more than the principle.
The EU’s Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. According to the European Commission’s implementation guidance, the timeline runs in stages rather than arriving all at once:
| Date | What applies |
|---|---|
| 11 June 2026 | Provisions on notification of conformity assessment bodies |
| 11 September 2026 | Reporting obligations for actively exploited vulnerabilities and severe incidents |
| 11 December 2027 | Main obligations, including the essential cybersecurity requirements in Annex I |
The September 2026 date is the one teams keep missing. From that point, manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a full notification within 72 hours, and a final report within 14 days once a corrective measure is available, or within one month for severe incidents. Reports go through ENISA’s Single Reporting Platform. Critically, these reporting duties apply to products already on the market, not only to products placed on it after December 2027.
Penalties for non-compliance with the essential requirements reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
The Commission published detailed practical guidance on 27 July 2026, running to more than 80 pages with worked examples and flowcharts. It is non-binding, but market surveillance authorities and notified bodies are expected to work from it, which makes it the closest thing to an authoritative reading currently available.
Consumer-IoT standards like ETSI EN 303 645 and schemes like the US Cyber Trust Mark point in the same direction. In practice, a connected product designed today without a verified boot chain and a secure update mechanism risks being unsellable in major markets across its intended lifespan.
What this means if you ship into the EU: the vulnerability reporting process needs to exist before September, and that requires knowing which of your products are in scope, who the responsible legal entity is, what the support period is for each, and who is on the hook to detect and escalate within 24 hours. That is process work, not engineering work, and it has a shorter runway than the 2027 technical requirements.
What Secure Boot Does Not Protect You From
Secure boot is necessary and it is not sufficient. Treating it as a security checkbox is how teams end up with a verified boot chain protecting badly written application firmware.
Runtime compromise. Secure boot verifies code at load time. It says nothing about what happens after the application starts running. A buffer overflow in your network stack is exploitable on a device with a perfect chain of trust, because the exploited code was legitimately signed. You still need memory safety practices, input validation, and ideally runtime isolation.
Signed-but-vulnerable firmware. If a version of your firmware with a known critical vulnerability was validly signed, secure boot will happily run it forever. This is what anti-rollback protection exists to solve: monotonic version counters in one-time-programmable fuses that prevent a device from accepting an older signed image. It is frequently omitted, and its absence turns every past release into a permanent attack surface. If you implement nothing else from this section, implement this.
Supply chain compromise. Secure boot verifies that firmware was signed by your key. It does not verify that the thing you signed is what you intended to sign. A compromised build server produces validly signed malicious firmware. Reproducible builds, signed SBOMs, and controlling what can reach the signing step address this. Secure boot does not.
Physical attacks. With sufficient physical access, time, and budget, chip decapping, fault injection, and side-channel analysis can extract keys. Secure boot raises the cost substantially rather than making it infinite. For most threat models that is enough, but it should be a decision rather than an assumption.
Open debug interfaces. A locked-down boot chain alongside an open JTAG or SWD port is a locked front door next to an open window. Debug interfaces need permanent disablement or authenticated access in production units, and this is one of the most common findings in embedded security assessments precisely because leaving debug open is so convenient during development.
The pattern connecting all five: secure boot answers one question, which is whether this code is authorized to run. Teams get into trouble when they treat that answer as covering questions it never addressed.
Designing It In From the Start
Secure boot is painful to retrofit and straightforward to plan for, which is why it belongs in the earliest hardware decisions.
- Silicon selection. Choose a microcontroller with the cryptographic acceleration, secure key storage, and one-time-programmable fuses you need, rather than discovering the requirement after the part is locked. Changing MCU after schematic freeze is one of the more expensive corrections available to a hardware team.
- Key hierarchy, not a key. A single signing key for an entire product line means one compromise ends everything. A hierarchy separating root keys, which stay offline in an HSM and sign rarely, from intermediate signing keys that can be rotated, contains the damage. Decide who holds the root, where it physically lives, and what the ceremony is for using it, before the first device is provisioned.
- Signing infrastructure. Keys provisioned into hardware cannot be changed later. A leaked signing key compromises the fleet permanently, and there is no patch for it. Whether you run your own HSM or use a managed signing service is a genuine build-versus-buy decision with real tradeoffs on both sides, worth working through deliberately rather than defaulting to whichever the firmware lead is familiar with. The general shape of that evaluation is covered in this comparison of custom software against managed SaaS.
- Anti-rollback from day one. Version counters in OTP fuses, incremented on release. Retrofitting this after devices ship is close to impossible, because fielded units have no counter to compare against.
- Provisioning at manufacture. Where do keys get injected, by whom, and how do you prevent your contract manufacturer from overproducing units with valid keys? This is a manufacturing process question that engineering teams routinely discover late, and the answer affects factory selection.
- Treat boot, update, and key handling as one system. A weakness in any one undermines the others. Secure boot without secure OTA means you cannot fix anything. Secure OTA without anti-rollback means an attacker can downgrade you into a known vulnerability.
If this work is going to an external firmware team, these six items belong in the statement of work rather than in a later conversation, and they’re a reasonable filter when evaluating a development partner for complex technical work. A partner who has shipped a secure boot chain will discuss key ceremonies unprompted. One who hasn’t will talk about secure boot as a feature to enable.
Secure Boot: Common Questions
Generally no, at least not properly. Secure boot depends on immutable boot code and keys provisioned into one-time-programmable hardware, and neither can be changed on units already in the field. Some platforms allow enabling a boot chain via a firmware update if the silicon supports it and the fuses have not been burned, but this only covers devices you can still reach and only if the hardware was selected with the option in mind. For fielded devices without the necessary silicon features, the honest answer is that the next hardware revision carries the fix.
Not by name. The CRA’s essential requirements in Annex I are outcome-based rather than prescriptive, requiring protection of integrity for stored and transmitted data, including firmware, and secure update mechanisms. In practice, for a device with mutable firmware, demonstrating those outcomes without a verified boot chain and a hardware root of trust is difficult. Harmonised standards under development are expected to make the expected technical approaches more explicit.
A TPM is a discrete standardized chip providing key storage, cryptographic operations, and platform measurement. A secure element is a tamper-resistant chip for secure key storage and crypto, common in payment and IoT contexts. Arm TrustZone is not a chip but a hardware-enforced separation within the main processor, creating an isolated execution environment on the same silicon. TrustZone is often cheapest because it needs no additional component; discrete secure elements and TPMs generally offer stronger physical tamper resistance.
It varies enormously with silicon choice and team experience, so treat any single figure with suspicion. The more useful framing is that the cost is heavily front-loaded and drops sharply the earlier the decision is made. Selecting an MCU with the right features during architecture costs approximately nothing extra. Discovering the requirement after silicon selection means either a hardware respin or shipping without it. Discovering it after production means a recall or a fleet you cannot secure.
For the root key, it is close to unrecoverable for devices already provisioned. Fielded units will accept anything signed with the compromised key, and they have no mechanism to learn otherwise. This is the reason for key hierarchies with rotatable intermediates, and for keeping root keys in an HSM used only during controlled ceremonies. Plan for this scenario before it happens, because there is no remediation afterward.
No. It verifies that code is authorized to load, which leaves runtime compromise, signed-but-vulnerable firmware, supply chain attacks, and open debug interfaces entirely unaddressed. It is the foundation other controls sit on rather than a substitute for them.
Conclusion
The uncomfortable truth is that embedded security failures are rarely sophisticated. They are usually the absence of basics: no verified boot, default credentials, unsigned updates, open debug ports. All cheap to include and expensive to omit.
Secure boot is the cheapest insurance an embedded product can carry, and the law increasingly requires the policy. But the near-term work for most teams is not engineering. It is knowing which products fall in scope of the CRA, who is responsible for reporting, and whether that process exists before September 2026. The technical requirements arrive in December 2027. The obligation to report an actively exploited vulnerability within 24 hours arrives considerably sooner.
Build it in from the first design review, and the catastrophic failures never get their foothold.
Infographic
