Secure Boot on Industrial Devices: What It Actually Involves

"Does it support secure boot?" comes up in nearly every serious industrial hardware evaluation. It's a checkbox on RFPs, a requirement in an increasing number of regulated deployments, and one of the most misunderstood features in embedded Linux. This post is the honest version: what secure boot actually involves on an industrial device, what breaks when you turn it on, and what it won't protect you from.

What secure boot actually is

Secure boot is a chain of trust. Each stage of the boot process verifies the cryptographic signature of the next stage before handing off control: the bootloader verifies the kernel, the kernel verifies the initramfs or root filesystem, and so on. If any link fails verification, the device refuses to boot — or boots into a recovery path, depending on your design.

The key word is chain. A chain is only as strong as its root, which is why the first link — the root of trust — has to live in immutable hardware: fused keys in the SoC, a TPM, or a dedicated secure element. Software can't bootstrap trust in itself.

The pieces you need on a real device

1. A hardware root of trust

On TI Sitara parts this is the secure boot ROM with fused keys; on Intel x86 it's Boot Guard / verified boot with fused OEM keys. This is a manufacturing-time decision — you fuse keys once, and there's no undo. Get the key ceremony wrong and you've bricked a production run's trust model, not just a board.

2. A signed bootloader

U-Boot with verified boot (CONFIG_FIT_SIGNATURE) is the standard path in Yocto builds. You sign the FIT image containing kernel and device tree with your release key. In your Yocto build, this means integrating signing into the image recipe so every build artifact is signed automatically — manual signing steps are where production mistakes happen.

3. A verified root filesystem

dm-verity is the usual mechanism: the kernel verifies filesystem blocks against a hash tree as they're read. The root hash gets baked into the kernel command line or signed boot config. This catches both tampering and flash corruption, which on industrial devices in harsh environments is not a theoretical concern.

4. Key management across the product lifecycle

This is the part teams underestimate. You need a key hierarchy (a root key kept offline, signing keys per release stream), a revocation story, and a manufacturing process that provisions per-device identity without leaking the crown jewels. A spreadsheet of keys on an engineer's laptop is not key management.

What breaks when you turn it on

Honest accounting of the costs:

• Development velocity drops. Every debug cycle now involves signing. Unsigned test kernels don't boot. Your developers will feel this daily unless you build a proper development-key workflow (separate dev keys, clearly segregated from production).
• Field updates get more complex. Your OTA system now has to deliver signed artifacts and handle key rotation. A/B partitioning pairs naturally with this — the inactive partition receives the signed update, gets verified, and only then becomes the boot target.
• Recovery gets harder. A device that refuses to boot unsigned code is a device that's harder to unbrick in the field. You need a deliberate recovery path: a signed recovery image, a hardware-triggered fallback, or both. Design this before you need it.
• Someone has to own the keys. Key ceremonies, HSMs, access control, audit trails. This is organizational work, not just engineering, and it needs an owner with a name.

What secure boot won't save you from

Secure boot verifies what runs, not whether what runs is any good. It won't fix a vulnerable application, a misconfigured firewall, or credentials baked into firmware. It doesn't protect data at rest (that's disk encryption's job) and it doesn't protect against runtime exploitation of a signed-but-buggy image. Think of it as one layer — necessary for serious deployments, insufficient on its own.

It also doesn't help if your supply chain is compromised before your keys exist. Secure boot starts at manufacturing; everything upstream of that is a different problem.

The practical takeaway

If you're shipping industrial devices that will live in the field for a decade, secure boot is worth the investment — but budget for the organizational cost, not just the engineering. The technology is well understood (U-Boot verified boot, dm-verity, fused SoC keys); the failures happen in key management and manufacturing process, the unglamorous parts nobody puts on the architecture diagram.

Secure boot ships as part of our embedded Linux platform, alongside signed A/B OTA updates. If you're weighing this for your product and want a second pair of eyes on the plan — the key hierarchy, the manufacturing flow, the Yocto integration — we're happy to talk through it.