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. Nearly 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, and building it in from the first design decision rather than bolting it on later is a core principle of modern embedded development, an area where Crunch-IS is a leader precisely because security designed in is a fraction of the cost of security retrofitted. Regulation is now making that foundation mandatory. Here’s what it involves, and what skipping it really costs.
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.
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- two halves of the same system can force a physical recall, which is orders of magnitude more expensive than the engineering that would have prevented it.
Regulation has made it non-optional
Security by design is moving from best practice to legal requirement. The EU’s Cyber Resilience Act sets baseline security obligations for products with digital elements, including protection of firmware integrity and secure updates, with real penalties for non-compliance. Consumer-IoT standards like ETSI EN 303 645 and schemes like the US Cyber Trust Mark point the same direction. In practice, a connected product designed today without a verified boot chain and secure update mechanism risks being unsellable in major markets over its intended lifespan. The economics have flipped: security is now cheaper to build in than to omit.
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. That means selecting a microcontroller with the necessary cryptographic and secure-storage features rather than discovering the need after the silicon is chosen. It means establishing key management and a signing infrastructure up front, because keys provisioned into hardware can’t be changed later and a leaked signing key compromises the whole fleet. And it means treating boot, update, and key handling as a single integrated system, since a weakness in any one undermines the others.
The uncomfortable truth is that embedded security failures are rarely sophisticated. They’re usually the absence of basics no verified boot, default credentials, unsigned updates that were cheap to include and expensive to omit. Secure boot is the cheapest insurance an embedded product can carry, and increasingly the law requires the policy. Build it in from the first design review, and the catastrophic failures simply never get their foothold.
