The CRA does not create a separate firmware category, but firmware is computer code and can form part of the software element of a covered product. Manufacturers should include firmware in product scope, risk assessment, vulnerability handling and update planning rather than treating it as unrelated to the hardware.
Firmware Is Generally Analysed as Software
The CRA defines software as the part of an electronic information system that consists of computer code. Firmware is generally computer code that provides low-level control or functionality for hardware. The Regulation does not need a separate firmware category for that code to matter. Where firmware forms part of a product with digital elements, it should be included in the product's software and cybersecurity analysis.
Embedded Firmware Usually Belongs Inside the Hardware Product Boundary
A connected device may depend on firmware for startup, communications, authentication, sensor handling, security controls or update functionality. Treating that firmware as legally unrelated to the hardware can produce an incomplete product boundary. The CRA's lifecycle approach requires manufacturers to consider cybersecurity risks throughout design, development, production, delivery and maintenance. Vulnerabilities in device firmware can therefore be directly relevant to the cybersecurity of the marketed hardware product.
Separately Supplied Firmware Can Require Its Own Scope Analysis
The CRA definition includes software components being placed on the market separately. Firmware supplied as a separately marketed software product or component can therefore require an independent scope assessment. The analysis should consider who makes it available, its intended purpose, connectivity, the commercial context and whether it is intended for integration into another electronic information system.
Firmware Is Relevant to the Cybersecurity Risk Assessment
Firmware can operate with high privileges and can control security-sensitive hardware functions. Manufacturers should identify firmware assets, trust boundaries, update mechanisms, authentication requirements and dependencies as part of the product cybersecurity risk assessment. Security controls implemented elsewhere in the product may be undermined if the firmware layer can be altered, downgraded or exploited without appropriate protection.
Firmware Vulnerabilities Need Lifecycle Handling
CRA obligations extend beyond the state of the product at first release. Manufacturers need vulnerability-handling processes and security update capability during the relevant support period. Firmware should therefore be represented in component inventories and vulnerability processes where it affects the product. Teams need to know which product versions use which firmware versions and how a security correction can be distributed safely.
Firmware Updates Do Not Automatically Create a New Product
A firmware update does not automatically mean that a completely new product has been placed on the market. Updates can be part of normal maintenance and vulnerability handling. However, major changes can require further analysis, including whether the update changes functionality, intended purpose or cybersecurity risk sufficiently to raise questions about substantial modification. The dedicated substantial-modification guidance should be used for that later question rather than assuming that every firmware release has the same legal effect.
Firmware Can Affect Product Classification
Classification under the CRA is based on the core functionality of the product and the relevant categories in the Regulation and implementing material. Firmware may contribute to that core functionality even though it is not marketed independently. Manufacturers should therefore define the complete functionality of the product before deciding whether it is a general, important or critical product with digital elements.
Maintain Firmware Traceability
A practical CRA product record should connect device models and hardware revisions with the firmware versions they run. Record firmware provenance, dependencies, update mechanisms, supported versions, known vulnerabilities and security fixes. This traceability supports cybersecurity risk assessment, technical documentation, vulnerability remediation and evidence requested during conformity or market-surveillance activity.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.