IN SHORT
A product with digital elements is an important product when its core functionality is that of a category listed in Annex III (class I or class II), and a critical product when its core functionality is that of a category listed in Annex IV (Article 7(1), Article 8(1)). The test applies to the product as a whole: integrating a component that belongs to one of those categories does not, in itself, change the procedure for the final product (Article 7(1)). Since 21 December 2025, each category also has a technical description, laid down in Commission Implementing Regulation (EU) 2025/2392, which should be read together with the Annexes. The classification decides which conformity assessment procedures of Article 32 the manufacturer may use for products placed on the market from 11 December 2027 (Article 71(2), first subparagraph).
Who classifies the product, and when
What the text requires
The classification follows from the Regulation itself: products with digital elements which have the core functionality of a product category set out in Annex III shall be considered to be important products with digital elements Article 7(1)
and are subject to the procedures in Article 32(2) and (3). For Annex IV, the Commission may require a European cybersecurity certificate by delegated act (Article 8(1), first subparagraph); Where no delegated acts as referred to in the first subparagraph of this paragraph have been adopted, products with digital elements which have the core functionality of a product category as set out in Annex IV shall be subject to the conformity assessment procedures referred to in Article 32(3). Article 8(1), second subparagraph
The manufacturer carries out the chosen conformity assessment procedures or has them carried out (Article 13(12), second subparagraph).
Our interpretation
Articles 7, 8 and 32 do not provide for any authority to classify an individual product before it is placed on the market. In our reading, the classification is therefore the manufacturer's own assessment, made when it selects the procedure, and open to scrutiny afterwards: by a notified body where one is involved, and by market surveillance authorities, to whom the technical documentation must remain available (Article 13(13)). Commission guidance, market surveillance practice or case law could refine how the criterion is applied.
Timing. Implementing Regulation (EU) 2025/2392 was adopted on 28 November 2025 under Article 7(4) and published in the Official Journal on 1 December 2025. Its Article 3 provides for entry into force on the twentieth day following publication, which is 21 December 2025; it sets no separate, later date of application. The procedures that depend on the classification, however, apply from the general date of application, 11 December 2027 (Article 71(2), first subparagraph), and products placed on the market before that date are subject to the Regulation's requirements only if they undergo a substantial modification from that date (Article 69(2)). The rules on notified bodies, which carry out the third-party procedures, apply from 11 June 2026 (Article 71(2), second subparagraph).
The method, step by step
- Confirm that the product is in scope. Classification only matters for a product with digital elements that is made available on the market and not excluded. See our scope guide.
- Define the product as you place it on the market. A product with digital elements includes its remote data processing solutions, and a component placed on the market separately is a product in its own right (Article 3, point (1)). Recital 3 of 2025/2392 states that the stricter procedures apply if that product as a whole is an important or critical product.
- State its core functionality in one or two sentences, consistent with the intended purpose stated in your instructions, marketing and technical documentation (Article 3, point (23)).
- Compare it with each candidate category, reading the title in Annex III or IV together with the technical description in 2025/2392: Annex I of that act for classes I and II, Annex II for critical products (Article 2 of 2025/2392). The lists of products in each description use the formula "includes but is not limited to", and the examples are provided for illustrative purposes only and are not an exhaustive list (recital 7 of 2025/2392).
- Apply the integration rules of Article 7(1) and recitals 3 to 5 of 2025/2392 (summarised below).
- Settle the class. If the core functionality matches a class II or Annex IV description, the stricter procedures apply; if it matches only a class I description, the conditions of Article 32(2) decide whether internal control remains available.
- Check special regimes: free and open-source software (Article 32(5)), high-risk AI systems (Article 12(3)) and products classified as EHR systems (see below).
- Record the reasoning in the technical documentation (see the last section).
Our interpretation
"Core functionality" is not defined in Article 3. In our reading, it is the function the product is essentially designed and placed on the market to perform, not every function it is capable of performing; this is how recitals 4 and 5 of 2025/2392 apply the notion. Because the intended purpose is defined by reference to the manufacturer's instructions, promotional or sales materials and technical documentation (Article 3, point (23)), we expect the way a product is described and marketed to weigh in any later review of its classification.
The criteria in Article 7(2) (functions critical to the cybersecurity of other products, or functions carrying a significant risk of adverse effects) explain why the categories were chosen and guide the Commission when it amends Annex III (Article 7(3), first subparagraph). In our reading they are not a separate test for individual products: a product that matches no listed category is not an important product merely because it meets one of those criteria.
Our interpretation
Where a product's core functionality genuinely matches categories in different classes, in our reading the stricter procedure applies: Article 32(3) and Article 32(4) attach to the product falling under class II or Annex IV, whatever other category it also matches. The texts do not address this case expressly (see the open questions below).
What Implementing Regulation (EU) 2025/2392 contains
The Commission was required to adopt, by 11 December 2025, an implementing act specifying the technical description of the categories of products with digital elements under classes I and II as set out in Annex III Article 7(4)
and of the Annex IV categories (Article 7(4)). Implementing Regulation (EU) 2025/2392 is that act. It has three articles and two annexes:
- Article 1 defines "Common Criteria" and "Common Evaluation Methodology" by reference to Implementing Regulation (EU) 2024/482, which establishes the European Common Criteria-based cybersecurity certification scheme (EUCC).
- Article 2 provides that the technical descriptions of the Annex III categories are set out in its Annex I, and those of the Annex IV categories in its Annex II.
- Article 3 concerns entry into force (see above).
The annexes describe the same categories as Annexes III and IV, in the same order. The implementing act does not add, move or withdraw categories; that can only be done by delegated acts under Article 7(3) and Article 8(2), which provide for transitional periods.
Its recitals set out how the Commission applies the core-functionality criterion:
- Core functionality decides whether a product meets a technical description, and therefore the applicable procedures (recital 2).
- Integration. A product is subject to the stricter procedures only if it is an important or critical product as a whole. Integrating an embedded browser into a news app for smartphones does not in itself subject the app to the procedure for browsers, but the manufacturer must still demonstrate that the app as a whole meets the essential requirements, considering, as appropriate, the security of the embedded browser (recital 3).
- Additional functions do not take a product out of its category. An operating system with a calculator or a simple graphics editor, an operating system integrating browser functionality, or a router integrating firewall functionality, still has the core functionality of an operating system or a router (recital 4).
- Ability is not core functionality. A product able to perform a category's functions whose core functionality itself is different from that of such product category is not to be considered to meet the technical description of that product category. Security orchestration, automation and response (SOAR) software is "generally" not a SIEM; a smartphone is "generally" neither an operating system nor a password manager (recital 5).
- The essential requirements apply regardless. Every manufacturer carries out the risk assessment of Article 13(2) and (3), whether or not the product is important or critical (recital 6; Article 13(3)).
- AVA_VAN levels from the Common Criteria and Common Evaluation Methodology are used to separate the chip categories, and may be expressed by reference to the latest or older versions of those standards (recital 8).
The categories and their technical descriptions
The summaries below paraphrase the technical descriptions; words in quotation marks are verbatim from 2025/2392. They are not a substitute for the full text.
Important products, class I (Annex III, Part I; 2025/2392, Annex I, class I)
| Category | What the technical description covers |
|---|---|
| 1. Identity management and privileged access management | Products providing authentication or authorisation, possibly with lifecycle management of identity credentials, for persons, devices or systems, including access control to digital resources or physical locations. Lists single sign-on, federated identity, one-time password and multi-factor authentication software, TAN generators, biometric and access control readers. |
| 2. Standalone and embedded browsers | Software letting end users access, render and interact with web content (typically a browser engine, HTTP and HTTPS support, scripts, cookies). Expressly includes embedded browsers "intended for integration into another system or application" and "browsers with AI agent integration". |
| 3. Password managers | Products that store passwords locally or on a remote server, including generation, sharing and integration with applications; includes browser-extension, enterprise and hardware-based password managers. |
| 4. Anti-malware software | Software that detects or searches for, removes or quarantines malicious software (viruses, worms, ransomware, spyware, trojans); includes real-time and manual scanners, rootkit detection, and rescue disks whose core functionality is that task. |
| 5. VPN products | Products that establish an encrypted logical tunnel constructed from the resources of a physical or virtual network: VPN clients, servers and gateways. |
| 6. Network management systems | Products that manage connected network elements (servers, routers, switches, workstations, printers, mobile devices) by monitoring them and controlling their network operations and configuration, including software-defined networking controllers. |
| 7. SIEM systems | Products that collect data from multiple sources, analyse and correlate it, and present it as actionable information for security purposes such as threat and incident detection, forensics or compliance. No list of examples. |
| 8. Boot managers | Software managing initial start-up after power-on or restart (initialising hardware, handing over to the operating system, selecting boot options); includes UEFI firmware and single- and multi-stage boot loaders. |
| 9. PKI and certificate issuance software | Products used in a public key infrastructure to manage the life cycle of digital certificates or of the associated keys; includes key and certificate management systems, OCSP responders and all-in-one PKI solutions. |
| 10. Physical and virtual network interfaces | Hardware adapters with firmware that connect a device to a network through a driver interface, typically at the data link layer, and virtual interfaces that emulate it. Lists Wi-Fi, Ethernet, USB, Bluetooth, Zigbee and Fieldbus adapters, virtual network interface cards, container network interfaces and VPN interfaces. |
| 11. Operating systems | Software that provides an abstract interface to the hardware and controls the execution of software; real-time, general-purpose and special-purpose operating systems. |
| 12. Routers, internet modems and switches | Routers select routes between networks (including virtual routers); internet modems convert signals for IP-based communication (fibre, DSL, cable, satellite, cellular); switches forward packets "and that have a management plane": managed, smart, multilayer and programmable switches, and bridges such as wireless access points. |
| 13. 14. 15. Microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities | Integrated circuits that additionally provide security functionalities (encryption, authentication, secure key storage, random number generation, trusted execution environment and the like) aimed at securing other products, networks or services beyond the chip itself, such as a secure boot chain or secure communication interfaces. |
| 16. Smart home general purpose virtual assistants | Products communicating on the public internet that process natural-language prompts (spoken or written) and, on that basis, give access to services or control connected devices in residential settings; includes smart speakers with an integrated assistant. |
| 17. Smart home products with security functionalities | Remotely controllable products that protect the physical security of consumers in a residential setting (door locks, baby monitors, alarms, home security cameras), "as well as hardware and software that centrally control such products". |
| 18. Internet-connected toys | Toys covered by Directive 2009/48/EC that communicate on the public internet and either have inbound and outbound communication technology (keyboard, microphone, speaker, camera) or can track or infer the location of the toy or its user. Detecting mere proximity is not location tracking. |
| 19. Wearables | Products worn on the body that can regularly or continuously sense and process information relevant to the user's health, excluding products within Regulations (EU) 2017/745 and 2017/746 (fitness trackers, smartwatches, smart jewellery and clothing); and wearables for individuals under the age of 14, such as child safety wearables. |
Important products, class II (Annex III, Part II; 2025/2392, Annex I, class II)
| Category | What the technical description covers |
|---|---|
| 1. Hypervisors and container runtime systems | Hypervisors abstract or allocate computing resources and run, manage and orchestrate logically separated virtual machines (type 1, type 2 and hybrid, including nested virtualisation). Container runtimes manage the execution and lifecycle of containers running as isolated processes on a single host operating system. |
| 2. Firewalls, intrusion detection and prevention systems | Firewalls protect a network or system by monitoring and restricting traffic, including web application firewalls, filters and anti-spam gateways. Intrusion detection systems monitor traffic that has entered the network (network- or host-based); intrusion prevention systems are detection systems that actively respond. |
| 3. 4. Tamper-resistant microprocessors and microcontrollers | The class I microprocessors or microcontrollers (points 13 and 14) with tamper evidence, resistance or response, which are additionally "designed to provide protection of AVA_VAN level 2 or 3". |
Critical products (Annex IV; 2025/2392, Annex II)
| Category | What the technical description covers |
|---|---|
| 1. Hardware devices with security boxes | Hardware made of multiple discrete components that securely stores, processes or manages sensitive data or performs cryptographic operations, inside a physical envelope providing tamper evidence, resistance or response. Lists physical payment terminals, hardware security modules and tachographs that meet the description. |
| 2. Smart meter gateways and other devices for advanced security purposes | Gateways controlling communication between a smart metering system (as defined in Directive (EU) 2019/944) and authorised third parties such as utilities; they handle meter or personal data, provide cryptography and firewalling, and can control other devices. Electricity gateways are covered; gas or heat gateways may be, "provided that the gateway meets this description". |
| 3. Smartcards or similar devices, including secure elements | Secure elements are microcontrollers or microprocessors with tamper-protected security functions, typically handling credentials or cryptography, "designed to provide protection of at least AVA_VAN.4", discrete or integrated into a system on chip (for example TPMs and eUICCs). Smartcards are secure elements in a card or other carrier (identity documents, payment, access and tachograph cards, payment wristbands). |
Our interpretation
Read together, the chip categories form a ladder: an integrated circuit with security functionalities protecting more than itself is class I; a microprocessor or microcontroller that is also tamper-resistant and designed for AVA_VAN level 2 or 3 is class II; a secure element designed for at least AVA_VAN.4 is critical. The descriptions refer to the level the product is designed to provide, not to a certificate already obtained. A chip whose security functions protect only the chip itself does not appear to meet the class I description, since that description requires functionalities aimed at securing other products, networks or services.
Borderline cases addressed by the texts
These cases come from the CRA and from 2025/2392 themselves; they are not market claims.
- Embedded browser: app versus component. The news app of recital 3 is not in the browser category, but an embedded browser "intended for integration into another system or application" is. A supplier placing such a component on the market separately is therefore dealing with a class I product (Annex III, Part I, point 2, Article 3, point (1)).
- Integrated firewall. Firewalls and intrusion detection or prevention systems need a third-party assessment, but
This is not the case for other products with digital elements not categorised as important products with digital elements which may integrate firewalls or intrusion detection or prevention systems. Recital 45
- Toys that only detect proximity. Where the toy merely detects the proximity of the user or of other toys by using sensing technologies, the toy is not to be considered to have location tracking features (2025/2392, Annex I, class I, point 18).
- Medical wearables. Health-monitoring wearables within Regulation (EU) 2017/745 or 2017/746 are excluded from point 19; wearables for children are those for individuals under 14 (2025/2392, Annex I, class I, point 19).
- Rescue disks. Only those "with the core functionality of searching, removing or quarantining malicious software" are listed under anti-malware (2025/2392, Annex I, class I, point 4).
- Smart home hubs and apps. Point 17 also covers hardware and software that centrally control smart home security products (2025/2392, Annex I, class I, point 17).
- Gas and heat meters. Gateways for gas or heat metering may be critical products if they meet the gateway description (2025/2392, Annex II, point 2).
Our interpretation
The switch description refers to switches "that have a management plane", and lists managed, smart, multilayer and programmable switches. In our reading, a switch with no management plane does not meet the class I description of point 12, although it remains subject to the essential requirements like any other product in scope. A firmware update that adds a management interface would call for the classification to be revisited.
Consequences for conformity assessment
What the text requires
| Classification | Procedures available | Provision |
|---|---|---|
| Not listed in Annex III or IV | Any procedure of Article 32(1), including internal control (module A) | Article 32(1) |
| Important, class I | Internal control only for the essential requirements covered by harmonised standards, common specifications or European cybersecurity certification schemes (assurance level at least "substantial") that the manufacturer has applied in full; for the other requirements, EU-type examination (module B) with module C, or full quality assurance (module H) | Article 32(2) |
| Important, class II | Module B with module C, module H, or, where available and applicable, a European cybersecurity certification scheme at assurance level at least "substantial"; internal control is not available | Article 32(3) |
| Critical (Annex IV) | A European cybersecurity certification scheme in accordance with Article 8(1); where its conditions are not met, any procedure of Article 32(3) | Article 32(4), Article 8(1), second subparagraph |
For class II, the recitals state that the conformity assessment should always involve a third party, even where the product complies fully or partly with harmonised standards, common specifications or European cybersecurity certification schemes Recital 91
. A delegated act under Article 8(1) must provide for a transitional period of at least six months, unless a shorter one is justified for imperative reasons of urgency (Article 8(1), third subparagraph).
Special regimes:
- Free and open-source software in Annex III may use any procedure of Article 32(1), including internal control, if the technical documentation is made public when the product is placed on the market (Article 32(5)). See our open-source guide.
- High-risk AI systems that are also important or critical products, and to which the internal control procedure of Annex VI to the AI Act (Regulation (EU) 2024/1689) applies, follow the CRA procedures as far as the essential cybersecurity requirements are concerned (Article 12(3)).
- EHR systems. Regulation (EU) 2025/327 (European Health Data Space) inserts an Article 32(5a) for products classified as EHR systems; see our timeline guide.
The modules, notified bodies, the EU declaration and the CE marking are explained in our conformity assessment guide.
What to record in the technical documentation
What the text requires
The technical documentation must contain all relevant data on the means used to meet Annex I and at least the elements of Annex VII (Article 31(1)). Several of those elements bear directly on classification: the intended purpose (Annex VII, point 1(a)), the cybersecurity risk assessment (Annex VII, point 3), and the list of harmonised standards, common specifications or certification schemes applied, specifying the parts applied where they were applied only in part (Annex VII, point 5). The EU declaration of conformity names the notified body and describes the procedure performed, where applicable (Annex V, point 7). The documentation is kept up to date, where appropriate, at least during the support period (Article 31(2)).
Good practice (recommendation, not a legal requirement)
Keep a short classification record in each technical file. It is not a separately named legal requirement, but it makes the choice of procedure traceable:
- the product and versions assessed, and its core functionality in one or two sentences, matching the intended purpose in your instructions and marketing;
- each category considered, with the wording of the 2025/2392 description you relied on to include or exclude it;
- integrated components that fall within an Annex III or IV category, and how their security is taken into account in the assessment of the whole product;
- the conclusion (not listed, class I, class II or critical), the procedure chosen and, for class I, which standards or schemes were applied in full;
- for chips, the AVA_VAN level the product is designed for and the evidence for it;
- the events that will trigger a review: a change of core functionality or marketing, an amendment to Annex III or IV, or a delegated act under Article 8(1).
Open questions
Uncertain / awaiting guidance
- Core functionality is not defined in the CRA. The recitals of 2025/2392 use "generally" for SOAR software and smartphones, which leaves room for products whose core functionality is less clear-cut.
- Products matching categories in different classes (for example a device marketed both as a router and as a firewall) are not addressed expressly by Article 7, Article 32 or 2025/2392.
- "Other devices for advanced security purposes, including for secure cryptoprocessing" appear in the title of Annex IV, point 2, but the technical description in Annex II, point 2, of 2025/2392 describes only smart meter gateways. How such other devices are to be identified is not spelled out.
- AVA_VAN levels. The chip descriptions turn on the level a product is "designed to provide". The texts do not say how a manufacturer that has no certificate should demonstrate that design target.
- Article 8(1) delegated acts. When we checked the records of the Publications Office of the EU on 2 November 2026, the Commission acts recorded as adopted on the basis of the CRA were Delegated Regulation (EU) 2025/1535 (on certain products within the scope of Regulation (EU) No 168/2013), Implementing Regulation (EU) 2025/2392 and Delegated Regulation (EU) 2026/881 (on when the CSIRT receiving a notification may delay its dissemination to other CSIRTs). None is a delegated act under Article 8(1), so critical products currently fall under Article 8(1), second subparagraph. Check again at the time of assessment; the Commission must keep a list of delegated and implementing acts adopted under the CRA (Article 26(2), second subparagraph). We have not verified here which harmonised standards or certification schemes are available.
- Future amendments. Annexes III and IV can be amended by delegated act (Article 7(3), Article 8(2)). The CRA does not say how the technical descriptions would then be updated.
Fictional example — Acme Networks
Acme Networks, a fictional company, sells three products. The first is a home router with a built-in packet filter. Acme records that its core functionality is routing between the home network and the internet (class I, point 12). It also asks whether the packet filter makes the router a class II firewall, and concludes that it does not, citing recitals 4 and 5 of 2025/2392, while noting the question in its record. The second is a five-port desktop switch with no configuration interface. Acme notes that the description of switches refers to switches "that have a management plane", concludes that its switch does not meet it, and checks that no other category applies. The third is a firewall appliance for small offices, whose core functionality is protecting a network by monitoring and restricting traffic: class II, point 2. Acme plans a notified-body procedure for it and contacts notified bodies early. Each conclusion goes into the relevant technical file.
What to do next
Good practice (recommendation, not a legal requirement)
List your products, write down the core functionality of each, and check it against the technical descriptions in Implementing Regulation (EU) 2025/2392 before choosing a procedure. Then read our conformity assessment guide for the procedure that applies.