Embedded-software CRA work should begin by defining the product boundary and the role of firmware, bootloaders, operating systems, drivers, libraries and hardware security features. The security case should then address boot integrity, device identity, privileged debug paths, local and remote interfaces, update authenticity, anti-rollback or recovery design where appropriate, long-term vulnerability handling and the exact relationship between the embedded component and the product placed on the market.
Embedded Software Is Covered Through the Product Boundary
The CRA applies to products with digital elements, including software and hardware products and their remote data processing solutions where the Regulation's conditions are met. Embedded software should therefore be analysed as part of the product actually placed on the market. A manufacturer should identify which firmware, boot code, operating-system components, drivers, libraries and remote services are necessary for the product to perform its intended functions.
Embedded Software Is Not Automatically an Annex III Important Product
Annex III does not contain a general category called embedded software. Important-product classification depends on core functionality. Embedded software may itself match a listed category, for example an embedded browser, boot manager or operating system, but a firmware component is not important merely because it is embedded. The classification record should identify the specific Annex III category relied on, if any.
Integration Does Not Automatically Reclassify the Whole Product
Article 7(1) states that integrating a product with digital elements whose core functionality matches an Annex III category does not by itself make the product into which it is integrated subject to the important-product conformity procedures. An embedded operating system or network interface can therefore have classification significance without automatically turning the entire device into the same Annex III category. The manufacturer still needs to assess the whole product against the general CRA requirements.
Map the Boot Chain Before Mapping Security Controls
Embedded products often pass control through immutable code, a first-stage bootloader, a second-stage loader, firmware, an embedded operating system and application code. The threat model should identify which stage establishes trust for the next, which keys or hashes are used, where configuration is loaded and what an attacker could achieve by replacing or downgrading one stage. Secure boot is useful only when its trust anchors and update path are also controlled.
Debug and Manufacturing Interfaces Need Lifecycle Controls
JTAG, SWD, UART consoles, test pads, factory commands and service modes can bypass ordinary application security. The manufacturer should decide which interfaces remain enabled after production, how privileged maintenance is authorized and how secrets used during factory provisioning are protected. A production device should not inherit unrestricted engineering access merely because the same interface was needed during development.
Protect Firmware Updates From Substitution and Rollback
Embedded update design should verify the authenticity and integrity of firmware before installation and should define what happens if power fails or storage is corrupted during an update. Where rollback would reintroduce a known exploitable vulnerability, the product should have an appropriate strategy for version control or anti-rollback while still preserving a safe recovery path. The technical file should distinguish security updates from factory recovery images and service tooling.
Hardware Security Features Need Software Evidence
Embedded software may depend on secure elements, trusted execution environments, memory protection, cryptographic accelerators, one-time programmable fuses or protected key stores. Merely listing those features does not show that they protect the product. Evidence should document how firmware configures them, which software components can access protected material and whether update, recovery or diagnostic modes weaken the intended protection.
Real-Time Constraints Affect Security Update Design
Embedded products can control time-sensitive physical or communications functions. Update and restart procedures should account for availability and safe interruption rather than assuming a desktop-style reboot is acceptable. The manufacturer should document maintenance states, redundancy or recovery behavior where relevant and how security fixes are delivered without silently disabling the product's essential function.
Third-Party Firmware Components Need Traceability
Embedded images frequently contain an operating system, protocol stacks, cryptographic libraries, device drivers and vendor binary components. The manufacturer should maintain sufficient component and version information to evaluate vulnerabilities and determine which product releases are affected. Where a supplier component cannot be updated independently, the product update process should explain how the manufacturer integrates and distributes the remediation.
Recovery Modes Are Part of the Attack Surface
Boot recovery, rescue partitions, USB update modes and factory reset functions can become alternative paths around normal authentication and update controls. Recovery design should verify the image being restored, protect sensitive configuration and return the product to a known security state. If recovery intentionally permits older software, the manufacturer should assess whether that creates a path back to a known vulnerable version.
Keep Evidence Tied to Hardware Revisions
Embedded software behavior can depend on processor revision, memory layout, radio module, secure element or board configuration. The technical documentation should therefore connect firmware and test evidence to the hardware variants actually placed on the market. A board revision that changes boot security, storage protection or network interfaces should trigger a review of the cybersecurity risk assessment rather than being treated as an unrelated manufacturing change.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.