What "important" and "critical" mean in the CRA: the product tiers in plain English

The Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) sorts products into three tiers: default, important (in two classes, I and II) and critical. If you have never read a regulation, the labels sound like a scale of how much the law expects of you. They are not. This guide explains what the tiers actually change, with device examples for each. It is a documentation aid, not legal advice.

The one thing that changes: who checks your work

Every in-scope product must meet the same essential requirements in Annex I, with the same vulnerability handling, technical documentation, declaration of conformity and CE marking. The tier changes the conformity assessment: the procedure by which you show that the product meets those requirements before you sell it.

There are two kinds of procedure (Article 32 and Annex VIII):

• Self-assessment ("internal control", module A): you test, document and sign yourself.
• Third-party assessment: a notified body, an independent test house appointed by a Member State to assess products under a specific EU law, examines the design ("EU-type examination", module B, followed by module C for production) or audits your whole quality system ("full quality assurance", module H). Or a European cybersecurity certification scheme, where one applies.

The tier decides which of those you may use.

How a product lands in a tier

By its core functionality, not by its parts. Three kinds of statement follow, and they do not weigh the same: the law, the Commission's reading of it, and our own examples.

The law (evidence). Article 7(1): a product with the core functionality of a category in Annex III is important, and "the integration of a product with digital elements which has the core functionality of a product category set out in Annex III shall not in itself render the product in which it is integrated subject to" the stricter procedures. The Commission has published what each category covers in Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 (published 1 December 2025), as Article 7(4) required. Its recital 3 gives the same rule by example: building an embedded browser into a news app "does not in itself render the news app subject to" the procedure for browsers. Read the description for any category you think you might be in.

The Commission's reading (a draft, not binding). The CRA uses "core functionality" without defining it. The Commission's guidance on applying the CRA, C(2026) 5252, says so itself (point 138) and gives a definition in point 139: a product's core functionality is its "main features and technical capabilities, without which it would not be able to meet its intended purpose". Point 139 adds that it can be assessed taking into account what the maker says "in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation". A product "may not have more than one core functionality" for choosing the assessment procedure (point 144), so it lands in one tier only. On built-in parts, point 141 reads Article 7(1) this way, and applies the same logic to critical products: "the mere integration of an important or critical product with digital elements does not in itself render the product with digital elements an important or critical product with digital elements". Its example 58 is a smartphone that integrates an operating system: the phone as a whole has a different core functionality, so integrating the operating system does not make it an operating-system product.

How much weight to give that: the guidance is a draft whose content the Commission approved on 27 July 2026. It is not yet formally adopted, and it is not binding (point 8). We cite it as the Commission's reading, not as law. We read its section 6 (points 136 to 155) on 13 October 2026.

Our examples (argument). A thermostat running a real-time operating system is not an "operating system" product; a sensor built on a microcontroller with security features is not a "microcontroller with security-related functionalities" product. These two are ours, not the Commission's; they follow the pattern of its smartphone example. The chip and OS vendors carry those categories; you carry yours.

The hard cases

Everything in this subsection is the Commission's reading in the draft guidance (not binding, point 8), not the text of the Regulation.

• More than the category. A product can look like a listed category, yet its core functionality may "substantially exceed" that of the category (point 142). Example 59: security orchestration, automation and response (SOAR) software can do what a security information and event management (SIEM) system does, but incident response is a core part of what it is, so it is "generally not considered to have the core functionality of SIEM systems".
• Less than the category. Or it can "fall substantially short" of it (point 142). Example 60: a log collection and visualisation tool that does no data correlation and gives no actionable security insights is generally not a SIEM system either.
• Extras do not move you out. Additional functions that "merely complement or enhance" a core functionality that matches a category leave the product in that category (point 142).
• The answer follows the product, not the brochure. The assessment rests on the product's main features and technical capabilities "and not on the way in which the product with digital elements is described or marketed", where the description does not reflect what the product technically is (point 142). A maker "may not misrepresent the core functionality of its product with digital elements" to escape the stricter procedures; the sign the guidance names is "clear inconsistencies between promotional materials, instructions for use, and technical documentation" (point 143).
• Modules sold separately. If you also sell a module of your product on its own, "offered for separate purchase, licensing or subscription", that module is a product in its own right and is classified by its own core functionality (point 145). A module supplied only inside the product is not: there the core functionality "is determined at the level of the integrated product with digital elements". Example 61: a security suite whose SIEM, intrusion detection and analytics modules are also offered by separate subscription has one class I module, one class II module and one default module.

Default: most connected devices

A product that is not in Annex III or Annex IV is a default product. Most connected devices are here: an environmental sensor, a smart light bulb, a connected coffee machine, a label printer, a USB peripheral, an industrial data logger (examples ours: check each against Annexes III and IV).

What you may do: any procedure in Article 32(1), including self-assessment under module A. You may still choose a notified body, but you do not have to.

Important, class I: 19 categories

Annex III lists 19 class I categories. For a hardware maker, the ones that come up most are:

• Smart home products with security functionalities (Annex III, class I, point 17): smart door locks, security cameras, baby monitoring systems and alarm systems are named in the text itself. Regulation 2025/2392 describes them as products that "protect the physical security of consumers in a residential setting and which can be controlled or managed remotely".
• Routers, modems intended for the connection to the internet, and switches (point 12): a home Wi-Fi router, an LTE modem, a managed switch.
• Internet connected toys with "social interactive features (e.g. speaking or filming)" or location tracking (point 18): a talking doll that connects to the internet.
• Personal wearable products with a health monitoring purpose outside the medical device rules, or intended for children (point 19): a fitness tracker, or a child's GPS watch. Regulation 2025/2392 defines "children" here as under 14.
• Smart home general purpose virtual assistants (point 16): a smart speaker with a voice assistant.
• Operating systems (point 11), boot managers (point 8) and microcontrollers with security-related functionalities (point 14): these matter if you sell the OS, the bootloader or the chip, not if you build on one.

The other categories are mostly software and IT products: identity and access management, browsers, password managers, anti-malware, VPNs, network management, SIEM systems, PKI software, network interfaces, security-capable microprocessors and ASICs or FPGAs.

What you may do (Article 32(2)): self-assessment is open only if you apply in full a harmonised standard, a common specification or a European cybersecurity certification scheme at assurance level at least "substantial". Otherwise a notified body is required (module B with C, or module H). A harmonised standard is a European standard whose reference the Commission has published in the Official Journal for this law; applying it gives a "presumption of conformity". When we last checked, we found no harmonised standard cited under the CRA in the Official Journal, so a class I product today has no self-assessment route through one (the date of that check is in step 5 of "What to do" below).

What will matter once a standard is cited (the Commission's reading; draft, not binding, point 8). "Apply in full" is one condition of two. Point 149 of the guidance: for a class I product to be eligible for self-assessment, "(i) all the applicable requirements of a relevant harmonised standard need to be applied; and (ii) the standard’s scope needs to cover at least all the cybersecurity risks associated to that product’s core functionality". Functions beyond the core do not close the route. Where the standard does not cover them, you still assess their risks, document the additional measures you took for them (points 150 and 151) and may use self-assessment for the whole product. What you lose is narrower: the presumption of conformity reaches only the risks the standard covers, so such products "may therefore not benefit from presumption of conformity for those additional functionalities" (point 155). Example 63: a router that integrates a firewall component still has the core functionality of a router; a harmonised standard covering the risks of the router's core functionality, with additional measures for the firewall function, keeps self-assessment open for the whole product. The guidance says the same goes for common specifications and certification schemes (footnote 25). None of this changes anyone's route today, because no harmonised standard is cited yet.

One exception: free and open-source software in this class may use any procedure in Article 32(1), self-assessment included, if its technical documentation is public when it is placed on the market (Article 32(5)).

Important, class II: 4 categories

Annex III class II has four categories: hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers. Examples (ours): a firewall appliance for a small office, an intrusion detection sensor, a tamper-resistant microcontroller sold as a chip and designed to resist attackers at Common Criteria level AVA_VAN 2 or 3.

For the two chip categories the line is a resistance level. Only a chip designed to resist attackers at AVA_VAN 2 or 3 is class II; designed for AVA_VAN 4 or higher, it is a secure element, which is critical (Annex IV, point 3). That is the Commission's description in Implementing Regulation (EU) 2025/2392, Annex I, class II, points 3 and 4. So the chip in a bank card or an identity card is on the Annex IV side of the line, not here (example ours).

What you may do (Article 32(3)): a notified body (module B with C, or module H), or a European cybersecurity certification scheme at assurance level at least "substantial" where one is available. You may not assess the product yourself, whatever standards you apply, unless it is free and open-source software whose technical documentation is public when it is placed on the market: that software may use any procedure in Article 32(1), self-assessment included (Article 32(5)).

Critical: Annex IV, 3 categories

Annex IV has three:

• Hardware devices with security boxes. Regulation 2025/2392 describes devices that "securely store, process, or manage sensitive data or perform cryptographic operations" inside a tamper-evident or tamper-resistant physical envelope, and names physical payment terminals, hardware security modules and tachographs as examples.
• Smart meter gateways within smart metering systems, and other devices for advanced security purposes, including secure cryptoprocessing.
• Smartcards or similar devices, including secure elements. Regulation 2025/2392 describes a secure element as a chip designed to resist attackers at Common Criteria level AVA_VAN 4 or higher.

What you may do: Article 8(1) lets the Commission require a European cybersecurity certificate at assurance level at least "substantial" for these, by delegated act. Where no such act has been adopted, the class II procedures apply (Article 8(1) and Article 32(4)). We found no such delegated act when we last checked (the date is in step 5 of "What to do" below). The open-source exception in Article 32(5) names Annex III only, so it does not reach critical products.

The tiers on one screen

Tier	Where listed	Self-assessment?	Typical example
Default	Not listed	Yes (module A)	Environmental sensor
Important, class I	Annex III, 19 categories	Only with a harmonised standard, common specification or scheme applied in full, or if it is free and open-source software whose technical documentation is public (Article 32(5))	Smart door lock, home router
Important, class II	Annex III, 4 categories	No, unless it is free and open-source software whose technical documentation is public (Article 32(5))	Firewall appliance
Critical	Annex IV, 3 categories	No; certification may become mandatory	Payment terminal, secure element

Two details that change the answer

Open-source software. Free and open-source software in an Annex III category may use any procedure in Article 32(1), self-assessment included, if its technical documentation is public when it is placed on the market (Article 32(5)). That holds for class I and class II alike. It does not hold for critical products: Article 32(5) names the Annex III categories only.

Same obligations, different paperwork. An important product does not have extra essential requirements. It has a different route to showing it meets them, and where a notified body is involved, its name, number and the certificate it issued go on your declaration of conformity (Annex V).

What to do

1. Write down your product's core functionality in one sentence (one only; the definition is under "How a product lands in a tier" above), then read Annexes III and IV and the descriptions in Regulation 2025/2392 against it. Our scope check asks four scope questions first (whether you supply the product in the EU as part of a business, whether it can connect to a device or network, whether a sector law or another exclusion applies, and what your customer actually gets), and then the categories, strictest list first: Annex IV, then Annex III class II, then class I.
2. Whatever tier you land in, record the core functionality in your technical documentation. Annex VII, point 1(a) asks for the product's intended purpose there (evidence), and the Commission's guidance draws the conclusion: "The product’s core functionality should therefore be clearly identified", so that market surveillance authorities can check the right procedure was followed (point 144; draft, not binding). If you land in default, also record why you are not in Annex III or IV; we expect it to be the first question an authority asks (argument). Getting the route wrong has a price: the guidance notes that not meeting the obligations in Article 32 "may trigger administrative fines in accordance with Article 64(3)" (point 146), the paragraph whose ceiling is €10 million or, for an undertaking, 2% of worldwide annual turnover, whichever is higher.
3. If you land in class I, plan for a notified body now, unless your product is free and open-source software whose technical documentation is public (Article 32(5)): until a harmonised standard is cited, or a common specification or certification scheme is available for the CRA (the Commission's timeline plans a delegated act on the EUCC scheme for Q4 2026), that is in practice the only route (argument), and the CRA rules for appointing notified bodies have applied only since 11 June 2026 (Article 71(2)).
4. If you land in class II or critical, contact notified bodies early, and watch for an Article 8(1) delegated act. The one class II product that need not is free and open-source software whose technical documentation is public (Article 32(5)).
5. Before you look for a notified body, know that there is not one yet. Notified bodies today: when we last checked (8 October 2026), no notified body had been designated under the CRA in the Commission's NANDO database, so there is not yet one to apply to. Article 35(2) asks Member States to strive to have enough notified bodies by 11 December 2026; that is a target, not a promise. Check NANDO again before you plan your assessment.

What is settled and what is not

Settled (evidence): the Annex III and IV lists, the core-functionality rule in Article 7(1), the assessment routes in Article 32, and the category descriptions in Implementing Regulation (EU) 2025/2392.

The Commission's reading, in a draft that is not yet adopted: what "core functionality" means and how to judge it, including the hard cases (points 139 to 145), what getting the route wrong can cost (point 146), and how a harmonised standard that covers only part of a product works for class I (points 147 to 155). All of it is section 6 of the guidance C(2026) 5252, whose content the Commission approved as a draft on 27 July 2026. It is not binding, and a draft can still change before it is adopted (argument); point 8 says "An authoritative interpretation of the CRA may only be given by the Court of Justice of the European Union".

Not settled, at the check dated in step 5 above: we found no harmonised standard cited under the CRA in the Official Journal, no Article 8(1) delegated act requiring certification for critical products, and no notified body designated under the CRA. The first two change the routes for class I and critical products; the third decides whether there is anyone to carry out a third-party assessment. We update this guide when they land.