Product classification under the Cyber Resilience Act, which products are important or critical

Product classification under the Cyber Resilience Act is the system that sorts products with digital elements into four categories according to their risk, and it determines how compliance is demonstrated. Regulation (EU) 2024/2847 lists 19 categories of important products of class I and 4 of class II in its Annex III, and 3 categories of critical products in its Annex IV. Everything not on those lists is a default product. Classification does not decide whether a product is covered, because every product within the regulation is. It decides whether a manufacturer’s self-assessment is enough or a notified body or European certification is needed. Since 21 December 2025 Implementing Regulation (EU) 2025/2392 has been in force, which describes each category technically and has settled many of the doubts about where products fit.

Table of contents

The four product categories and what changes in each

The Cyber Resilience Act distinguishes four categories, and each has its own route for demonstrating conformity before CE marking. The more sensitive the product’s function is for the cybersecurity of others, the more weight the involvement of an independent third party carries.

CategoryWhere it is listedHow conformity is demonstrated
DefaultNot listed in Annex III or IVManufacturer’s self-assessment through internal control, module A
Important, class IAnnex III, 19 categoriesSelf-assessment only if harmonised standards, common specifications or a European certification scheme are applied in full. Otherwise, a notified body
Important, class IIAnnex III, 4 categoriesNotified body or European certification at assurance level at least substantial
CriticalAnnex IV, 3 categoriesEuropean certification if a delegated act requires it. Until it exists, the same routes as class II

The specific procedures, the modules and the documentation each requires are explained in our guide to CE marking under the Cyber Resilience Act and conformity assessment. Whatever the category, the essential requirements of Annex I are the same, and so is the obligation to report exploited vulnerabilities.

Core functionality decides the category

A product is important when its core functionality matches one of the categories in Annex III, under Article 7(1). It is not enough for it to have a similar function among many others. An accounting program with a password manager for its own login remains a default product, because its core function is accounting.

The same article settles the case of components. Integrating an important product into another does not make the second one important. A manufacturer of connected washing machines that builds in a microcontroller with security functions does not have to take the washing machine to a notified body because of that component. The one within Annex III is the manufacturer of the microcontroller, if it places it on the market separately.

The list is not arbitrary. The categories in Annex III meet at least one of the two criteria in Article 7(2). The first is performing functions that are critical to the cybersecurity of other products, networks or services. The second is a function which, if tampered with, could disrupt or damage a large number of products or affect the health and safety of their users.

Important products of class I

Class I of Annex III groups 19 categories. They are products with relevant security or management functions, but with a lower risk than those in class II.

  1. Identity management systems and privileged access management software and hardware, including authentication and access control readers, such as biometric readers
  2. Standalone and embedded browsers
  3. Password managers
  4. Software that searches for, removes or quarantines malicious software
  5. Products with the function of a virtual private network, or VPN
  6. Network management systems
  7. Security information and event management systems, or SIEM
  8. Boot managers
  9. Public key infrastructure and digital certificate issuance software
  10. Physical and virtual network interfaces
  11. Operating systems
  12. Routers, modems intended for connection to the internet, and switches
  13. Microprocessors with security-related functionalities
  14. Microcontrollers with security-related functionalities
  15. ASICs and FPGAs with security-related functionalities
  16. Smart home general purpose virtual assistants
  17. Smart home products with security functionalities, such as door locks, security cameras, baby monitors and alarm systems
  18. Internet-connected toys with social interactive features or location tracking features
  19. Personal wearable products with a health monitoring purpose that are not regulated as medical devices, and wearables intended for children

The technical descriptions refine several of these points. Category 17 covers products that protect the physical security of consumers in a residential setting, so a camera designed to monitor an industrial warehouse does not fall into it simply because it is a camera. Routers include virtual routers, and operating systems include real-time ones. For toys, detecting the proximity of the user or of other toys does not count as location tracking.

Important products of class II

Class II brings together just four categories, all with a central role in the security of other systems. For them self-assessment is never available.

  • Hypervisors and container runtime systems that support the virtualised execution of operating systems and similar environments
  • Firewalls and intrusion detection and prevention systems
  • Tamper-resistant microprocessors
  • Tamper-resistant microcontrollers

The difference between a class I and a class II microcontroller lies in resistance to physical tampering. One with security functions is class I, and one designed to resist physical attacks is class II.

Critical products in Annex IV

Annex IV lists three categories of critical products, those on which NIS2 essential entities depend or whose failure could disrupt critical supply chains.

  • Hardware devices with security boxes
  • Smart meter gateways and other devices for advanced security purposes, including secure cryptoprocessing
  • Smartcards or similar devices, including secure elements

The first category is broader than its name suggests. According to Implementing Regulation (EU) 2025/2392, it includes physical payment terminals, hardware security modules that generate and manage cryptographic keys, and tachographs. The condition is that they store or process sensitive data inside a casing that provides tamper evidence or tamper resistance.

For these products Article 8 allows the Commission to require a European cybersecurity certificate at assurance level at least substantial through a delegated act, with a transitional period of at least six months. Until that act exists, critical products follow the same assessment routes as class II.

Implementing Regulation 2025/2392 and the technical descriptions

Implementing Regulation (EU) 2025/2392 of 28 November 2025 contains the technical description of each category in Annexes III and IV. It was published in the Official Journal on 1 December and has been in force since 21 December 2025. Article 7(4) of the Cyber Resilience Act required the Commission to adopt it by 11 December 2025.

Its descriptions are the starting point for any analysis of where a product fits. They explain what each category does and list products it includes, with a wording that leaves the list open. A product that is not named may fall within a category if it meets the description, and one with a similar name may be outside it if its core function is different.

How the list can change

The lists in Annexes III and IV are not final. The Commission can add categories, move one from class I to class II or remove it through delegated acts, using the criteria in Article 7(2) for important products. For Annex IV it must also check critical dependency by essential entities or the risk to critical supply chains.

Changes come with notice. If a category is added to class I or II, or one is moved up from class I to class II, the delegated act must provide a transitional period of at least twelve months. Only duly justified urgency allows it to be shortened. For Annex IV the minimum is six months.

Example: a manufacturer with three products

The case is fictitious. Nortel Sistemas, S.L., a company in A Coruña, markets three products in the European Union: a warehouse management application, a 4G router for industrial warehouses and a smart lock for homes.

The management application is a default product, because its core function is not listed in Annex III even though it has user access control. It will be able to demonstrate conformity through self-assessment. The router falls into category 12 of class I, whose technical description is not limited to home use. The lock falls into category 17 of class I, because it protects physical security in a residential setting.

For those two class I products the route depends on the harmonised standards. If Nortel applies them in full once they are published in the Official Journal, it will be able to self-assess. If they do not exist or it applies them only in part, it will need a notified body. As the Cyber Resilience Act standards are still being drafted, it should start looking for a notified body early. All three products, moreover, have been subject to the obligation to report exploited vulnerabilities since 11 September 2026.

The general framework of the regulation is in our guide to what the Cyber Resilience Act is and which companies it covers, and the fines for placing a product on the market without the right assessment, in our analysis of Cyber Resilience Act penalties.

Is business management software an important product under the Cyber Resilience Act?

Generally not. Business management software, such as an ERP, an accounting program or a warehouse application, is a default product, because its core functionality is not listed in Annex III. Including ancillary security functions, such as access control for its own users, does not change the category. It would be important if its core function were, for example, identity or network management.

It is if it is a smart home product with security functionalities. Category 17 of Annex III covers cameras that protect the physical security of consumers in a residential setting and can be controlled remotely. A professional camera for industrial premises does not fit that description and, unless its core function matches another category, will be a default product.

The final product does not become important by integrating that component. Article 7(1) expressly states that integrating an Annex III product does not in itself make the product integrating it subject to the procedures for important products. The category of the final product depends on its own core functionality.

Not necessarily. Article 32(5) allows manufacturers of free and open-source software listed in Annex III to use self-assessment through internal control, provided they make the technical documentation available to the public when they place the product on the market.

Classification decides the conformity assessment procedure, which applies to products placed on the market from 11 December 2027. It is best settled earlier, because class I products without harmonised standards, class II products and critical products need a notified body or European certification, and those processes take time.

Classifying a product correctly is the decision that most affects the cost of complying with the Cyber Resilience Act. An error upwards means paying for a notified body that was not needed, and one downwards leaves the product outside the law in December 2027. At Innovatech we review where each product fits in Annexes III and IV and in the Commission’s technical descriptions, as part of our Cyber Resilience Act compliance service. Write to us and we will give you a free initial assessment.

Managing Partner at Innovatech Legal | Website | + posts

Marta Suárez-Mansilla is Managing Partner of Innovatech Legal and a Spanish lawyer (abogada), Madrid Bar (ICAM), working in technology law. She completed Harvard Law School's Copyright course and BerkeleyX's Blockchain programme, and has advised technology companies for more than eight years.