CRA Product Classification

What Is CRA Product Classification and Why Does It Matter?

The CRA applies the same essential cybersecurity requirements (Annex I) to all products; the class changes how conformity with these requirements is demonstrated. For a default-class product the manufacturer’s own assessment is sufficient, whereas important and critical products may require assessment by an independent notified body.

Classification is therefore the first and most decisive decision in a CRA compliance project. Incorrect classification can have two consequences: placing a product in a higher class than necessary creates unnecessary notified body costs and lost time; placing it in a lower class than necessary can lead to CE marking being affixed under the wrong conformity procedure, recall of the product during market surveillance and administrative fines.

Legal Basis of Classification

Under the CRA, the classification rules are set out in the Regulation itself, while the technical descriptions of the categories are laid down in the Commission’s implementing regulation.

For categories to be included in Annex III, the Regulation sets two criteria: the product primarily performs functions critical to the cybersecurity of other products, networks or services (such as authentication and access security, intrusion prevention and detection, endpoint security or network protection), or the product performs a function that carries a significant risk of adverse effects in terms of its intensity and ability to disrupt, control or damage a large number of other products, or the health, security or safety of their users, through direct manipulation (such as network management, configuration control, virtualisation or processing of personal data) (Article 7(2)).

The Core Functionality Rule

The core principle of classification: A product’s class is determined by what the product is designed for, not by which components it contains. Under Article 7(1), integrating a product that qualifies as an important product into another product does not in itself subject that other product to the procedures applicable to important products. Implementing Regulation (EU) 2025/2392 also stresses that a product does not fall into a category merely because it can perform some of that category’s functions.

The recitals of the Implementing Regulation include examples that illustrate this rule:

• A news app with an embedded browser is therefore not assessed in the “browser” category.
• A SOAR software that can offer SIEM-like functions is generally not considered a SIEM.
• A router with an added firewall function therefore remains a router; it is assessed as a Class I router, not a Class II firewall.
• A smartphone is generally not classified as an operating system or password manager merely because it contains operating system and password manager components.

Remote data processing solutions (such as a cloud back-end under the manufacturer’s responsibility) are not classified separately. They are considered part of the product they are linked to and are assessed within that product’s class and conformity route.

Default Products

All products with digital elements within the scope of the CRA whose core functionality does not fall into any category in Annex III or Annex IV are in the default class. The vast majority of products in scope belong to this group: smart white goods, smart TVs, speakers without a virtual assistant, printers, game consoles, photo and video editing software, mobile apps, commercial enterprise software and hard drives, for example. Smart speakers with an integrated virtual assistant, however, fall into the Class I category of general-purpose virtual assistants for smart homes under Implementing Regulation (EU) 2025/2392.

Obligations do not become lighter for default-class products: all Annex I essential requirements, the vulnerability handling obligations in Annex I, Part II, the SBOM, the Article 14 reporting obligation and the Annex VII technical file apply equally to default products. The only difference lies in conformity assessment: the manufacturer can carry out its own conformity assessment under Module A, based on internal production control.

Important Products: Class I (Annex III)

Class I covers products that perform functions important for cybersecurity but do not have as high a risk profile as Class II. The 19 categories listed for Class I in Annex III are:

Important Products: Class II (Annex III)

Class II contains products whose exploitation could have more serious and wider effects. Annex III lists four categories for this class:

• Hypervisors and container runtime systems (for example, server virtualisation platforms)
• Network firewalls, web application firewalls (WAF), anti-spam network gateways and intrusion detection/prevention systems (IDS/IPS)
• Tamper-resistant microprocessors
• Tamper-resistant microcontrollers

The last two categories cover chips designed to be protected against physical attacks such as side-channel analysis or fault injection.

Implementing Regulation (EU) 2025/2392 refers to the Common Criteria AVA_VAN vulnerability analysis levels in some definitions of tamper-resistant hardware. This criterion is used only to define the relevant categories; it does not bring every well-protected IT product into these categories.

Critical Products (Annex IV)

Under the CRA, critical products are products whose core functionality falls into a category in Annex IV. When updating Annex IV, the Commission takes into account whether essential entities under NIS2 critically depend on the product category and the risk that incidents could seriously disrupt critical supply chains across the internal market (Article 8(2)). Annex IV lists 3 categories:

1. Hardware devices with security boxes: Devices with physical tamper protection for the secure storage or processing of sensitive data or for cryptographic operations. Implementing Regulation (EU) 2025/2392 cites physical payment (POS) terminals, hardware security modules (HSMs) and tachographs as examples.
2. Smart meter gateways and other devices for advanced security purposes: Gateways within smart metering systems as defined in Directive (EU) 2019/944, and devices for advanced security purposes, including secure cryptoprocessing.
3. Smartcards and similar devices: Including secure elements.

Article 8(1) provides that the Commission may, by delegated act, require a European cybersecurity certificate at assurance level at least “substantial” for certain critical products. Unless such an act is adopted, critical products are subject to the same conformity procedures as Class II products. As of the date this guide was updated, no act has been adopted under Article 8(1).

Conformity Assessment Routes by Class

Article 32 determines which conformity assessment procedures each class may use. Module A is self-assessment based on internal production control; Module B+C (EU-type examination and conformity to type based on internal production control) and Module H (full quality assurance) require the involvement of a notified body.

There are two further special cases. For free and open-source software falling into an Annex III category, the manufacturer may use all procedures, including Module A, provided the technical documentation is made public when the product is placed on the market (Article 32(5)). In addition, the needs of micro, small and medium-sized enterprises are taken into account when notified body fees are set (Article 32(6)). For how the modules work, notified body selection and EU authorised representative coordination, see our CRA Conformity Assessment and Notified Body Preparation page.

CRA Implementation Timeline

The provisions on notified bodies (Chapter IV) have applied since 11 June 2026; the essential requirements and conformity assessment become mandatory on 11 December 2027. Since Class I (until harmonised standards are published), Class II and critical products will require working with a notified body, the time needed for body selection, the examination process and possible corrections should be planned now. The starting point for this planning is the classification decision.

How to Classify a Product under the CRA

In CRA product classification, the lists are checked starting from the highest risk class. We recommend the following order:

1. Scope check: Does the product contain digital elements capable of a direct or indirect data connection, and is it made available on the EU market in the course of a commercial activity? Products subject to sectoral regimes such as medical devices, type-approved motor vehicles, civil aviation and marine equipment are out of scope.
2. Defining the core function: Write down the product’s intended purpose and main function in one sentence. This definition must be consistent with the user manual, marketing material and technical documentation.
3. Annex IV check: Does the core function fall into one of the three categories in Annex IV? If so, the product is critical.
4. Annex III Class II check: If not, does the core function fall into one of the four categories in Class II?
5. Annex III Class I check: If not, does the core function fall into one of the 19 categories in Class I? Base your decision on the technical descriptions in Implementing Regulation (EU) 2025/2392.
6. Default class: If it falls into none of the categories, the product is in the default class.
7. Documenting the rationale: Put the decision in writing, together with the definition it relies on and the alternative categories considered, and keep it in the technical file. The conformity procedure chosen and, where applicable, the notified body details also appear in the EU Declaration of Conformity.

Borderline Cases and Common Mistakes

Classifying by component is the most common mistake. A Linux-based operating system or a VPN client in a product does not make it an operating system or VPN product. The reverse also holds: a component placed on the market separately (for example, a microcontroller with security functions) may itself fall within Annex III, but the end product using it is classified separately according to its own core function.

Marketing language can also affect classification. Promoting a product as a “security solution” or “smart security device” may be taken into account when assessing its intended purpose; the technical file and marketing material must be consistent with each other.

The class is not permanent. An update that adds a new main function to the product can change its class; the Commission can also update Annex III and Annex IV and will publish guidance under Article 26. Classification should therefore be reviewed at every major release.

Finally, planning self-assessment for Class I products by relying on harmonised standards that have not yet been published increases the risk of being caught in a notified body bottleneck as 2027 approaches.

Sector Examples for Turkish Manufacturers

The table below shows the likely classes of product types commonly encountered among manufacturers exporting from Türkiye to the EU. The final decision must be assessed separately for each product based on its core function and the technical descriptions in Implementing Regulation (EU) 2025/2392.

CRA Product Classification Analysis with Nesil Teknoloji

At Nesil Teknoloji, we carry out product classification either as the first phase of CRA compliance consulting projects or as a standalone service. Our typical workflow:

After classification, the product is validated against the Annex I requirements through CRA product security testing; for products requiring third-party assessment, we coordinate the relationship with the notified body in the EU.

Frequently Asked Questions

Official Sources

• Regulation (EU) 2024/2847, official text (EUR-Lex)
• Implementing Regulation (EU) 2025/2392, technical descriptions of important and critical products (EUR-Lex)
• European Commission, Cyber Resilience Act page
• ENISA (European Union Agency for Cybersecurity)