Designing embedded security when you cannot patch quickly
A device in the field may be unreachable for months and in service for a decade. That constraint should change the architecture, not just the update policy.
The constraint that changes the design
Server software has a short distance between a defect and its repair. A fix merges, a pipeline runs, and within hours the vulnerable version no longer exists anywhere. Every security practice built for that world assumes patch speed as the primary mitigation.
Embedded products break the assumption in three ways. The device may be offline or intermittently connected, so an update is offered rather than applied. The deployment may prohibit unattended change—an industrial controller mid-process, a medical device in use, a vehicle in motion. And the service life may be a decade, which is longer than the support window of the operating system, the toolchain and often the silicon.
The consequence is that patch speed cannot be the main control. What remains is architecture: arranging the product so that a defect in the part most likely to contain one cannot reach the part that matters.
Bound the consequence in hardware
The most durable boundaries in an embedded product are the ones software cannot cross regardless of its defects. Where the hardware offers them, they are worth the design effort:
- a key store the application processor cannot read, so a remote code execution defect does not yield the device identity key or the firmware verification root;
- a separate execution environment for the small amount of code that must be trusted—attestation, key use, update verification—so its correctness does not depend on the correctness of the network stack;
- memory protection or an MPU/MMU configuration that separates tasks, so a parsing overflow does not reach control logic;
- one-time-programmable fuses for anti-rollback counters and lifecycle state, so a downgrade attack cannot restore a vulnerable version;
- a hardware watchdog the application cannot disable, so a hung or subverted main loop results in a reset into a known state.
Each of these converts a software defect from a total compromise into a bounded one. They also cost money and board space, which is why the decision belongs in the architecture phase rather than in a security review six weeks before production.
Separate what parses from what controls
The single most useful software-level decision in a device is to put untrusted input handling somewhere that cannot act.
Almost all remotely reachable defects live in code that parses: a protocol frame, a configuration file, an over-the-air payload, a Bluetooth advertisement, a certificate. Almost all serious consequences live in code that controls: actuating something physical, changing a safety limit, granting access, using a key.
Separating the two—different task, different privilege level, different memory region, ideally a different core—means the frequent defect class cannot directly produce the serious consequence. Communication between them goes through a narrow, validated interface that accepts a small set of structured commands rather than raw data.
This is the same argument as privilege separation in server software, with a stronger payoff, because the containment can be enforced by hardware rather than by an operating system that may itself be the target.
Make the boot chain recoverable, not just verified
Secure boot verifies each stage before executing it, which is necessary and insufficient. The harder question is what the device does when verification fails, and the answer determines whether a bad update produces a support call or a truck roll.
NIST SP 800-193 frames this well by treating protection, detection and recovery as three separate properties. Protection prevents unauthorised firmware change; detection identifies corruption; recovery restores a working image without physical access. Most products implement the first two and discover the third is missing when a fleet update goes wrong.
Practical arrangements worth deciding early:
| Property | Mechanism | Failure it prevents |
|---|---|---|
| Protection | Signed images, immutable root key, write-protected bootloader | Unsigned or modified firmware executing |
| Detection | Measured boot, integrity check before hand-off | Silent corruption or persistence |
| Recovery | A/B slots with automatic rollback, or a minimal recovery image | A bricked fleet after a bad release |
| Anti-rollback | Monotonic version counter in fuses | Downgrade to a known-vulnerable build |
Note the tension in the last two rows: anti-rollback and recovery pull in opposite directions, and resolving it requires deciding which images are permissible rollback targets. Discovering that tension in the field is expensive.
Design the interfaces you will be judged on
Device assessments and increasingly device regulations focus on a small set of interfaces, and the findings are repetitive across products: a debug interface left enabled in production, a serial console with a shell, a default credential shared across a product line, a network service listening that the product does not need, a firmware image that can be read out and contains secrets.
ETSI EN 303 645 is the clearest baseline for consumer devices, and its early provisions—no universal default passwords, a means to manage vulnerability reports, keep software updated, securely store sensitive parameters, minimise exposed attack surfaces—are the same items that appear in most assessment reports. In the UK, the first three of those have since become legal requirements for consumer connectable products under the Product Security and Telecommunications Infrastructure Act.
Treat the production configuration as a deliverable with its own review. The most common root cause of these findings is not ignorance but drift: the interface was needed while the product was being built, and nothing in the release process closed it.
An honest support period is an engineering commitment
The EU Cyber Resilience Act requires manufacturers to handle vulnerabilities and provide security updates across a defined support period, and to state it. For a product with a ten-year service life, that statement has significant engineering consequences that are easy to underestimate.
Supporting a release branch years after it shipped requires the build to be reproducible with a toolchain that still exists, the test rig for that hardware revision to still be assembled, the signing key for that generation to still be usable and still be protected, and someone to still know how the update mechanism of that firmware behaved. Each of these decays quietly unless it is somebody’s job.
The practical implication is to reduce the number of things you have to support: fewer hardware variants, a common update mechanism across generations, and a deliberate decision about which branch a fix lands on. A shorter stated period that you can honour is worth more than a longer one you cannot, to customers and to regulators.
What a field defect should cost you
A useful design review question is not “could this be exploited?” but “what does one exploited defect cost, and who pays?” Work it through for a specific case: a memory-safety defect in the network parser of a deployed device.
If parsing is isolated, the key store is hardware-protected, the watchdog resets into a verified image and the update path reaches most of the fleet, the cost is an out-of-cycle release and some support load. If parsing shares privilege with control logic, the identity key is readable from flash, and the fleet updates at forty per cent, the cost is a recall conversation.
The difference between those two outcomes was decided in the architecture, years before the defect was written. That is the argument for treating secure development lifecycle requirements as product decisions with cost implications rather than as a compliance layer—by the time a device is in the field, the set of available responses has already been fixed.