Firmware security gets deprioritized on a lot of projects because it doesn't show up as a visible feature and doesn't block a demo. The problem surfaces later — after units are in the field, physically accessible to anyone who buys one, running firmware that can potentially be extracted, modified, or used as a foothold into whatever network the device connects to. A small set of baseline protections, built in from the start, closes most of the common attack paths at a fraction of the cost of adding them after launch.
Secure boot: only run firmware that's supposed to be there
Secure boot verifies a cryptographic signature on the firmware image before executing it, ensuring only firmware signed by the legitimate manufacturer runs on the device. Without it, anyone with physical or remote flash access can potentially replace the firmware with something else entirely — a modified version that bypasses licensing or safety checks, or firmware repurposing the device for something unrelated to its intended function. Secure boot is typically implemented as a chain: an immutable first-stage bootloader (usually burned into ROM or one-time-programmable memory) verifies the next stage's signature before handing off execution, and that pattern continues up through the application firmware.
Flash encryption: protecting what's stored on the device
Even with secure boot preventing unauthorized firmware from running, an attacker with physical access to the flash memory can potentially read out the firmware image directly — exposing proprietary algorithms, embedded credentials, or implementation details that make further attacks easier. Flash encryption addresses this by encrypting firmware and stored data at rest, so a raw flash dump is unreadable without the device's encryption key, which is itself typically stored in protected, hardware-isolated memory rather than the flash it's protecting.
Debug port lockdown
JTAG and SWD debug interfaces are essential during development — they're also, if left open in shipped hardware, a direct path to reading out memory, halting execution, or reflashing firmware, bypassing secure boot entirely on some chip families if the debug port itself isn't locked down. Production firmware should disable or restrict these interfaces, using whatever mechanism the specific MCU provides (a fuse, a lock bit, a debug-authentication scheme) — and that decision needs to be deliberate, since some approaches are permanent and irreversible, which affects field-debugging and RMA processes.
Credential and key provisioning
- No shared or hardcoded secrets — every device should have unique cryptographic identity, not a secret baked identically into every unit, which turns one device's compromise into every device's compromise
- Keys provisioned at manufacture time via a secure process, not embedded in source code or configuration files that end up in a repository or a widely-shared build artifact
- Hardware-backed key storage where the target silicon supports it (a secure element or hardware security module), rather than keys sitting in general-purpose flash where they're more exposed
These decisions get harder, not easier, to add later
Secure boot and flash encryption in particular are close to impossible to retrofit onto already-shipped hardware — they typically require specific silicon features enabled and configured during initial provisioning, and reversing an unprotected fleet into a protected one after the fact usually isn't possible without a hardware revision. This is one of the clearer cases where a security decision needs to be made at the start of a project, not added once there's a reason to worry about it.
How we approach this
Secure boot, flash encryption, and debug lockdown get scoped as part of the firmware architecture from day one, sized to the actual threat model and certification requirements of the product rather than applied uniformly regardless of need. See our firmware work for how this fits into a full engagement.