Embedded and Firmware Security for Connected Products
The firmware security chain from root of trust to field updates, link by link, with the guide that covers each one.
Firmware security for a connected product is a chain. Each link depends on the one before it: a hardware root of trust anchors secure boot, secure boot checks signed images, signing protects the update path, and updates keep a hardened system patched for years. This hub follows that chain for engineering leaders and firmware leads at product companies, especially those shipping long-lived industrial equipment.
Who this is for
- Teams designing a new MCU or embedded Linux product that must meet the EU Cyber Resilience Act's essential requirements [1].
- Teams with a fleet already in the field that now needs signed updates, rollback protection and a support period [1].
- Machinery makers, whose safety-relevant software must be protected against corruption under the Machinery Regulation [2].
Why it matters now
The CRA’s Annex I sets product properties that land directly on firmware. Among others, products must be placed on the market without known exploitable vulnerabilities, be secure by default, allow vulnerabilities to be fixed through security updates, protect against unauthorised access, and protect the integrity of programs and configuration against unauthorised modification [1]. These obligations apply from 11 December 2027 [1]. NIST’s platform firmware resiliency guidelines frame the same goal in three parts: protect firmware, detect corruption, and recover to a known-good state [3].
The chain, and where each guide fits
Our original map of the firmware security chain. The CRA points are where the requirement most directly lands, not a full compliance mapping.
| Link in the chain | Engineering question | Closest Cyber Resilience Act Annex I Part I point [1] | Guide |
|---|---|---|---|
| Hardware root of trust | What does the device trust first, and where are keys anchored? | (2)(d), (2)(f) | Hardware root of trust and secure boot |
| Secure boot | Does every stage verify the next one before it runs? | (2)(f) | Same guide, plus the bootloader security checklist |
| Signing and keys | Who can sign a release, and how are keys protected and rotated? | (2)(f) | Firmware signing and key management |
| OTA updates and rollback | How do signed updates reach the fleet safely, and recover if they fail? | (2)(c) | Secure firmware update architecture; OTA platform vs. custom update infrastructure |
| Hardening | What attack surface does the shipped image expose? | (2)(b), (2)(j) | Embedded Linux and Yocto security hardening |
| Testing | How do you show it works, before and after release? | (2)(a) | Firmware security testing |
The CRA column shows the closest point, as our reading; it isn’t a legal mapping.
Industrial specifics
Industrial products often add constraints: intermittent connectivity, maintenance windows, safety interlocks, and fleets that stay in service for many years. Our secure firmware update architecture guide is written around those constraints, and the CRA requires the support period to reflect how long the product is expected to be in use [1].
Start here
- Check your current update path against the Secure Update Readiness Assessment.
- Read the secure firmware update architecture guide.
- Confirm what your silicon gives you as a root of trust: hardware root of trust and secure boot.
- If the work is bigger than your team, see how to evaluate firmware development companies.
Guides in this section
- Secure Boot and Hardware Root of Trust: architecture choices for product teams: SoC ROM, secure element, TPM or TrustZone; chain of trust; provisioning; rollback.
- Secure Firmware Update Architecture for Industrial Connected Products: signing → distribution → verification → A/B or delta install → rollback → reporting.
Sources
All accessed 2026-11-10.
- Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024. Cited: Art. 13(8), 71(2); Annex I Part I point (2). EUR-Lex, ELI: http://data.europa.eu/eli/reg/2024/2847/oj
- Regulation (EU) 2023/1230 on machinery, Annex III section 1.1.9. EUR-Lex, ELI: http://data.europa.eu/eli/reg/2023/1230/oj
- NIST, SP 800-193, "Platform Firmware Resiliency Guidelines", May 2018. https://csrc.nist.gov/pubs/sp/800/193/final
Spotted an error? Report it to our corrections log. Read our editorial methodology.