Important products with digital elements

Important products with digital elements are the product categories the Cyber Resilience Act (CRA) lists by name in Annex III. Article 7(1) ties the classification to a single feature: a product is important where it has the core functionality of a category set out there. What hangs on it are the stricter conformity assessment procedures in Article 32(2) and (3).

The classification does not change what a product has to achieve. The essential cybersecurity requirements in Annex I apply to every Product with digital elements alike. It changes only the route by which compliance has to be demonstrated, and with it lead time, cost and the question of whether a third party must be involved. Alongside important products, the CRA also has Critical products with digital elements under Article 8 and Annex IV, which follow a regime of their own.

Core functionality, not ingredient

What counts is whether a product has the core functionality of a category, not whether it contains that functionality somewhere. Recital 45 works this through with the firewall example: because class II defines the category by core functionality, firewalls and intrusion detection and prevention systems are subject to mandatory third-party assessment. Other products not categorised as important that merely integrate a firewall expressly are not.

The second sentence of Article 7(1) says the same in the other direction. Integrating a product that has the core functionality of an Annex III category does not in itself make the receiving product subject to the procedures in Article 32(2) and (3). A device does not become a class I product because an operating system runs on it.

Why these categories

The list was not assembled freely. Under Article 7(2), every category meets at least one of two criteria:

• The product primarily performs functions critical to the cybersecurity of other products, networks or services, including securing authentication and access, intrusion prevention and detection, end-point security or network protection.
• The product performs a function carrying a significant risk of adverse effects, measured by its intensity and its ability to disrupt, control or damage a large number of other products, or the health, security or safety of its users through direct manipulation. The example the Regulation gives is a central system function, including network management, configuration control, virtualisation or the processing of personal data.

The Commission has to take those criteria into account when it amends the list. For your own classification they are a guide to interpretation, not an additional test: a product that falls under no Annex III category does not become important because one of the two criteria happens to fit it.

Class I: 19 categories

• identity management systems and privileged access management software and hardware, including authentication and access control readers, biometric readers among them
• standalone and embedded browsers
• password managers
• software that searches for, removes or quarantines malicious software
• products with the function of a virtual private network (VPN)
• network management systems
• security information and event management (SIEM) systems
• boot managers
• public key infrastructure and digital certificate issuance software
• physical and virtual network interfaces
• operating systems
• routers, modems intended for connection to the internet, and switches
• microprocessors with security-related functionalities
• microcontrollers with security-related functionalities
• application specific integrated circuits (ASIC) and field-programmable gate arrays (FPGA) with security-related functionalities
• smart home general purpose virtual assistants
• smart home products with security functionalities, including smart door locks, security cameras, baby monitoring systems and alarm systems
• internet connected toys covered by Directive 2009/48/EC that have social interactive features or location tracking features
• personal wearable products with a health monitoring purpose to which Regulation (EU) 2017/745 or (EU) 2017/746 does not apply, or personal wearable products intended for children

Class II: four categories

• hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments
• firewalls, intrusion detection and prevention systems
• tamper-resistant microprocessors
• tamper-resistant microcontrollers

What separates the two classes is how far the impact of an incident reaches. Under recital 44, an incident involving a class II product might lead to greater negative impacts than one involving a class I product. As an indication of that, the recital points to class II products either performing a cybersecurity-related function or another function carrying a higher risk of adverse effects than in class I, or meeting both criteria.

What follows from the class

For any product listed in neither annex, the internal control procedure based on module A remains open (Article 32(1)). For important products the choice narrows:

• Class I: module A stays available as long as the manufacturer fully applies a Harmonised standard, common specifications or a European cybersecurity certification scheme at assurance level at least “substantial”. Where they have not been applied, have been applied only in part, or simply do not exist for the category, modules B and C or module H apply (Article 32(2)).
• Class II: a third party is always involved. The options are EU-type examination followed by internal production control (modules B and C), full quality assurance (module H), or, where available and applicable, a European certification scheme at assurance level at least “substantial” (Article 32(3)). Full application of harmonised standards makes no difference here.

In class I, therefore, the state of standardisation decides whether a notified body is needed at all. Recital 80 gives exactly that as the reason why harmonised standards should arrive in time: their availability lets class I manufacturers run the assessment through the internal control procedure and can therefore help avoid bottlenecks and delays at conformity assessment bodies. How the individual Conformity assessment procedures run is set out in Annex VIII.

Relief for open-source software

Article 32(5) carries an exception for products qualifying as Free and open-source software that fall under an Annex III category. Their manufacturers may use the procedures in Article 32(1), the internal control procedure included, provided the technical documentation is made available to the public at the time the product is placed on the market. The relief covers both classes of Annex III. It does not extend to Annex IV.

Where the AI Act meets this

Where an important product is at the same time a high-risk AI system under Article 6 of Regulation (EU) 2024/1689, and the conformity assessment based on internal control would apply there, the CRA’s own procedures govern its essential cybersecurity requirements (Article 12(3)). This covers important products subject to the procedures in Article 32(2), points (a) and (b), or in Article 32(3). The stricter assessment cannot be sidestepped through the AI Act.

The list keeps moving

Annex III is not fixed for good. Article 7(3) empowers the Commission to add and define a category by delegated act, to move one between the classes, or to withdraw one. Such acts provide, where appropriate, for a transitional period of at least 12 months before the procedures in Article 32(2) and (3) start applying; a shorter one is allowed only on imperative grounds of urgency. A product can therefore gain or lose its classification without anything about it having changed.

In borderline cases the category names alone will not carry the classification. Article 7(4) obliges the Commission to adopt, by 11 December 2025, an implementing act specifying the technical description of the categories in Annex III and Annex IV. Only that description says what a network management system is for the purposes of the Regulation. Anyone classifying a product should work from its wording rather than from the category name. Under Article 9(1), point (b), the Commission consults stakeholders, where appropriate, while the technical descriptions for Annex III are prepared.