Treat the CRA product inventory as the index for the rest of the compliance system. It should identify each relevant product and version, preserve why the CRA does or does not apply, and link the product to classification, risk, technical documentation, conformity, component, vulnerability and support records. It should be updated when products, versions, intended purpose, architecture or market arrangements change.
The CRA Does Not Prescribe a Product Inventory Form
Regulation (EU) 2024/2847 does not create a named statutory form called a CRA product inventory. The inventory is an internal readiness control. Its value is that Article 13 obligations and the Article 31 technical-documentation duties apply product by product, so a manufacturer needs a reliable way to identify which products and versions require analysis and evidence.
Start With the Legal Product, Not Only the Commercial SKU
A sales catalogue can be a useful source, but it is not automatically the correct CRA inventory. The inventory should identify the product with digital elements as it is placed on the market, including the software or hardware version, associated remote data processing where relevant, and the entity acting as manufacturer. One commercial family may contain several technical variants that need separate records where architecture, functionality or support differs.
Record Intended Purpose and Reasonably Foreseeable Use
Intended purpose is central to CRA analysis because the cybersecurity risk assessment in Article 13 must consider intended purpose, reasonably foreseeable use and conditions of use. The inventory should therefore contain a concise intended-purpose statement and identify major operational environments or use conditions that materially affect scope or risk.
Preserve the CRA Scope Decision
For every product, record whether the CRA applies and preserve the reasoning. The record should identify whether the item is a product with digital elements, whether it has the relevant connection to a device or network, whether remote data processing is part of the product, and whether any exclusion or special regime is being relied upon. A simple yes-or-no field without reasoning makes later review difficult.
Track Product Version and Release Status
Product versions matter because risk, dependencies, vulnerability exposure and technical evidence can change across releases. Record the current supported versions, first market-placement status, major release identifiers and whether a version is active, maintenance-only or end of support. The inventory does not need to duplicate every build record, but it should point to the controlled version source.
Identify the Manufacturer and Key Economic Operators
The inventory should identify the legal manufacturer for the product and, where relevant, the authorised representative, importer and distributor arrangements used for Union market access. Internal product ownership should be recorded separately from the statutory economic-operator role so that a product manager or engineering team is not confused with the legal manufacturer.
Add Classification and Conformity Fields
The inventory should show whether the product has been assessed against Articles 7 and 8 and Annexes III and IV, including the technical descriptions in Commission Implementing Regulation (EU) 2025/2392. Where the product is not an important or critical category, record that conclusion and connect the product to the conformity-assessment route selected under Article 32.
Connect the Product to Its Cybersecurity Risk Assessment
Each inventory entry should link to the current Article 13 cybersecurity risk assessment rather than storing risk conclusions only as free text. This makes it possible to see whether the assessment exists, when it was last reviewed and whether a product change requires a new review.
Track Support Period and Lifecycle Status
Article 13 requires the manufacturer to determine a support period and to handle vulnerabilities during that period. The inventory should therefore record the support-period decision, expected end date where known, and any lifecycle status that affects vulnerability handling, user communications or update commitments.
Use Named Owners for Evidence, Not Only for Products
Assign a product owner and an evidence owner. The product owner coordinates commercial and lifecycle facts, while the evidence owner is responsible for keeping compliance records connected and reviewable. Engineering, product security, legal and compliance teams can then contribute controlled records without relying on one person to remember where every document is stored.
Review the Inventory When Product Facts Change
A CRA inventory should be reviewed when a product is launched, materially changed, rebranded, transferred between legal entities, given a new intended purpose, connected to new remote processing, moved into a new support state or affected by a classification change. The inventory is most useful when it acts as an active control rather than a one-time spreadsheet created before an audit.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.