CRA Annex IV Critical Products: The Three Categories Explained (2026)

The EU’s Cyber Resilience Act (CRA) sorts products with digital elements into four levels: default, important Class I, important Class II and critical. The critical level is the shortest list in the Regulation. Annex IV names just three categories of products, all of them built around protecting keys, credentials and sensitive data at the hardware level.

Because the list is so short, it is also the most misunderstood. Many guides describe Annex IV as a catch-all for “high-risk” technology: connected devices, industrial controllers, software supply chains, update servers, even medical devices. None of those are on it. If your product is not one of the three categories below, it is not a critical product, and treating it as one wastes budget on a conformity route you do not need.

This guide walks through the real CRA Annex IV critical products list: what each category covers according to the official technical descriptions in Commission Implementing Regulation (EU) 2025/2392, what being critical means for conformity assessment, how Annex IV differs from Class I and Class II in Annex III, what is often wrongly assumed to be critical, and what to do if your product may be on the list.

Table of Contents

What Annex IV Actually Lists

Annex IV of Regulation (EU) 2024/2847 contains three entries, and nothing else:

Hardware devices with security boxes
Smart meter gateways within smart metering systems as defined in Directive (EU) 2019/944, and other devices for advanced security purposes, including for secure cryptoprocessing
Smartcards or similar devices, including secure elements

The annex itself is only a list of headings. What each heading means in practice is set out in Commission Implementing Regulation (EU) 2025/2392, adopted under Article 7(4) of the CRA and in force since 21 December 2025. It gives a technical description for every category in Annexes III and IV, and it is the text to rely on when classifying a product, ahead of any guide, including this one.

Core functionality decides, not components

A product falls into a category when its core functionality is that of the category. Integrating a listed component does not, on its own, move the whole product into that category. A router with a TPM is still a router, and a smartphone with an embedded SIM is not a secure element. The manufacturer still has to show that the product as a whole meets the essential requirements, which includes accounting for the security of the components inside it. The examples in the implementing regulation are illustrative, not exhaustive.

In Regulus, free for manufacturers: classify your product by its core function, with the exact Annex III or IV point.

1. Hardware Devices with Security Boxes

This category covers hardware products that securely store, process or manage sensitive data or perform cryptographic operations, and that are made of multiple discrete components enclosed in a physical envelope. That envelope provides tamper evidence, tamper resistance or tamper response as a countermeasure against physical attacks. The defining feature is the box: the protection is designed into the housing around the electronics, not only into the chips.

What falls in

The implementing regulation names three examples, provided they meet the description:

Physical payment terminals, the card readers and PIN entry devices used at points of sale.
Hardware security modules (HSMs) that generate and manage cryptographic keys and other cryptographic elements.
Tachographs, the recording devices fitted to commercial vehicles.

What does not

A ruggedised industrial enclosure, a locked cabinet or a sealed consumer device is not a “security box” in this sense. The category is about products whose purpose is to protect secrets and cryptographic operations, with physical tamper countermeasures built in for that reason. A gateway or controller that happens to sit in a sturdy housing does not qualify.

Is your product Class I, Class II or default?

Classify it in Regulus by its core function, with the exact Annex III or IV reference. The requirements, risk assessment and technical file follow from the answer. Free for manufacturers.

Classify your product free

2. Smart Meter Gateways and Other Advanced Security Devices

Smart meter gateways are the products that control communication between the components of a smart metering system, or devices connected to it, and authorised third parties such as utility providers. According to the technical description, they collect, process and store meter or personal data, protect data flows by supporting specific cryptographic needs such as encryption and decryption, incorporate firewalling functions and provide the means to control other devices.

Electricity first, but not only

The reference point is the smart metering system for electricity as defined in Directive (EU) 2019/944. The implementing regulation adds that gateways used in smart metering systems for other energy sources, such as gas or heat, can also fall into this category, provided the gateway meets the same description.

The category is the gateway, not every meter. A meter that simply measures and reports is not named; what matters is whether the device performs the gateway role described above. If you build metering equipment with integrated communication, compare its core functionality with that description before concluding either way.

“Other devices for advanced security purposes”

The second half of the heading, other devices for advanced security purposes including for secure cryptoprocessing, has no separate example list in the implementing regulation. Treat it with care: it is not an open door for any product with security features, and a claim that a product belongs here should be argued from its core functionality, not from the presence of encryption.

3. Smartcards and Secure Elements

Secure elements are microcontrollers or microprocessors with security-related functions, including tamper evidence, resistance or response, that typically store and process cryptographic operations or sensitive data such as identity or payment credentials. The technical description sets a clear threshold: they are designed to provide protection of at least AVA_VAN.4 as defined in the Common Criteria and the Common Evaluation Methodology. They can be discrete chips or be integrated into a system on chip, and they may run their own operating system and applications.

Named examples include Trusted Platform Modules (TPMs) and embedded UICCs (eUICC).

Smartcards and similar devices are secure elements built into a carrier, usually a plastic card but potentially other shapes. The implementing regulation lists identity and travel documents, qualified signature cards, replaceable UICCs (SIM cards), physical payment cards, physical access cards, digital tachograph cards and wristbands with an integrated payment secure element.

The chip ladder: Class I, Class II or critical

Semiconductors are where Annex III and Annex IV meet, and one catalogue can land on three different levels:

Microprocessors and microcontrollers with security-related functionalities (Annex III, Class I), when those functions protect something beyond the chip itself, such as secure boot, a trusted execution environment or secure communications.
Tamper-resistant microprocessors and microcontrollers (Annex III, Class II), designed for an AVA_VAN.2 or AVA_VAN.3 level of resistance.
Secure elements (Annex IV, critical), designed for AVA_VAN.4 or higher.

A general-purpose microcontroller without such security functions stays in the default category.

What Being Critical Means for Conformity Assessment

Being on Annex IV does not add new essential requirements. Critical products meet the same Annex I requirements as every other product with digital elements. What changes is how conformity has to be demonstrated.

European cybersecurity certification, where a delegated act requires it

Under Article 8(1), the Commission may adopt delegated acts that require products in an Annex IV category to obtain a European cybersecurity certificate at assurance level at least “substantial” under a scheme adopted under the Cybersecurity Act, Regulation (EU) 2019/881. This is only possible where such a scheme covers the category and is available to manufacturers, and the delegated act must give at least six months of transition unless urgency justifies less.

If there is no delegated act: the Class II procedures

Where no such delegated act applies, Article 8(1) and Article 32(4) send critical products to the same procedures as Class II products: EU-type examination followed by conformity to type (modules B and C), full quality assurance (module H), or a European cybersecurity certification scheme at assurance level at least “substantial” where one is available and applicable. In every case, self-assessment under module A is not an option. A notified body or a certification scheme is involved.

The list can also change. Article 8(2) allows the Commission to add or withdraw Annex IV categories by delegated act, based on criteria such as the critical dependency of essential entities under NIS2 on the category, or the risk that incidents could seriously disrupt critical supply chains. For the full picture of routes by class, see our guide to CRA conformity assessment and the overview of notified body requirements.

Critical vs Important: Annex IV Compared with Class I and Class II

Most products that people assume are “critical” are in fact important products under Annex III, or default products. The difference matters, because each level has its own conformity route.

Level	Where it is listed	Examples from the Regulation	How conformity is demonstrated
Default	Everything in scope that is not in Annex III or IV	Most connected consumer and industrial products, business software, general-purpose microcontrollers	Internal control (module A), self-assessed by the manufacturer
Important, Class I	Annex III, 19 categories	Routers, modems and switches; operating systems; browsers; password managers; VPN products; smart locks, security cameras and alarm systems for the home; microcontrollers with security functions	Module A only if harmonised standards, common specifications or a certification scheme at “substantial” level are applied in full; otherwise modules B+C or module H
Important, Class II	Annex III, 4 categories	Hypervisors and container runtime systems; firewalls and intrusion detection or prevention systems; tamper-resistant microprocessors and microcontrollers	Modules B+C, module H, or a European certification scheme at “substantial” level
Critical	Annex IV, 3 categories	Payment terminals, HSMs and tachographs; smart meter gateways; smartcards, TPMs and other secure elements	European cybersecurity certificate at “substantial” level or higher where a delegated act requires it; otherwise the Class II procedures

For a closer look at the boundary between the two important classes, read our comparison of Annex III Class I vs Class II.

What Is Not on the Annex IV List

These are the most common misreadings we see, and why they are wrong:

Connected IoT devices in general. A smart thermostat, a connected appliance or an industrial sensor is a default product unless its core functionality matches a category in Annex III or IV. Some consumer products are Class I, such as smart home products with security functions and connected toys with social interaction or location features, but none of them are critical.
Industrial controllers, PLCs and IoT gateways. They are not listed in Annex IV, and not in Annex III either, unless their core function is one of the listed ones, for example a router or a firewall. A gateway that translates Modbus to MQTT is not a smart meter gateway.
Routers, firewalls and network equipment. These are important products under Annex III (routers in Class I, firewalls and IDS/IPS in Class II), not critical ones.
The software supply chain. Libraries, SDKs, open-source components and firmware are not an Annex IV category. Tracking them is an obligation for every product, through the software bill of materials.
Processes. Vulnerability handling, secure updates, security testing and technical documentation are obligations that apply at every level. They are not products and they are not “critical categories”.
Medical devices. Products covered by the Medical Devices Regulation (EU) 2017/745 or the In Vitro Diagnostic Regulation (EU) 2017/746 are outside the CRA altogether. Vehicles type-approved under Regulation (EU) 2019/2144 are also excluded, although that exclusion covers the regulated finished product, not everything sold to the automotive sector.

Obligations That Apply Whatever the Class

Classification decides the conformity route. It does not decide whether you have to do the underlying work. Every manufacturer of a product in scope, critical or not, has to:

Meet the essential requirements in Annex I, both Part I on the properties of the product and Part II on vulnerability handling.
Carry out and maintain a cybersecurity risk assessment under Article 13. Our guide to the CRA risk assessment explains what it should contain.
Draw up a software bill of materials covering at least the top-level dependencies, in a machine-readable format. See the CRA SBOM requirements.
Handle vulnerabilities, with a coordinated vulnerability disclosure policy and a contact address for reports. More in CRA vulnerability handling.
Deliver security updates securely throughout the support period. See CRA update requirements.
Report actively exploited vulnerabilities and severe incidents under Article 14. These obligations have applied since 11 September 2026, including for products already on the market: an early warning within 24 hours, a notification within 72 hours and a final report, submitted through the single reporting platform to the coordinating CSIRT and ENISA.
Determine and declare a support period that reflects how long the product is expected to be in use. It is at least five years, unless the product is expected to be in use for less. For long-lived equipment such as payment terminals or HSMs, the expected time in use is the starting point, not the five-year minimum.
Keep the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period if that is longer.

What to Do If Your Product Might Be Critical

If any of the three categories sounds close to your product, work through the question in this order:

Write down the core functionality of the product as a whole, in one or two sentences, before looking at the annexes. Not the components, not the marketing features.
Compare it with the technical descriptions in Implementing Regulation (EU) 2025/2392, starting with Annex IV and then Annex III. For chips, check the vulnerability analysis level the product is designed for (AVA_VAN.2 or 3 versus AVA_VAN.4 or higher).
Record the reasoning. The classification, the reference to the annex point and the reasons belong in your technical documentation, and they will be the first thing a notified body or authority asks about.
Check whether a delegated act under Article 8(1) applies to your category. If it does, plan for European cybersecurity certification. If it does not, plan for a notified body under modules B+C or H.
Start the conversation with a notified body early. The provisions on notified bodies have applied since 11 June 2026, and the CRA applies in full from 11 December 2027. Capacity for third-party assessment may be tight as that date approaches.
Do not wait for the route to start the work. The risk assessment, SBOM, vulnerability handling process and technical documentation are needed whichever procedure applies.

Key takeaways

Annex IV has three categories: hardware devices with security boxes, smart meter gateways and other advanced security devices, and smartcards or similar devices including secure elements.
The official meaning of each category is in Implementing Regulation (EU) 2025/2392, with examples such as payment terminals, HSMs, tachographs, TPMs, eUICCs and payment cards.
Critical products need a European cybersecurity certificate where a delegated act requires one; otherwise they follow the Class II procedures with a notified body.
Generic IoT, industrial controllers, network equipment, software components and processes are not critical products. Medical devices are outside the CRA.

Not sure whether your product is default, Class I, Class II or critical? Regulus is a free platform for manufacturers: it classifies each product with the exact Annex III or IV reference, walks you through the Annex I requirements, builds the risk assessment and SBOM, tracks the Article 14 reporting deadlines and generates the nine CRA documents in Word. An expert review is available as a paid option. Regulus does not certify products. Start at Regulus.