Skip to content
folhas.io
secure by design for connected products· Articles

Articles

Classifying the product under the CRA: the decision that sets the cost of everything else

Default, important class I, important class II or critical. The product's category determines whether conformity is a self-assessment or a notified body, and the difference is measured in tens of thousands of euros and months of calendar.

Published
Updated

Update note (23 Oct 2026). We corrected the assessment routes for class II and critical products, which were oversimplified, added the exception for free and open-source software and Implementing Regulation (EU) 2025/2392, and brought the state of the harmonised standards up to date.

Before any technical requirement, the CRA forces a framing question: which category does the product fall into? The answer determines the conformity assessment route and, with it, the cost, the timeline and the third-party dependency of the entire project.

The four categories

Default products. Everything not listed in the annexes. The manufacturer self-assesses under internal production control (the equivalent of Module A in classic CE assessments): it applies the essential cybersecurity requirements of Annex I, assembles the technical documentation, signs the EU declaration of conformity and affixes the CE marking. No third parties. The Commission estimates this is the case for around 90% of the products in scope.

Important, class I (Annex III). Nineteen categories, among them: identity and access management systems, browsers, password managers, VPNs, network management systems, SIEM, boot managers, PKI, physical and virtual network interfaces, operating systems, routers and switches, microprocessors and microcontrollers with security functionalities, smart home virtual assistants, smart home products with security functionalities (locks, cameras, alarms, baby monitors), connected toys with social interaction or location features, and health-monitoring wearables.

For class I, self-assessment is only available if a harmonised standard exists and is applied (or a common specification, or European certification) covering the requirements. Without an applicable harmonised standard, a notified body steps in: EU-type examination (Module B+C) or full quality assurance (Module H).

Important, class II (Annex III). Hypervisors and container runtimes, firewalls and intrusion detection/prevention systems, tamper-resistant microprocessors and microcontrollers. Here harmonised standards do not open up self-assessment: Article 32(3) allows EU-type examination (Module B+C), full quality assurance (Module H) or, where available and applicable, a European cybersecurity certification scheme at assurance level at least “substantial”. At the time of this revision, the delegated act specifying such schemes (Article 27(9)) had not yet been adopted, so in practice this means a notified body.

There is an exception for both classes of important products: products that qualify as free and open-source software may use any of the procedures, including internal control, provided the technical documentation is made public when they are placed on the market (Article 32(5)).

Critical (Annex IV). Hardware devices with security boxes, smart meter gateways, smartcards and secure elements. If a delegated act under Article 8(1) requires a European cybersecurity certificate (EUCC, for example) at assurance level at least “substantial”, that is the route. Until such an act exists, and none had been adopted by October 2026, the class II procedures apply (Article 32(4)).

Diagram: default products go to self-assessment; class I goes to self-assessment with a harmonised standard and to a notified body without one; class II goes, in practice, to a notified body; critical products go to European certification if a delegated act requires it and, without such an act, to a notified body.
From category to conformity route. The class I fork, with or without a harmonised standard, is where the schedule risk lives.

The most common misreading

The classification applies to the product being placed on the market, not to the components inside it. An agricultural sensor built on a microcontroller with a secure element does not become class I because of it: the one placing the MCU on the market is the MCU manufacturer. The right question is always “what is the core functionality of my product, as Annex III describes it?”. The binding delimitation is in Commission Implementing Regulation (EU) 2025/2392, which gives the technical description of each category in Annexes III and IV. The Commission guidance of 27 July 2026, C(2026) 5252, published after this text first appeared and not binding, devotes an entire section to these categories (section 6), because this is where most framing doubts live.

The case we run into most often: a generic IoT device (environmental monitoring, telemetry, agriculture) is typically a default product, and only becomes an important product if its core functionality matches an Annex III category. The locks, cameras and alarms in class I are smart home products with security functionalities, which the implementing regulation limits to products that protect the physical security of consumers in a residential setting. A camera or alarm on a farm does not automatically fall there, although an access control reader may fall under another class I category.

The schedule trap in the class I categories

For class I without a cited harmonised standard, the cheap route (self-assessment) closes. And the state of the CRA’s harmonised standards remains the biggest uncertainty in the process. In October 2026, no CRA standard had its reference published in the Official Journal, so there is not yet a presumption of conformity under Article 27. The vertical standards of standardisation request M/606 are in the approval phase: on 13 August, ETSI announced that 17 final drafts of the EN 304 6xx series (among them browsers, password managers, routers, smart home products, toys and wearables), submitted over the summer, were out to public enquiry, where anyone can read them, in a procedure whose end date varies, depending on the standard, between mid-September and mid-November 2026. Approval is followed by the Commission’s assessment and the publication of the reference in the Official Journal, and several will not be cited much before December 2027.

A class I manufacturer who planned for “Module A” may discover late that it needs a notified body, with indicative costs of EUR 15,000–50,000 and 6–12 months of calendar, in a market of notified bodies still being built: the regulation requires Member States to endeavour to have a sufficient number by 11 December 2026 (Article 35(2)), and at the latest public checks no body had yet been notified under the CRA.

The sensible way to manage this risk: decide the classification in writing, with reasoning, right at the design stage; track the state of the category’s standards; and have a budgeted plan B with a notified body in case the standard does not arrive in time.

What this means for manufacturers

  1. Classification is a business architecture decision: a feature added to the product that becomes its core functionality can change the category and multiply the cost of conformity.
  2. Documenting the reasoning behind the chosen category is part of the technical documentation; it is the first thing a market surveillance authority will want to see.
  3. For default products, the real work is in the essential cybersecurity requirements of Annex I and in the vulnerability handling process. Self-assessment involves no third party checking the work: the manufacturer declares conformity under its sole responsibility.

Sources