CRA Important and Critical Product Classes, Explained
Under the EU Cyber Resilience Act, the conformity route your product must take is decided almost entirely by which class it falls into. Get the classification wrong and you either over-engineer a light-switch or, far worse, self-declare a product that the regulation says needed a notified body. Before you plan a single control, you need to know whether your device is default, important, or critical — because those three words carry very different obligations.
The three tiers and why they exist
The CRA applies to nearly all “products with digital elements” placed on the EU market — hardware and software that can connect, directly or indirectly, to a device or network. Every such product must meet the same set of essential cybersecurity requirements in the regulation’s annexes. What changes across the tiers is not the requirements themselves but how you are allowed to prove you meet them.
The logic is risk-based. A product whose compromise would cascade — because it sits at a trust boundary, protects other systems, or runs in sensitive environments — gets a stricter path to market. The tiers are named default (the large unlisted majority), important (split into Class I and Class II), and critical. The higher the tier, the less latitude you have to simply declare conformity yourself.
Default: the unlisted majority
If your product is not named in the regulation’s lists of important and critical categories, it sits in the default tier. This is where most consumer IoT lands — a connected sensor, a smart appliance, a fitness tracker. For these, the manufacturer may use internal control of production: you self-assess against the essential requirements, compile the technical documentation, and issue the EU declaration of conformity yourself. No notified body is required. That is a real advantage, but it is not a free pass — the essential requirements still apply in full, and market surveillance authorities can demand your documentation and test the product.
Important (Class I and Class II): security-relevant functions
The important tier captures products that perform a security-relevant function or whose compromise would materially affect other devices. Think password managers, network management systems, and — highly relevant to embedded teams — microcontrollers and microprocessors that carry security-related functions, boot managers, and secure elements. The tier is subdivided: Class I products can reach conformity by applying a harmonised standard (once such standards exist) under internal control, while Class II products carry a heavier expectation and generally point toward third-party assessment.
The practical trap is assuming a small device cannot be “important.” A general-purpose MCU with a security function does not become default just because it is cheap. If your bill of materials includes a secure element, a hardware security module, or a smartcard-class chip, you are very likely touching this tier. The same trust-boundary thinking that drives the broader EU Cyber Resilience Act obligations for hardware makers is what the classification is testing for.
Critical: the strictest path
The critical tier is the small set of products the Commission considers so central to cybersecurity that it can require a European cybersecurity certification scheme as the route to conformity. Categories discussed here include hardware devices with security boxes, smart meter gateways within smart metering systems, and smartcards or similar secure elements. For these, self-declaration is off the table; you follow the designated certification path. The list is deliberately short, and the Commission retains power to update it, so the correct posture is to re-check the current legal text rather than rely on an early draft.
| Class | Typical products | Conformity route |
|---|---|---|
| Default (unlisted) | Most consumer IoT, smart appliances, sensors | Self-assessment (internal control) |
| Important — Class I | Password managers, VPNs, routers, security-relevant MCUs | Self-assessment if harmonised standard applied |
| Important — Class II | Firewalls, IDS/IPS, tamper-resistant microprocessors | Third-party assessment expected |
| Critical | Secure elements, smart meter gateways, hardware security modules | European cybersecurity certification may be mandated |
How to classify your own device
Work top-down against the current legal text. First check whether your product matches any critical category; if so, that path governs. If not, check the important categories — and check each component, not just the finished product, because a security function anywhere in the stack can pull you up a tier. If nothing matches, you are default. Document that reasoning: a market surveillance authority can ask why you concluded a product was default, and “it was not obviously on the list” is a weak answer without a written analysis of the categories you considered and rejected.
Classification is a judgement call at the boundaries, and the boundaries are exactly where products land in practice. A structured threat model that maps your device’s security functions and trust boundaries makes the classification defensible and doubles as the technical documentation the CRA already expects. If you would like a second set of eyes on where your product sits and what conformity route follows, that is precisely the kind of question we work through with clients — reach out through our contact page.
