No CRA compliance without a product inventory

A product inventory appears nowhere in the Cyber Resilience Act (CRA), yet hardly any of its obligations can be met without one. The regulation imposes most of its duties not on the company as a whole but on the individual product with digital elements. Scope, conformity assessment procedure, support period, retention period and the details a notification must contain are all decided product by product. Anyone who wants to answer those questions first needs a complete and up-to-date list of their products. This post explains why that is so, and what belongs in the list.

The role is determined per product

Even the question of which role a company holds under the regulation has no company-wide answer. Recital 78 notes that, depending on the services it provides in relation to a given product, the same entity may fall within different categories of economic operators. An importer or distributor that places a product on the market under its own name or trademark, or substantially modifies it, is considered a manufacturer under Article 21 and becomes subject to Articles 13 and 14. So a company that sells third-party products under its own brand or substantially modifies them carries the full manufacturer obligations for exactly those products, and not for its other products. The first field in the inventory is therefore the role.

Scope is a list, not a heading

Under Article 2(1) the regulation applies to products with digital elements that are made available on the market and whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection. That sounds like a question about the portfolio, but it is a question about each individual product, and the answer rarely matches the price list. Article 3(1) counts a product’s remote data processing solutions as part of the product. Article 3(2) defines those as data processing at a distance for which the software is designed and developed by the manufacturer or under its responsibility, and without which the product could not perform one of its functions, in practice usually a backend or a cloud service. Recital 11 gives the example of an app that needs an interface or database provided by the manufacturer. That service then falls within scope too. Conversely, components placed on the market separately are products in their own right.

Article 2 also carries exclusions, for instance for products already covered by the regulations on medical devices or on vehicle type-approval, and for spare parts made available to replace identical components and manufactured to the same specifications as the components they replace. An inventory that lists only the devices and licences sold misses the services behind them and the building blocks distributed on their own, and it does not record why a product is in or out.

Classification decides the route

The route a product takes to conformity depends on its core functionality. If it has the core functionality of a category in Annex III, it is an important product under Article 7 and must go through the procedures in Article 32(2) and (3). For class II, third-party assessment is mandatory (Article 32(3)). Only manufacturers of free and open-source software may choose the internal control procedure under Article 32(5), provided they make the technical documentation publicly available when placing the product on the market. Where an important product is integrated into another, Article 7 states expressly that this does not, in itself, subject that other product to the same procedures. Classification is not inherited. It follows from each product’s own core functionality. Core functionality from Annex IV makes a product a critical product, for which the Commission may require a European cybersecurity certificate by delegated act. Until the Commission has done so, the class II procedures apply (Article 8(1)). The regulation contains no duty to justify the classification. What the manufacturer must justify, under Article 13(4), is why individual essential requirements do not apply to a product. Recording the classification in the inventory anyway, with its reasoning, the chosen procedure and the identification number of any notified body involved, means having it ready when the Commission amends Annex III, which Article 7(3) allows it to do.

The end of support is a date per product

The support period is not a company policy. Under Article 13(8) it is set per product to reflect the length of time the product is expected to be in use. It runs for at least five years, and for less only where the expected period of use is shorter. The information used to determine it belongs in the technical documentation. The end date must be clearly specified at the time of purchase under paragraph 19, including at least the month and the year, and under Annex II it also appears in the information for users. Further deadlines follow from that date. Under paragraph 13 the technical documentation and the EU declaration of conformity must be kept for at least ten years after the product has been placed on the market or for the support period, whichever is longer. Without the date of placing on the market and the end of support for each product, it is not even possible to say when a file may be closed.

The 24-hour test

Since 11 September 2026 the reporting obligations in Article 14 have applied, and they are the sharpest test of any inventory. The early warning of an actively exploited vulnerability has to be submitted without undue delay and in any event within 24 hours, indicating, where applicable, the Member States in which, to the manufacturer’s knowledge, the product has been made available. That indication is not a formality. Article 16(2) uses it to decide which further CSIRTs receive the notification. Under Article 14(8) the impacted users of the product, and where appropriate all users, must be informed as well. For incidents, recital 67 names the ways: publishing the information on the manufacturer’s website or, where the manufacturer is able to contact the users and the risks justify it, reaching out to them directly. The inventory should therefore record, per product, the channel through which users are informed and, where direct contact is possible, who they are. Because Article 69(3) extends the reporting obligations to all products within scope that were placed on the market before 11 December 2027, the entire installed base belongs in the inventory, not only the current range. What the reporting obligations require in detail is covered in a separate post.

Components, versions, modifications

The obligations do not stop at the product level. Part II of Annex I requires vulnerabilities and components of products to be identified and documented, including by drawing up a software bill of materials covering at least the top-level dependencies. Where a manufacturer identifies a vulnerability in an integrated component, Article 13(6) requires the manufacturer to report it to whoever manufactures or maintains the component, and to address and remediate it. The regulation sets no deadline in hours for that. If the vulnerability is actively exploited, however, the 24-hour clock of Article 14 starts running on awareness, and whoever then has to search for the products and versions that contain the library will hardly meet it.

Versions are not a purely technical detail. A substantial modification after placing on the market, meaning a change that affects compliance with the essential cybersecurity requirements in Part I of Annex I or changes the intended purpose for which the product was assessed, calls for compliance to be verified and, where applicable, for a new conformity assessment (recital 41). Article 13(10) assumes that subsequent substantially modified versions of a software product are each placed on the market, and allows the manufacturer, under conditions, to provide security updates only for the version last placed on the market. The inventory therefore needs, per product, the versions with their dates and, for each change, whether it counted as substantial.

What belongs in the inventory

The obligations all but dictate the list of fields. Per product and, where it matters, per version:

• Identity: name and type of the product (Annex V, point 1) and an identifier such as a type, batch or serial number (Article 13(15)).
• Role: manufacturer, importer, distributor, or manufacturer by virtue of Article 21.
• Scope: the decision with its reasoning, plus the associated remote data processing solutions and the separately distributed components (Article 2, Article 3(1) and (2)).
• Classification and procedure: important product of class I or II, critical product or neither, plus the procedure chosen under Article 32 and the identification number of any notified body involved (Annex V, point 7).
• Dates: placing on the market per version, end of the support period with its reasoning, and from those the end of the retention obligation (Article 13(8), (13) and (19)).
• Markets: the Member States in which the product is made available, which also determine the language versions of the declaration of conformity (Article 14(2), Article 28(2)).
• Documents: where the software bill of materials, the technical documentation and the declaration of conformity are kept, and for a simplified declaration the exact internet address of the full one (Article 13(20)).
• Users and channels: the way in which impacted users are informed in an emergency and, where direct contact is possible, the users themselves (Article 14(8)).
• Supply chain: the economic operator that supplied the product and, where available, the economic operators to which it was supplied, to be presented to market surveillance authorities on request for ten years (Article 23).

Where inventories fail

The list itself is not the problem; its completeness and its upkeep are. Four patterns recur. First, the variant: the same product under several brands, where an importer or distributor that places it on the market under its own name or trademark counts as its manufacturer under Article 21, or in customer-specific editions, which are best kept as products of their own. Second, the forgotten service: the backend or cloud function that belongs to the product as a remote data processing solution but appears on no product list because it was never sold. Third, the discontinued product: withdrawn from the range but still in the field, and therefore still relevant for the reporting obligations. Fourth, the missing owner: an inventory nobody keeps up to date and which is wrong after the next release. The regulation expects the technical documentation to be continuously updated, where appropriate, at least during the support period (Article 31(2)). The inventory is where you first notice whether that is happening.