Embedded software should not be treated as invisible merely because users buy the hardware rather than the code separately. The CRA cybersecurity analysis should reflect the software that actually enables the marketed product's digital functions, while separately marketed embedded-software components can have their own CRA position.
Embedded Software Is Part of the Digital Product Architecture
A hardware product with digital elements commonly depends on software stored or executed inside the device. That code can control communications, sensors, access control, cryptography, startup behaviour, data processing, update mechanisms and other security-sensitive functions. The CRA covers both software and hardware products, so the product cybersecurity analysis should reflect the software that actually enables the marketed hardware to perform its functions.
The Marketed Hardware Usually Provides the Main Product Boundary
Where embedded software exists only as part of a marketed hardware device, the practical CRA analysis normally begins with the complete hardware product rather than pretending that each embedded binary is a separately marketed product. The manufacturer should identify the embedded software within the product architecture and carry its cybersecurity risks and controls into the product-level assessment.
Embedded Software Can Include More Than Firmware
Embedded software can include bootloaders, firmware, operating-system components, device drivers, local applications, protocol implementations and other code used by the product. The CRA does not require teams to force all of these elements into one technical label. What matters is understanding which software components contribute to product functions and cybersecurity and which organisation is responsible for their integration.
Third-Party Embedded Components Still Affect Manufacturer Risk
Manufacturers frequently incorporate third-party operating systems, libraries, protocol stacks or other software into hardware products. The fact that the manufacturer did not write every line of code does not make those dependencies irrelevant to product cybersecurity. CRA manufacturer responsibilities include taking the cybersecurity risk assessment into account throughout the product lifecycle and exercising appropriate due diligence regarding integrated components.
Separately Marketed Embedded Software Creates a Second Question
Some embedded software is also distributed independently to equipment manufacturers or integrators. Article 3 expressly includes software components placed on the market separately within the definition of products with digital elements. Where embedded software is supplied as its own marketed component, the supplier should therefore assess whether that component itself falls within CRA scope rather than relying only on the compliance position of the finished device.
Embedded Software Must Be Traceable for Vulnerability Handling
A manufacturer needs to know which embedded software versions are used by which product versions. Without that traceability, a vulnerability in a bootloader, protocol library or operating-system component can be difficult to connect to affected products. Component and version records should therefore support vulnerability intake, impact analysis, remediation and security-update decisions throughout the support period.
Updates Need to Be Connected to the Product Record
Embedded products often receive software and firmware updates after market placement. The manufacturer should preserve the relationship between the marketed hardware version, installed embedded software, subsequent updates and cybersecurity risk evidence. Ordinary security updates are part of lifecycle security, while larger functional changes can also raise later questions about substantial modification.
Embedded Software Can Influence Product Classification
CRA product classification depends on the product's core functionality. Embedded software can provide functionality that causes a hardware product to match an important or critical product category even though the code is not separately sold. Scope should therefore be determined for the complete marketed product before the team moves to the classification and conformity assessment steps.
Build an Embedded Software Inventory Inside the Product File
For each hardware product, record the main embedded software elements, supplier or development owner, version, function, update method and relevant dependencies. Connect that inventory to the cybersecurity risk assessment, vulnerability records and technical documentation. The objective is not to create a separate CRA product for every internal software module, but to maintain evidence of the software that materially affects the security and functionality of the marketed product.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.