Cyber Resilience Act: A Practical Guide for Embedded Firmware Teams
Zephyr RTOS, SBOMs, secure updates, vulnerability reporting and incident response
By Arkadiusz Grzelka · ArivEmb · Revised 4 October 2026
Technical guidance only. This article is not legal advice; product classification and conformity decisions should be reviewed with qualified legal and compliance specialists.
Why the Cyber Resilience Act matters to embedded teams
The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, turns cybersecurity into a product requirement for products with digital elements placed on the EU market. For an embedded team, this reaches far beyond a security checklist. The obligations connect product architecture, firmware, the build system, the software bill of materials, update mechanisms, vulnerability handling and the evidence retained for each release.
A manufacturer outside the European Union can still be directly affected when its product is sold in the EU. Article 18 permits the appointment of an authorised representative, but this does not transfer the manufacturer’s core obligations. Importers and distributors also have duties before making a product available, so the first practical signal may be a compliance questionnaire from a European customer or distributor.
The dates embedded product teams should plan around
- 10 December 2024: Regulation (EU) 2024/2847 entered into force.
- 11 September 2026: CRA reporting obligations for actively exploited vulnerabilities and severe incidents begin to apply.
- 11 December 2027: the main product requirements apply to products placed on the EU market.
The support period is not automatically the same for every product. The manufacturer determines it from the expected use and product context; as a general rule it is at least five years unless the product is expected to be used for a shorter period. Firmware maintenance, dependency tracking, update infrastructure and evidence retention therefore need a lifecycle plan before release.
What a defensible embedded security workflow looks like
The CRA is easier to manage when security evidence is created by the engineering workflow instead of assembled manually during an audit. Three habits make the largest difference: evidence is a build artifact, every dependency is pinned to a reproducible revision, and an unknown scan result is never treated as a clean result.
1. Reduce and map the attack surface
List every interface that accepts attacker-controlled input: Bluetooth Low Energy, network protocols, USB, UART shells, debug ports, device firmware update channels, parsers and provisioning interfaces. Record what each entry point can reach, keep the boundaries reviewable and test the failure paths as deliberately as the happy paths.
A useful test strategy is risk-based. Prioritise boundary values, malformed input, negative cases, privilege transitions and complete attacker-controlled paths. A percentage target can be a supporting metric, but it is not a substitute for testing the paths that matter to the threat model.
2. Pin the software supply chain
A release must be rebuildable. Pin Zephyr, modules, vendor SDKs, toolchains, containers and other dependencies to known revisions. CI should fail when production inputs follow floating branches. Secrets, sample signing keys and shared default credentials should never become part of a release baseline.
3. Generate the SBOM from what was built
Generate an SBOM for every product release and retain it with the signed firmware, build provenance, test results and scan output. For Zephyr-based products, west spdx can provide a useful starting point. The inventory should reflect the compiled product rather than every repository that happened to be checked out.
Scanner results require context. Matching often depends on product identifiers, version ranges and database freshness. A vendor fork or commit-based Zephyr build may not map cleanly to a CPE. If a component could not be identified or the vulnerability database is stale, record the limitation explicitly instead of reporting a false clean result.
Zephyr RTOS and CRA engineering
Zephyr provides strong foundations for product security: Kconfig-based feature control, devicetree-described hardware, Twister testing, native_sim, MCUboot integration, SPDX generation and a public vulnerability process. Compliance is not automatic, however. The manufacturer still owns the product configuration, its modules and forks, update policy, evidence, vulnerability decisions and communication with users.
CVE-2025-10456 is a useful example of why version statements must be precise. The Zephyr advisory records the BLE issue as fixed in the main line for 4.2.0 and in the maintained 3.7 branch. Teams should consult the current project advisory rather than repeat a blanket statement that every release up to a particular number is affected.
Secure boot and update are lifecycle mechanisms
Signed firmware is only one part of the design. A production update path also needs authenticity checks, rollback policy, recovery behavior, power-loss handling and field monitoring. The complete flow—upload, install, boot, confirm, revert and recover—should be tested on the target hardware.
A compromised root signing key is a different class of incident. Upstream MCUboot does not provide one portable, universal field-revocation mechanism for a compromised root key. Recovery depends on the product architecture and hardware capabilities. Key rotation, secondary trust paths, protected storage and a recovery plan should therefore be designed before the first product ships.
When a vulnerability is reported
Imagine a researcher reports that a BLE device can be taken over without pairing and says exploitation is already occurring. The team must quickly validate the report, identify affected products and versions, locate the responsible component, decide whether the issue is actively exploited, prepare mitigations and determine how a signed fix can reach the field.
The first hours
- Acknowledge the reporter and open a private incident record.
- Reproduce the issue and preserve the proof of concept as a regression test.
- Use release SBOMs and build records to identify affected product versions.
- Activate the reporting and user-communication owners defined in the incident runbook.
- For an actively exploited vulnerability, prepare the CRA early warning within 24 hours and the follow-up notification within 72 hours.
Under the CRA reporting process, the final report for an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure becomes available. Severe incidents have their own reporting sequence and a final report timeline of one month. Current procedural details should always be checked against the European Commission and ENISA reporting guidance.
Fix, verify and roll out
Convert the exploit into an automated test before changing the code. Apply the fix, run the security-specific tests and the full release suite, regenerate the SBOM and other evidence, sign through the normal release pipeline and monitor the field rollout for update failures or unexpected rollback. A rushed patch that bricks devices becomes a second incident.
Close the loop
Keep the exploit test in every future release. Publish an advisory that explains affected versions and the safe upgrade path. When the flaw is in an external component, notify the component manufacturer or maintainer and share the issue, fix and supporting information where applicable under Article 13(6). Record non-affected products using VEX where appropriate, and update the threat model, runbook and release controls.
Five practical actions to start now
- Pin every production dependency to a fixed, reviewable revision.
- Generate and retain an SBOM for every shipped firmware release.
- Scan on every build and on a schedule, while recording what the scanner could not identify.
- Replace sample signing keys and design key rotation and recovery before release.
- Write and rehearse an incident runbook covering reporting, remediation and user communication.
Download the presentation
The revised 16-slide deck is available as a PDF: https://arivemb.com/downloads/ArivEmb_CRA_Practical_Guide_Embedded_Firmware_2026.pdf
Primary references
Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20/eng
European Commission CRA summary: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
European Commission CRA reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
Zephyr vulnerability advisories for 2025: https://docs.zephyrproject.org/latest/security/vulnerabilities/2025.html
FDA cybersecurity in medical devices FAQ: https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs
NIST IR 8425: https://csrc.nist.gov/pubs/ir/8425/final
MCUboot signed images: https://docs.mcuboot.com/signed_images.html
MCUboot with Zephyr: https://docs.mcuboot.com/readme-zephyr.html