Part 1
Why CRA Product Classification Matters
The Cyber Resilience Act divides all products with digital elements into three tiers: default, important, and critical. The tier your product falls into is not a label — it determines the conformity assessment procedure you must follow before you can affix the CE marking and place your product on the EU market. Get the classification wrong and you may have followed the wrong procedure entirely, with consequences ranging from having to redo your compliance work to market withdrawal.
Classification is also the first practical decision you need to make in any CRA compliance project. It determines which standards apply, whether a notified body must be involved, and how much your compliance work will cost. A manufacturer with ten products classified as default will face a very different compliance burden than one with the same ten products classified as Class I important. The question is not an academic exercise.
Most manufacturers placing connected products on the EU market will be default products. But for those whose products fall into one of the 26 named categories — and a significant number will — understanding the classification rules is essential before any other compliance work begins.
CRA Conformity Assessment Routes and Modules Explained
Article 32 of the CRA sets out the conformity assessment procedures available to each product tier. The table below shows which procedures apply and when. For tiers that require third-party involvement, the manufacturer can choose between Module B+C and Module H. A European cybersecurity certification scheme (such as the EUCC) is separately available under Article 27(9) of the CRA and can substitute for or complement the module-based routes depending on the tier and whether a relevant scheme is in force.
| Module | Type | Default | Class I | Class II | Critical |
|---|---|---|---|---|---|
| Module A | Self-assessment | only if hEN fully applied | — | — | |
| Module B+C | Notified body — EU-type examination | only if no EUCC scheme available | |||
| Module H | Notified body — full quality assurance | only if no EUCC scheme available | |||
| EUCC | Testing lab — European cybersecurity certificate | assurance level at least substantial | assurance level at least substantial |
What each procedure involves
Internal control — self-assessment
The manufacturer carries out the entire conformity assessment internally with no notified body involvement. They prepare technical documentation, draw up an EU Declaration of Conformity, and affix the CE marking. Where a harmonised standard does not fully cover all applicable essential requirements, the manufacturer must address the gap and document how each uncovered requirement is met.
For Class I products, Module A is only available when a harmonised vertical standard has been fully applied. Without a fully applied harmonised standard, Class I manufacturers must use Module B+C or H.
EU-type examination — notified body, product by product
Module B — A notified body examines the design and development of the product and issues an EU-type examination certificate. Module C — The manufacturer declares conformity to the approved type and affixes the CE marking.
Module B+C is assessed per product type. It is well suited to manufacturers placing a limited number of product types on the market. Manufacturers who need a notified body can choose this route or Module H — the decision typically depends on portfolio size and how frequently products change.
Full quality assurance — notified body, system level
The manufacturer implements a comprehensive quality management system covering design, development, and production, assessed by a notified body. Once the system is approved, each new or substantially modified product can be placed on the market without a fresh per-product assessment — only the quality system is re-evaluated periodically.
Module H carries a higher upfront investment than Module B+C but lower per-product cost at scale. It is particularly efficient for manufacturers placing many product types on the market or making frequent updates.
European cybersecurity certification scheme
A European cybersecurity certification scheme — the EUCC being the primary example — is not a CRA module. It is a certification route under Regulation (EU) 2019/881 (the Cybersecurity Act) that can be used to demonstrate conformity with CRA essential requirements where the scheme meets at least the "substantial" assurance level referenced in Article 27 of the CRA. Assessment is carried out by an accredited testing laboratory rather than a CRA notified body.
Obtaining EUCC certification is not mandatory — it is one option among several. Manufacturers determine the appropriate procedure based on their product's risk profile and use context. For Critical products, a European cybersecurity certification scheme under Article 8(1) is the primary route where one is available and applicable; where no such scheme applies, the procedures in Article 32(3) — Module B+C or H — are used instead.
Notified bodies for CRA conformity assessment are not yet formally designated. Manufacturers should monitor the NANDO database as designations are made by Member States ahead of the December 2027 deadline.
Further reading: For a complete guide to CRA compliance timelines, standards, and the three compliance pillars, see our EU Cyber Resilience Act: A Complete Preparation Guide for Manufacturers.
Part 2
The Core Functionality Principle
Before working through the 26 category descriptions, there is one legal concept that overrides everything else and that manufacturers consistently misunderstand: classification is determined by core functionality, not by capability, not by component composition, and not by product name. Understanding this principle is more important than memorising any individual category description.
CRA Article 7(1): The Core Functionality Rule
Article 7(1) of the CRA states that the core functionality of a product with digital elements determines whether that product meets the technical description of a category of important or critical products. This is reinforced by Article 8(1), which applies the same principle specifically to critical products.
Commission Implementing Regulation (EU) 2025/2392 , which provides the technical descriptions of each category, develops this principle across several recitals. Recital 3 explains that when manufacturers integrate components into their products — components that may themselves meet the description of an important or critical category — this does not automatically render the containing product subject to the higher conformity assessment procedure. What matters is whether the product as a whole is an important or critical product.
"A product with digital elements is subject to the conformity assessment procedures applicable to important or critical products with digital elements, if that product as a whole is an important or critical product as set out in Annexes III and IV to that Regulation."
— Recital 3, Commission Implementing Regulation (EU) 2025/2392
Recital 4 adds a further dimension: a product that performs functions additional to those described in a category does not thereby fall outside that category. The presence of ancillary functions — a calculator, a simple graphics editor, browser functionality within an operating system — does not disqualify a product from being classified as whatever its core functionality indicates. The question is always what the product primarily is, not everything it can do.
Ancillary vs Core Functionality in the CRA
Recital 5 of Implementing Regulation (EU) 2025/2392 addresses the opposite case: a product that has the ability to perform the functions of an important or critical category, but whose core functionality is something different, is not classified under that category. This is a critical distinction for manufacturers of complex products.
A useful test: ask what the product exists to do, and what a customer is primarily paying for. If the answer matches a category description, classification follows. If the matching functionality is subordinate to the product's primary purpose — enabled as a feature, integrated as a component, or present as a side-effect of the architecture — it is ancillary and does not drive classification.
CRA Classification Examples from Commission Implementing Regulation (EU) 2025/2392
Implementing Regulation (EU) 2025/2392 provides three concrete examples that are worth examining in detail, as they illustrate the kind of reasoning required.
The news app with an embedded browser
A news application for smartphones that integrates an embedded browser component to render web content is not a browser under the CRA. The browser is ancillary to the product's core functionality, which is delivering news content. The news app manufacturer must still ensure the whole product meets applicable cybersecurity requirements — including considering the security of the embedded browser — but it does not need to follow the conformity assessment procedure applicable to browsers. The embedded browser itself, if placed on the market as a standalone product, would be classified as a browser.
SOAR software and SIEM systems
Security orchestration, automation and response (SOAR) software often performs functions that overlap with SIEM systems — collecting data, analysing it, and presenting actionable security information. But SOAR's core functionality is orchestration and automation of security responses, not security information and event management. SOAR products are therefore generally not classified as SIEM systems, even though they can perform SIEM-like functions. The regulation explicitly uses this example to illustrate that functional capability alone does not determine classification.
The smartphone with an integrated password manager
A smartphone typically integrates components performing the functions of several important product categories — an operating system, an integrated password manager, and often browser functionality. None of these classifications attach to the smartphone, because none of them is the smartphone's core functionality. The smartphone exists to provide mobile computing and communication capabilities. Its integrated credential storage is ancillary, however capable it may be.
What these examples share is a consistent analytical approach: identify what the product is primarily designed and marketed to do, then ask whether that primary purpose matches a category description. If yes, the product is classified accordingly. If the matching function is incidental to a different primary purpose, it does not drive classification.
Practical implication: When assessing your product, start with an honest description of what it is — not what it can do. If your product description starts with "it's a [category name]," classification is likely straightforward. If it starts with "it's a [something else] that also does [category function]," the category function is probably ancillary.
Part 3
Important Products with Digital Elements — Class I
Annex III Class I lists 19 product categories. Products in this class can self-assess via Module A where a harmonised vertical standard is fully applied. The 19 categories are defined by the technical descriptions in Annex I to Commission Implementing Regulation (EU) 2025/2392 .
1. Identity Management Systems and Privileged Access Management Software and Hardware
Identity management systems are comprehensive platforms that handle the full lifecycle of digital and physical identities—covering individuals, organizations, devices, and services. They provide capabilities for identity registration, credential issuance and provisioning, attribute and entitlement management, synchronization across directories, and deregistration or deprovisioning. Core functions include authentication (verifying an asserted identity) and authorization (enforcing what that identity can access), implemented via policies, role-based or attribute-based access controls, and integration with applications, cloud services, and physical access control systems. Modern identity systems often support single sign-on (SSO), federation (SAML, OIDC, OAuth), identity brokering, directory services, self-service workflows (password reset, profile updates), and lifecycle automation to reduce manual errors and latency. They also incorporate logging and reporting for compliance and can interact with hardware authenticators and biometric readers to enforce stronger or multi-factor authentication as required by risk policies.
Privileged access management (PAM) software focuses specifically on governing, monitoring, and protecting accounts and sessions that have elevated capabilities or access to sensitive systems and data. PAM solutions typically include credential vaulting (securely storing and rotating privileged credentials), just-in-time access provisioning and session-based elevation to minimize standing privileges, fine-grained policy controls to restrict actions, and comprehensive session recording and audit trails for forensic and compliance purposes. They may offer workflow-driven approval processes, real-time monitoring and alerting for anomalous privileged activity, and integration with identity management platforms for consistent identity context and lifecycle handling.
No vertical standard is yet available for this category. Manufacturers should prepare using the horizontal standards (prEN 40000-1-2 for risk assessment, prEN 40000-1-3 for vulnerability handling, prEN 40000-1-4 for product security) and monitor ETSI working group outputs for the category-specific standard when it becomes available.
2. Standalone and Embedded Browsers
Standalone browsers are full-featured software applications that allow users to navigate, render, and interact with web content and online services hosted on networked servers. They incorporate a browser engine to parse and display markup (e.g., HTML/CSS), an execution environment for client-side scripts (e.g., JavaScript), networking stacks supporting web protocols (HTTP, HTTPS, WebSocket), and user-facing features such as tabbed browsing, bookmarks, extensions, developer tools, privacy controls, and persistent storage (cookies, localStorage). Security and performance features (e.g., sandboxing, same-origin policy enforcement, certificate validation, content security policy) are typically built in to protect users and the host system. Modern standalone browsers also integrate privacy modes, sync services for user data across devices, and may incorporate AI agents that assist with tasks like summarization, form filling, content recommendations, or contextual search while enforcing local or remote privacy and policy controls.
Embedded browsers are browser engines or lightweight rendering components integrated into other applications, devices, or systems to provide web-capable UI and content interaction without launching a separate browser app. Common examples include WebView components in mobile apps, in-vehicle infotainment systems, smart TV apps, kiosk software, and enterprise applications that embed web dashboards. Embedded browsers expose APIs for the host application to control navigation, inject scripts, manage cookies and storage, and mediate permission prompts (camera, microphone, geolocation). Security considerations differ from standalone browsers because the host application's privileges and the embedding context influence isolation, update cadence, and attack surface; therefore, careful sandboxing, permission governance, content filtering, and regular engine updates are essential.
3. Password Managers
Password managers are software (and sometimes hardware) products that securely store and manage authentication credentials and related secrets for users and organizations. They provide encrypted storage for passwords, passphrases, secure notes, and other secrets either locally on a device or in cloud-hosted vaults, and typically protect that vault with a master password, hardware key, biometric unlock, or a combination (multi-factor authentication).
Main functions include secure generation of strong, unique passwords; autofill and auto-submit of credentials into websites and applications; organized vaults and folders or tags for credential grouping; secure note storage; and versioning or history to recover previous credentials. Password managers also implement cryptographic best practices for encryption, key derivation, and secure transport, and include features such as password strength assessment, breach monitoring, and automated password change or rotation where supported.
4. Software that Searches for, Removes, or Quarantines Malicious Software
This category covers software typically referred to as antimalware and antivirus, designed to detect, prevent, remove, or isolate malicious code and maintain device and system integrity, confidentiality, and availability. They can use multiple detection techniques, such as signature-based matching against known malware fingerprints, heuristic and behavior-based detection to flag suspicious actions (file modifications, unusual network activity, process injection), machine-learning models for anomaly detection, and sandboxing or emulation to safely execute and analyze unknown samples.
Main capabilities include real-time (on-access) scanning of files, processes, and network traffic; scheduled and on-demand full-system scans; quarantine and secure deletion of confirmed threats; rootkit detection and low-level system scanning; and rescue/bootable disks or environments for offline remediation when the primary OS is compromised.
5. Products with the Function of Virtual Private Network (VPN)
VPN products establish encrypted logical tunnels using resources from physical or virtual networks. The category covers VPN clients, VPN servers, and VPN gateways. These products encapsulate and encrypt traffic between endpoints or between an endpoint and a network, protecting data confidentiality and integrity as it traverses untrusted or shared infrastructure. They handle key management, encryption/decryption, authentication, and session lifecycle management to ensure that only authorized parties can create or join a tunnel, and they may support multiple protocols and cipher suites to meet varying security and compatibility requirements.
The defining characteristic is that creating and maintaining encrypted tunnels for secure network communication is the product's primary function. Products that use VPN technology as part of a broader network infrastructure — for example, a router that supports VPN passthrough or a firewall that can terminate VPN connections — may not fall into this category if VPN is ancillary to their core function.
6. Network Management Systems
Products with digital elements that manage connected network elements perform continuous discovery, monitoring, and control of devices such as servers, routers, switches, workstations, printers, and mobile devices. They can collect telemetry and status information to maintain an accurate inventory and to observe health, performance, and usage trends across the network. Using that visibility, these products push and enforce configurations, apply policies (for access, routing, QoS, and security), and perform software or firmware updates to ensure devices remain compliant and operational. Beyond basic monitoring and configuration, these systems can orchestrate complex workflows and automate routine operational tasks, such as provisioning new devices, responding to incidents, and executing multi-step maintenance procedures with minimal human intervention.
The scope is explicitly about managing other network elements, not monitoring a product's own network connectivity. A router that shows its own traffic statistics is not a network management system. A product whose primary function is to provide centralised visibility and control over an organisation's network infrastructure is.
7. Security Information and Event Management (SIEM) Systems
SIEM systems ingest various data such as telemetry and log data from a wide range of sources — including network devices, servers, applications, endpoints, cloud services, identity providers, and security controls — to create a centralized, time-ordered record of activity across an environment. They normalize and enrich raw events with contextual information (asset data, threat intelligence, user identity, geolocation, and vulnerability status) so disparate signals can be understood together. SIEMs support efficient searching, historical analysis, and evidence preservation needed for investigations and compliance reporting.
On top of data collection and enrichment, SIEMs apply correlation rules, statistical models, and behavioral analytics to detect suspicious patterns, anomalies, and signs of compromise in near real time. When potential threats are identified, SIEMs generate prioritized alerts and provide investigative workflows, timelines, and visualizations that enable security teams to triage incidents, perform root-cause analysis, and reconstruct attacker activity for forensics.
The SOAR/SIEM example discussed in Part 2 is directly relevant here. SOAR software performs someSIEM-like functions but its core functionality is orchestration and automation of security responses.The regulation explicitly uses SOAR as an example of a product that is generally not a SIEM forclassification purposes, even where it collects, analyses, and presents security data. Similarly,network monitoring tools and compliance-only tools that do not perform correlation across multiplesources are generally not SIEMs.
8. Boot Managers
Boot managers are software components that control the initial steps a system takes immediately after power-on or a restart, serving as the bridge between raw hardware and the operating system. They perform hardware initialization tasks such as configuring processor modes, memory controllers, and essential peripherals, run self-tests, and prepare low-level services required by higher-level software. Once hardware and basic platform services are ready, boot managers locate, verify, and load the operating system kernel or a secondary boot stage, transferring execution in a controlled manner while preserving system state and enforcing integrity checks where supported.
Beyond basic startup sequencing, boot managers provide mechanisms for selecting among multiple boot options and execution pathways—choosing alternate kernels, recovery images, network boot sources, or diagnostic environments—often exposing user interfaces, boot menus, or automated policies for unattended systems.
This category is notable because it covers software that is typically deeply embedded in hardware products and not sold as a standalone product. Manufacturers of hardware products whose firmware includes a boot manager should assess whether the boot manager constitutes the core functionality of a separately placed product. Where firmware is bundled with hardware and not placed on the market as a separate software product, the hardware product as a whole governs the classification analysis.
9. Public Key Infrastructure and Digital Certificate Issuance Software
Products in the public key infrastructure (PKI) and digital certificate issuance category provide the software services and controls necessary to establish, maintain, and operate trust relationships based on asymmetric cryptography. They handle certificate lifecycle activities including certificate signing request (CSR) intake, identity vetting, certificate issuance, distribution, renewal, and revocation, as well as publishing revocation information (CRLs) or providing real-time revocation checks via OCSP responders. These systems also implement policy and profile enforcement—ensuring certificates are issued with appropriate key usage, validity periods, and extensions—and maintain audit logs and compliance records required for regulatory or organizational governance.
The scope is specifically about managing certificates or keys for others — operating as part of a PKI infrastructure. A product that uses digital certificates for its own TLS communications or for authenticating its own users is not a PKI product under this category. The product must be managing the certificate lifecycle as its reason for existing.
10. Physical and Virtual Network Interfaces
Physical network interfaces are hardware-backed products that provide a device's direct access to a network by exposing an API through device drivers, typically operating at the physical and data-link layers. They include network interface cards, radio modules, controllers, and media adapters for technologies such as Ethernet, Wi‑Fi, Bluetooth, USB networking, Fieldbus, IrDA, or Zigbee. These devices combine firmware, hardware PHYs, MACs, transceivers, and driver stacks to handle link establishment, framing, error detection, flow control, and low-level offloads (checksum, segmentation) so the host can transmit and receive packets with predictable timing and hardware-accelerated performance.
Virtual network interfaces implement the same driver-facing APIs and link-layer semantics as physical interfaces but without dedicated physical transmission hardware; they provide logical connectivity inside a host, hypervisor, or container environment and map to physical or overlay transport systems. Examples include virtual NICs presented to virtual machines, container network interfaces, software bridge interfaces, tun/tap devices, and VPN endpoint interfaces. Virtual interfaces can perform packet encapsulation/decapsulation, virtual switching, VLAN/QoS tagging, and namespace isolation, and they integrate with hypervisors, container runtimes, and network virtualization overlays to deliver isolation, policy enforcement, and programmable networking.
11. Operating Systems
Operating systems are foundational software that abstract underlying hardware details and coordinate the execution of application and system software. They initialize and manage core platform resources—CPU scheduling, memory allocation, storage access, and device I/O—so that multiple processes and threads can run safely and efficiently. By implementing drivers, kernel services, and runtime libraries, an OS mediates access to peripherals and storage, enforces isolation and protection boundaries between processes, and provides primitives for interprocess communication, synchronization, and error handling that applications rely on. The category covers real-time operating systems, general-purpose operating systems, and special-purpose operating systems.
The regulation explicitly notes that operating systems often include software performing ancillary functions — calculators, simple graphics editors, browser functionality — and that this does not disqualify a product from being an operating system. Conversely, a smartphone whose integrated operating system is a component of a mobile computing device is not an operating system for classification purposes — the smartphone's core functionality is mobile computing and communication.
12. Routers, Modems Intended for the Connection to the Internet, and Switches
This category covers three distinct product types under one heading. Routers establish and control the flow of data between different networks using routing protocol mechanisms and algorithms at the network layer — covering wired and wireless routers, virtual routers, and routers with integrated modems. Modems convert analogue signals to and from digital signals for IP-based communication — covering fibre modems, DSL modems, cable (DOCSIS) modems, satellite modems, and cellular modems. Switches provide connectivity between networked devices through packet forwarding and have a management plane — covering managed switches, smart switches, multilayer switches, virtual security switches, programmable SDN switches, and wireless access points functioning as bridges.
A combined router-modem device can be classified as both a router and a modem simultaneously, since both are genuine core functionalities of the product. A router that incorporates firewall functionality is still classified as a router — the firewall is an additional capability, as the regulation itself notes in Recital 4.
13. Microprocessors with Security-Related Functionalities
Microprocessors with security-related functionalities are integrated circuits that perform central processing tasks while embedding specialized hardware and low-level firmware to support security services. In addition to core features like instruction execution, interrupt handling, and memory management that rely on external memory and peripherals, these processors include dedicated engines or accelerators for cryptographic operations (AES, RSA/ECC, hashing), hardware random number generators, trusted execution environment and secure key storage mechanisms. They may expose microcode, privileged firmware interfaces, and hardware-backed isolation domains that enable efficient, tamper-resistant cryptographic processing without exposing sensitive key material to general-purpose software.
The critical qualifier is that the security functionalities must aim to secure other products, networks, or services beyond the microprocessor itself. Security functions that only protect the microprocessor's own operation do not satisfy this condition. Examples of qualifying security purposes include supporting a secure boot chain, providing secure virtualisation, or offering secure communication interfaces for the systems in which the microprocessor is integrated.
14. Microcontrollers with Security-Related Functionalities
Microcontrollers with security-related functionalities are integrated circuits that combine a processor core with onboard memory (flash, ROM, and RAM) and built-in peripherals (timers, GPIO, serial interfaces) to form a self-contained, programmable system. In addition to executing application code and low-level firmware, security-enhanced microcontrollers include dedicated hardware for cryptographic operations (AES, ECC, hashing), true random number generators, protected key storage, and often lightweight secure execution zones or trust anchors. These features let developers implement encrypted communications, authenticate devices, protect firmware and keys in constrained environments, and support secure boot and firmware update chains without requiring separate external security modules.
15. Application Specific Integrated Circuits (ASIC) and Field-Programmable Gate Arrays (FPGA) with Security-Related Functionalities
ASICs are integrated circuits fully or partially custom-designed for a specific function or application. FPGAs are characterised by a matrix of configurable logic blocks designed to be reprogrammable after manufacturing. Both qualify for this category when they additionally provide hardware-based security functionalities — encryption, authentication, secure key storage, random number generation, trusted execution environment, or other protection mechanisms — aimed at securing other products, networks, or services beyond the ASIC or FPGA itself.
As with categories 13 and 14, the security functions must be directed outward — protecting systems beyond the chip — not inward. A general-purpose ASIC or FPGA without dedicated security features for external protection does not qualify, and a complete system containing such an ASIC or FPGA is not classified under this category.
16. Smart Home General Purpose Virtual Assistants
Smart home general-purpose virtual assistants are software-driven products that accept natural language input—voice, text, or both—and interpret user intents to perform tasks, answer questions, and coordinate services over the public Internet. They combine speech recognition or NLP pipelines, intent classification, dialogue management, and backend connectors to translate informal user requests into actions such as playing media, setting reminders, searching the web, controlling smart devices, or querying calendars and services. These assistants typically run a mix of local processing (wake-word detection, basic command handling) and cloud processing (intent resolution, large-language understanding, third-party API calls), and they expose developer platforms and integrations that enable third-party skills, routines, and device adapters to extend capability across a wide range of residential use cases. Named examples include smart speakers with integrated virtual assistants and standalone virtual assistants meeting this description.
Four conditions must all be met for classification: the product must communicate on the public internet; it must process natural language inputs; it must respond by providing services or controlling connected devices; and it must operate in a residential smart home context. A virtual assistant that does not communicate on the public internet — processing entirely locally — does not fall into this category. A smartphone or tablet with a virtual assistant feature as an integrated component is not classified here, as the core functionality is mobile computing.
17. Smart Home Products with Security Functionalities
Smart home security products are devices and associated software designed to protect people and property within residential environments. They can combine sensors, actuators, cameras, microphones, network connectivity, and user-facing control interfaces to detect, deter, and respond to physical-security events such as unauthorized entry, privacy breaches, fire/smoke, or distress situations. These systems can operate locally, in the cloud, or a hybrid of both, and they expose management interfaces for homeowners, integrators, and emergency services to configure behavior, view status, and receive alerts. Named examples include smart door locks, baby monitoring systems, alarm systems, and home security cameras.
Two conditions must both be met: the product must protect physical security in a residential setting, and it must be capable of remote control or management. A physical door lock without remote connectivity does not qualify. A general smart home device with only peripheral security features — such as smart lights or smart plugs — whose primary purpose is convenience or energy management rather than physical security does not qualify either.
18. Internet Connected Toys with Social Interactive or Location Tracking Features
This category covers toys within the scope of Directive 2009/48/EC (the Toy Safety Directive) that communicate on the public internet and have either social interactive features or location tracking features. Social interactive features include embedded technologies enabling inbound and outbound communication — keyboards, microphones, speakers, or cameras. Location tracking features include technologies that enable tracking or inferring the geographical location of the toy or its user.
The regulation draws an important distinction for location features: a toy that merely detects the proximity of the user or of other toys using sensing technologies — without determining geographical location — does not have location tracking features for classification purposes. Both subcategories require internet connectivity as a threshold condition. A toy that is not covered by the Toy Safety Directive is not in this category regardless of its features.
19. Personal Wearable Products
Personal wearable products worn on the body for health monitoring are devices with embedded sensors, processors, and connectivity that continuously or periodically collect, process, and present physiological and activity data—such as heart rate, steps, sleep, temperature, respiration, or movement patterns—while excluding devices regulated as medical devices under Regulation (EU) 2017/745 or in vitro diagnostic devices under Regulation (EU) 2017/746; typical examples include fitness trackers, consumer smartwatches, smart jewellery, and sensor-integrated clothing that deliver wellness insights, activity coaching, and non-diagnostic trend monitoring.
Personal wearables designed specifically for use by and for children (under 14) follow the same technical model but are tailored for smaller physiques, simplified interfaces, and can include safety- and location-focused features (geofencing, emergency alerts, caregiver controls).
Part 4
Important Products with Digital Elements — Class II
Annex III Class II lists four product categories. Products in this class always require third-party assessment via a notified body — Module B+C or Module H — regardless of whether harmonised standards are applied. This mandatory involvement is the defining characteristic of Class II.
1. Hypervisors and Container Runtime Systems
Hypervisors and container runtime systems are software technologies that enable isolated, virtualized execution environments: hypervisors create and manage virtual machines (VMs) by abstracting and allocating hardware resources—CPU, memory, storage, and networking—so multiple VMs, each typically running its own guest OS, can coexist on the same physical host (hypervisors may be bare-metal/type 1, hosted/type 2, or hybrid and can even run nested).
Container runtime systems, by contrast, manage the lifecycle and execution of containers as isolated processes on a single host OS, packaging applications and their dependencies into lightweight, consistent execution units while controlling resource allocation and orchestration. Both approaches provide logical separation from other workloads and the underlying hardware, with VMs offering full OS-level isolation and containers providing more lightweight, process-level isolation.
2. Firewalls, Intrusion Detection and Prevention Systems
Firewalls are security products that monitor and control incoming and outgoing network traffic based on defined rules to protect a connected network or system from unauthorized access. They inspect packets and connections at various layers—network, transport, and application—and can enforce policies such as allowing, blocking, or logging traffic. This category covers a range of implementations including network firewalls that filter traffic between networks, application-layer firewalls like web application firewalls that inspect HTTP/HTTPS requests for malicious payloads, and specialized filters such as anti-spam gateways that block unwanted email; deployments may be physical appliances, virtual instances, or cloud-hosted services. A router that includes basic firewall functionality as an integrated component is not classified as a firewall — as explicitly noted in Recital 4 of the Implementing Regulation.
Intrusion detection systems (IDS) and intrusion prevention systems (IPS) both analyze network or host activity for signs of malicious behavior, but they differ in purpose and response. An IDS passively monitors traffic or system events to detect and alert on attempted, ongoing, or successful intrusions—using signature, anomaly, or behavior-based techniques—and is typically deployed as network-based or host-based sensors that feed alerts to administrators or security information systems. An IPS builds on IDS capability by actively responding to detected threats in real time, taking automated actions such as dropping packets, resetting connections, or applying firewall rules to block or contain attacks; like IDS, IPS can be network-based or host-based and is often integrated with broader security orchestration to balance automated prevention with false-positive management.
3. Tamper-Resistant Microprocessors
Tamper-resistant microprocessors are microprocessors with security-related functionalities (as defined in Class I, category 13) that additionally incorporate tamper evidence, resistance, or response, and that are designed to provide protection of AVA_VAN level 2 or 3 as set out in the Common Criteria and the Common Evaluation Methodology. AVA_VAN is the vulnerability analysis assurance component of the Common Criteria — it expresses the level of resistance against potential exploitability of flaws or weaknesses.
The relationship between Class I (category 13) and Class II (category 3) for microprocessors is a strict hierarchy: Class II is a subset of Class I with additional physical security requirements and a higher assurance level. A microprocessor that meets Class I criteria but does not incorporate tamper resistance at AVA_VAN level 2 or 3 remains a Class I product.
4. Tamper-Resistant Microcontrollers
Tamper-resistant microcontrollers are microcontrollers with security-related functionalities (as defined in Class I, category 14) that additionally incorporate tamper evidence, resistance, or response, and that are designed to provide protection of AVA_VAN level 2 or 3. The same hierarchy applies — Class II tamper-resistant microcontrollers are a subset of Class I microcontrollers with security functions, elevated to Class II by the physical security and assurance level requirements.
Tamper evidence means the product shows detectable signs of physical tampering attempts. Tamper resistance means it physically resists tampering attacks. Tamper response means it actively responds to tampering — for example, by erasing sensitive data when a physical attack is detected. All three mechanisms serve to protect the security assets held within the device against physical attack vectors.
Part 5
Critical Products with Digital Elements
Annex IV lists three categories of critical products. For critical products, manufacturers must obtain a European cybersecurity certificate under a European cybersecurity certification scheme pursuant to Regulation (EU) 2019/881 (the Cybersecurity Act), or, where no applicable scheme is in force, are subject to mandatory third-party conformity assessment. The conformity assessment route is the most demanding of the three tiers.
1. Hardware Devices with Security Boxes
Hardware devices with security boxes are physical products that securely store, process, or manage sensitive data and perform cryptographic operations while combining multiple discrete components inside a protective hardware envelope. These devices integrate dedicated processors, secure storage, and firmware to carry out tasks such as key generation, encryption/decryption, authentication, secure transaction processing, or tamper-evident logging. The physical envelope—built from hardened materials and designed with seals, locks or intrusion sensors, provides tamper resistance and can trigger defensive responses (e.g., zeroizing keys, locking down functionality, or logging tamper events) when physical compromise is detected, reducing the risk of extracted secrets or manipulated operation.
Examples include payment terminals that securely capture card data and PINs and enforce transaction integrity; hardware security modules (HSMs) that generate, store, and manage cryptographic keys with strong access controls and auditable interfaces; and tachographs that securely record vehicle and driver data within tamper-resistant housings. These devices are often certified against recognized security standards and include lifecycle controls—secure provisioning, authenticated firmware updates, and end-of-life key destruction—to maintain trustworthiness throughout deployment, operation, and disposal.
2. Smart Meter Gateways within Smart Metering Systems
Smart meter gateways control communication between components in or connected to smart metering systems — as defined in Article 2(23) of Directive (EU) 2019/944 on the internal market for electricity — and authorised third parties such as utility providers. The technical description requires that the gateway collect, process, and store meter or personal data; protect data flows through specific cryptographic capabilities including encryption and decryption; incorporate firewalling functionalities; and provide means to control other connected devices.
The category is primarily anchored in the electricity smart metering definition from Directive 2019/944 but may also extend to smart meter gateways used in other energy sources — gas, heat — provided the gateway meets the full technical description. The gateway function itself is the classifier, not the energy type being metered.
3. Smartcards or Similar Devices, Including Secure Elements
Secure elements are microcontrollers or microprocessors with security-related functionalities — including tamper evidence, resistance, or response — that typically store, process, or manage cryptographic operations or sensitive data such as identity or payment credentials, and that are designed to provide protection of at least AVA_VAN.4 as set out in the Common Criteria or the Common Evaluation Methodology. This is the key differentiator from the Class II tamper-resistant categories: critical secure elements require AVA_VAN.4 or higher, whereas Class II tamper-resistant products require AVA_VAN level 2 or 3.
Secure elements may be discrete silicon chips or integrated into systems-on-chip (SoC), and they often provide secure key generation, secure storage, cryptographic primitives, secure boot and authenticated update mechanisms, plus an isolated application environment or small operating system that hosts one or more trusted applications
Smartcards and similar devices embed secure elements into a carrier form factor to create portable, user-facing credentials and payment or access devices. In card form, the secure element is mounted in plastic (or other materials) as a credit-card–sized token; other carriers include removable Universal Integrated Circuit Cards (UUIC), wristbands, and fobs. Typical uses include identity and travel documents, qualified signature and payment cards or physical and logical access tokens.
CRA Vertical Standards by Product Category
The table below lists the vertical standard applicable to each important and critical product category and the current availability of drafts. All standards are in draft form — none have been formally adopted. Manufacturers should prepare using current drafts and adjust as final versions are published.
| Category | Class | Standard | Draft |
|---|---|---|---|
| Identity Management & PAM | Class I | tbd | Not yet available |
| Browsers | Class I | EN 304 617 | v0.1.0, Dec 2025 |
| Password Managers | Class I | EN 304 618 | v0.1.0, Dec 2025 |
| Antivirus / Antimalware | Class I | EN 304 619 | v0.0.12, Dec 2025 |
| VPN Products | Class I | EN 304 620 | v0.1.0, Dec 2025 |
| VPN Products — Industrial | Class I | EN 50770-4 | Not yet available |
| Network Management Systems | Class I | EN 304 621 | v0.1.2, Dec 2025 |
| Network Management Systems — Industrial | Class I | EN 50770-2 | Not yet available |
| SIEM Systems | Class I | EN 304 622 | v0.1.0, Dec 2025 |
| SIEM Systems — Industrial | Class I | EN 50770-6 | Not yet available |
| Boot Managers | Class I | EN 304 623 | v0.0.12, Dec 2025 |
| PKI & Digital Certificate Software | Class I | EN 304 624 | v0.0.8, Jan 2026 |
| Network Interfaces | Class I | EN 304 625 | v0.0.13, Dec 2025 |
| Network Interfaces — Industrial | Class I | EN 50770-3 | Not yet available |
| Operating Systems | Class I | EN 304 626 | v0.1.0, Dec 2025 |
| Routers, Modems & Switches | Class I | EN 304 627 | v0.0.11, Nov 2025 |
| Routers, Modems & Switches — Industrial | Class I | EN 50770-5 | Not yet available |
| Microprocessors with Security Functions | Class I | EN 50XXX (tbd) | Not yet available |
| Microcontrollers with Security Functions | Class I | EN 50XXX (tbd) | Not yet available |
| ASIC & FPGA with Security Functions | Class I | tbd | Not yet available |
| Smart Home Virtual Assistants | Class I | EN 304 631 | Not yet available |
| Smart Home Security Products | Class I | EN 304 632 | Not yet available |
| Internet-Connected Toys | Class I | EN 304 633 | Not yet available |
| Personal Wearable Products | Class I | EN 304 634 | Not yet available |
| Hypervisors & Container Runtimes | Class II | EN 304 635 | v0.0.10, Dec 2025 |
| Firewalls, IDS & IPS | Class II | EN 304 636 | v0.0.9, Dec 2025 |
| Firewalls, IDS & IPS — Industrial | Class II | EN 50770-1 | Not yet available |
| Tamper-Resistant Microprocessors | Class II | EN 5XXXX (tbd) | Not yet available |
| Tamper-Resistant Microcontrollers | Class II | EN 5XXXX (tbd) | Not yet available |
| Hardware Devices with Security Boxes | Critical | tbd | Not yet available |
| Smart Meter Gateways | Critical | tbd | Not yet available |
| Smartcards & Secure Elements | Critical | tbd | Not yet available |
For categories where no vertical standard is yet available, manufacturers should prepare using the three horizontal standards: prEN 40000-1-2 (risk assessment), prEN 40000-1-3 (vulnerability handling), and prEN 40000-1-4 (product security). These apply to all products regardless of category.
Frequently Asked Questions
Common questions about CRA product categories, classification methodology, conformity assessment, and applicable standards.