The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, establishes a harmonised European framework designed to strengthen the cybersecurity of products with digital elements made available on the European Union market.
In particular, it requires manufacturers to build cybersecurity into products from the design stage, to handle vulnerabilities, and to keep products secure throughout their support period.
However, conformity assessment procedures differ depending on the nature of the product, its core functionality and its level of criticality. The CRA therefore distinguishes between:
- Products with digital elements that do not fall into any specific category, commonly referred to as “default” or “standard” products;
- Important products listed in Annex III, divided into Class I and Class II;
- Critical products listed in Annex IV;
- Free and open-source software, which may be subject to a specific regime depending on how it is developed and made available.
Through eight use cases drawn from a range of sectors, this article explains in practical terms how a product is classified under the CRA and the main compliance measures to implement.
1. “Standard” Products with Digital Elements
Use Case 1: AI-Powered Autonomous Cleaning Robot for Airports
Product Overview
A manufacturer develops an autonomous cleaning robot for major transport hubs such as international airports.
The robot moves autonomously through terminals to clean floors continuously, including in high-traffic areas.
To operate, the product includes:
- LiDAR sensors and cameras to detect its surroundings;
- Embedded mapping, navigation and obstacle-avoidance software;
- A Wi-Fi or 5G connection for remote administration;
- A cloud platform for fleet monitoring and management;
- An AI system that analyses sensor data to optimise cleaning routes based on the layout of the premises, detected obstacles and passenger flows.
The robot can also detect situations requiring priority action, such as a spill or an unusually congested area. Operations teams can monitor its activity, change its settings or stop it from the supervision interface.
Regulatory Classification
Under the CRA, the robot is a product with digital elements, as it includes hardware and software components and can be connected directly or indirectly to a network or device.
It does not fall into any of the categories of important products listed in Annex III, nor into the categories of critical products listed in Annex IV of the CRA.
The robot therefore falls into the general category of products with digital elements, commonly referred to as “standard” products.
Under the AI Act, the AI system embedded in the robot presents minimal risk, provided that it is used solely to optimise cleaning routes and performs no function related to people’s safety.
Potential Risks
The robot’s connectivity and remote administration features expose it in particular to risks of unauthorised takeover, tampering with its trajectories, disruption of its operation or compromise of the fleet management platform.
Applicable Compliance Measures
The manufacturer must in particular:
- Carry out a cybersecurity risk assessment;
- Apply the essential requirements set out in Annex I;
- Implement a secure-by-design approach;
- Document identified vulnerabilities;
- Provide security updates throughout the support period;
- Draw up technical documentation and an EU declaration of conformity;
- Affix the CE marking.
Use Case 2: Digital Booking Kiosk in a Town Hall
Product Overview
A local authority deploys kiosks allowing citizens to book municipal rooms, complete certain administrative procedures or access local information.
In particular, the kiosk allows users to:
- Book a municipal room or facility;
- Make an appointment with an administrative department;
- Complete certain procedures online;
- Access information about local services, activities and events;
- Print or send a booking confirmation.
To operate, the product includes:
- A touchscreen and a public-facing software interface;
- A connection to the local authority’s network;
- A data exchange system with the relevant municipal departments;
- An administration interface for remote configuration and maintenance;
- A software update mechanism.
Classification under the CRA
The kiosk is a product with digital elements, as it includes hardware and software components and its intended use involves a direct or indirect connection to a device or network.
It falls within the scope of the CRA but does not belong to any of the categories of important products listed in Annex III, nor to the categories of critical products listed in Annex IV.
The kiosk therefore falls into the general category of products with digital elements, commonly referred to as “standard” products.
Potential Risks
The kiosk’s connection to the local authority’s network and its remote administration features expose it in particular to risks of unauthorised access, compromise of administrator accounts, tampering with displayed information, interception of exchanged data, or use of the kiosk as an entry point into the municipal information system.
Applicable Compliance Measures
The manufacturer will in particular need to:
- Secure authentication and administration mechanisms;
- Carry out a cybersecurity risk assessment;
- Protect data submitted by kiosk users;
- Ensure the confidentiality and integrity of data processed or transmitted;
- Limit data collection to what is strictly necessary;
- Ensure the availability of essential functions;
- Reduce the attack surface by disabling unnecessary interfaces and services;
- Identify, document and remediate vulnerabilities;
- Provide security updates throughout the support period.
2. Important Products under Annex III
Important products are products with digital elements that perform functions critical to the cybersecurity of other products, networks or services, particularly in relation to authentication, access control, intrusion detection or network protection.
They may also present a significant risk of adverse effects due to their ability to disrupt, control or damage a large number of other products, or to harm the health, safety or security of their users.
These products are listed in Annex III and divided into Class I and Class II.
Use Case 3: Generative AI Home Voice Assistant
Product Overview
Users can interact with the product in natural language to search for information, manage their daily activities or control the connected devices in their home.
To operate, the product includes:
- Microphones to receive voice commands;
- A connection to the internet and to other smart home devices;
- A mobile app for configuration and administration;
- A cloud platform that processes certain requests;
- A generative AI system that understands user requests and produces natural-language responses;
- Interfaces for controlling devices such as lighting, heating, locks or alarm systems.
The assistant can answer users’ questions, manage their calendar, set reminders and execute commands on authorised connected devices.
Regulatory Classification
Under the CRA, the voice assistant is a product with digital elements, as it includes hardware and software components and its intended use involves a direct or indirect connection to devices and networks.
Its core functionality corresponds to that of smart home general-purpose virtual assistants, a category expressly listed in Annex III of the Cyber Resilience Act. It is therefore classified as a Class I important product.
Under the AI Act, the AI system embedded in the home voice assistant is subject to the transparency obligations set out in Article 50 of the AI Act.
Potential Risks
The assistant’s connectivity and its ability to control other devices expose it in particular to risks of unauthorised access, interception of voice commands, compromise of user accounts, execution of malicious commands or takeover of the home’s connected devices.
Applicable Compliance Measures
The manufacturer must in particular:
- Carry out a cybersecurity risk assessment;
- Apply the essential cybersecurity requirements set out in Annex I;
- Secure communications between the assistant, the mobile app, the cloud platform and connected devices;
- Implement appropriate authentication and access control mechanisms;
- Protect the confidentiality and integrity of voice commands and other data stored, transmitted or processed;
- Limit the data collected and processed to what is necessary for the product to function;
- Prevent the execution of unauthorised commands on connected devices;
- Identify, document and remediate vulnerabilities;
- Provide security updates throughout the support period;
- Draw up technical documentation and an EU declaration of conformity;
- Affix the CE marking.
As a Class I important product, the voice assistant is subject to a stricter conformity assessment procedure. Whether internal control can be used depends in particular on the full application of harmonised standards, common specifications or relevant certification schemes covering the applicable requirements. Otherwise, the manufacturer must use one of the procedures involving a notified body provided for by the Cyber Resilience Act.
Use Case 4: Industrial Operating System for Production PLCs
Product Overview
A manufacturer develops an operating system for programmable logic controllers (PLCs) used on industrial production lines.
The software runs the PLC and supervises the execution of production operations, such as controlling equipment, processing commands and exchanging data with other plant systems.
To operate, the product includes:
- A runtime environment for controlling PLC functions;
- Communication interfaces with production line machines and sensors;
- A user account and access rights management mechanism;
- An interface for remote configuration and maintenance;
- A mechanism for downloading and installing software updates.
Classification under the CRA
The operating system is a product with digital elements, as it is software intended to be connected directly or indirectly to the PLCs, equipment and networks of the industrial environment.
Its core functionality corresponds to the operating systems category, expressly listed in Annex III of the Cyber Resilience Act. It is therefore classified as a Class I important product.
Potential Risks
A compromise of the operating system could in particular lead to the execution of unauthorised commands, tampering with production parameters, disruption of PLC operation, the spread of malware across the industrial network or loss of production line availability.
Applicable Compliance Measures
The manufacturer must in particular:
- Carry out a cybersecurity risk assessment;
- Apply the essential cybersecurity requirements set out in Annex I;
- Place the operating system on the market with a secure-by-default configuration;
- Secure boot, authentication and remote administration mechanisms;
- Protect the integrity of commands, programs and configuration settings;
- Limit interfaces, services and access rights to what is strictly necessary;
- Ensure the availability of the system’s essential functions;
- Identify, document and remediate vulnerabilities;
- Distribute security updates through secure mechanisms throughout the support period;
- Put in place a coordinated vulnerability disclosure policy;
- Draw up technical documentation and an EU declaration of conformity;
- Affix the CE marking.
As a Class I important product, the operating system is subject to a stricter conformity assessment procedure. The manufacturer may use internal control where it fully applies harmonised standards, common specifications or, where applicable, a European certification scheme covering the applicable requirements. Otherwise, it must follow a procedure involving a notified body, such as EU-type examination followed by internal production control, or full quality assurance.
3. Critical Products under Annex IV
Critical products are products with digital elements on which certain essential entities may depend critically to carry out their activities.
Incidents or the exploitation of vulnerabilities affecting these products may also cause serious disruption to critical supply chains across the internal market.
These products are listed in Annex IV of the Cyber Resilience Act.
Use Case 5: Secure Cryptographic Module for Hospital Infrastructure
Product Overview
A manufacturer develops a hardware security module designed to protect access, data exchanges and cryptographic operations within a hospital’s information system.
In particular, the module is used to secure access to an AI platform that assists healthcare professionals in analysing medical images. The module itself performs no diagnosis and plays no role in the results produced by the platform.
To operate, the product includes:
- A secure hardware environment for generating and storing cryptographic keys;
- Data encryption and decryption mechanisms;
- Electronic signature and exchange integrity verification functions;
- Communication interfaces with the hospital’s applications and servers;
- An identity, authorisation and administrator access management system;
- An AI system that analyses access behaviour to detect unusual activity.
When an anomaly is detected, the product can generate an alert or trigger predefined protective measures, such as temporarily blocking an access attempt.
Regulatory Classification
Under the CRA, the module is a product with digital elements, as it combines hardware and software components and communicates with the hospital’s applications, servers and networks.
Its core functionality is to perform secure cryptographic processing and protect the keys used by the information system. Subject to its precise technical characteristics, it may therefore fall under devices for advanced security purposes, including secure cryptoprocessing, listed in Annex IV of the Cyber Resilience Act. It is then classified as a critical product.
Under the AI Act, the AI system embedded in the cryptographic module does not fall into the high-risk AI system categories and therefore presents minimal risk, since it is solely intended to detect security anomalies and its failure would not endanger people’s health or safety.
Potential Risks
A compromise of the module could in particular lead to the exposure or fraudulent use of cryptographic keys, circumvention of access controls, decryption of sensitive data, tampering with exchanges or unavailability of the protected hospital applications.
Applicable Compliance Measures
The manufacturer must in particular:
- Carry out a cybersecurity risk assessment;
- Apply the essential cybersecurity requirements set out in Annex I;
- Implement secure-by-design and secure-by-default configuration;
- Protect cryptographic keys against unauthorised access, extraction and modification;
- Secure authentication, authorisation management and administration mechanisms;
- Ensure the confidentiality, integrity, authenticity and availability of data, commands and cryptographic operations;
- Log and monitor relevant security events;
- Identify, document and remediate vulnerabilities;
- Securely distribute security updates throughout the support period;
- Draw up technical documentation and an EU declaration of conformity;
- Affix the CE marking.
As a critical product, the module is subject to a stricter conformity assessment procedure. Where a delegated act requires the use of a European cybersecurity certification scheme, the manufacturer must obtain the corresponding certificate. Otherwise, it must apply one of the procedures provided for Class II important products, notably EU-type examination followed by internal production control, or full quality assurance.
Use Case 6: Access Control Smart Card for the Power Grid
Product Overview
A manufacturer develops a secure smart card for operators responsible for running and maintaining power infrastructure.
The card authenticates technicians and controls their access to sensitive premises, administration workstations and power grid supervision systems.
To operate, the product includes:
- A secure hardware component for storing identification data and cryptographic keys;
- A user authentication mechanism;
- Signature and encryption functions for exchanges;
- A communication interface with card readers and administration workstations;
- A certificate and access rights management system;
- Mechanisms protecting stored data against unauthorised extraction or modification.
Classification under the CRA
The smart card is a product with digital elements, as it combines hardware and software components and communicates with readers, administration workstations and access control systems.
Its core functionality corresponds to the category of smartcards or similar devices, including secure elements, expressly listed in Annex IV of the Cyber Resilience Act. It is therefore classified as a critical product.
This classification is based on the smart card’s core functionality, not on its use in the energy sector. A product’s core functionality determines whether it falls into a category of important or critical products and, consequently, which conformity assessment procedure applies.
Potential Risks
A compromise of the card could in particular lead to technician identity theft, unauthorised access to administration systems, extraction or fraudulent use of cryptographic keys, tampering with access rights or disruption of power grid operations.
Applicable Compliance Measures
The manufacturer must in particular:
- Carry out a cybersecurity risk assessment;
- Apply the essential cybersecurity requirements set out in Annex I;
- Implement secure-by-design and secure-by-default configuration;
- Protect identification data and cryptographic keys against unauthorised access, extraction or modification;
- Secure authentication, signature and communication mechanisms with card readers;
- Protect the integrity of certificates, access rights and other stored data;
- Ensure the product’s resistance to relevant physical and logical attacks;
- Identify, document and remediate vulnerabilities;
- Securely distribute security updates throughout the support period;
- Draw up technical documentation and an EU declaration of conformity;
- Affix the CE marking.
As a critical product, the smart card cannot be self-assessed. Where a delegated act requires European cybersecurity certification, the manufacturer must obtain the corresponding certificate. In all other cases, the product is subject to mandatory third-party assessment under the procedures applicable to Class II important products.
4. Open-Source Software
The CRA distinguishes between types of free and open-source software based on how they are made available. Software supplied outside the course of a commercial activity is not subject to the obligations applicable to manufacturers. Software made available in the course of a commercial activity is subject to them, while open-source software stewards benefit from a specific, lighter regime.
Use Case 7: Open-Source Medical Image Analysis Library
Product Overview
A community of researchers develops an open-source software library for analysing medical images as part of research projects.
The library enables researchers and developers to train, evaluate and use machine learning models to identify certain features in radiological images.
To operate, the product includes:
- Data preprocessing and classification functions;
- Interfaces for integrating the library into other applications;
- Open-source software components and libraries developed by third parties;
- Technical documentation for installing and using the software.
The source code is published free of charge under a free and open-source licence on a collaborative platform. The community does not sell the library, does not charge for its use and does not provide any associated paid service.
Regulatory Classification
Under the CRA, the library is a software product with digital elements. However, free and open-source software only falls within the scope of the CRA when it is made available on the market, that is, supplied for distribution or use in the course of a commercial activity.
In this case, the library is developed and supplied free of charge, without monetisation by its developers and outside the course of a commercial activity. It is therefore not subject to the CRA obligations applicable to manufacturers.
This classification should nevertheless be reassessed if the library is later commercialised, integrated into a product placed on the market, or accompanied by services that could constitute a commercial activity.
Potential Risks
Although no manufacturer obligations apply under the CRA, the library may in particular contain vulnerabilities in its code or dependencies, allow malicious components to run, compromise the confidentiality or integrity of processed images, or pass these vulnerabilities on to the products into which it is integrated.
Recommended Cybersecurity Measures
The community may in particular:
- Document the components and dependencies included in the library;
- Put in place code review and hardening procedures;
- Identify, document and address reported vulnerabilities;
- Publish a coordinated vulnerability disclosure policy;
- Provide a point of contact for reporting vulnerabilities;
- Distribute patches and updates through secure mechanisms;
- Inform users of known vulnerabilities and available remediation measures.
If a legal person provides systematic and sustained support for the development of this library, which is intended for use in commercial activities, and plays a key role in its viability, it may qualify as an open-source software steward and be subject to the specific obligations set out in Article 24 of the CRA. These include adopting a cybersecurity policy, cooperating with market surveillance authorities and certain obligations to report vulnerabilities and incidents.
Use Case 8: Commercially Maintained Open-Source Firewall
Product Overview
A company develops and sells a professional distribution of a firewall based on open-source software.
The product is aimed at businesses and public administrations that want to control communications between their internal networks, the internet and their various information systems.
To operate, the product includes:
- A network traffic filtering engine;
- Rules for allowing or blocking specific communications;
- An administration interface for configuring security policies;
- Logging and monitoring functions for network events;
- Open-source software components and libraries;
- A mechanism for distributing and installing security updates.
The company sells the product under its own name and offers maintenance, technical support and update services.
Classification under the CRA
The firewall is a product with digital elements, as it is software intended to be connected to its users’ networks and information systems.
Although it is based on open-source software, it is made available in the course of a commercial activity. The company selling it under its own name or trademark is therefore subject to the CRA obligations applicable to manufacturers of products with digital elements.
Its core functionality corresponds to the category of firewalls and intrusion detection or prevention systems, expressly listed in Annex III of the Cyber Resilience Act. It is therefore classified as a Class II important product.
Potential Risks
A compromise of the firewall could in particular allow filtering rules to be bypassed, unauthorised access to the protected network, interception or tampering with communications, execution of malicious code or unavailability of the affected systems and services.
Applicable Compliance Measures
The manufacturer must in particular:
- Carry out a cybersecurity risk assessment;
- Apply the essential cybersecurity requirements set out in Annex I;
- Implement secure-by-design and secure-by-default configuration;
- Protect administration functions against unauthorised access;
- Ensure the confidentiality and integrity of communications and configuration settings;
- Limit interfaces, services and access rights to what is strictly necessary;
- Inventory the components included in the product, including open-source components;
- Identify, document and remediate vulnerabilities;
- Put in place a coordinated vulnerability disclosure policy;
- Securely distribute updates throughout the support period;
- Report actively exploited vulnerabilities and severe incidents in accordance with the CRA;
- Draw up technical documentation and an EU declaration of conformity;
- Affix the CE marking.
As a Class II important product, the firewall must undergo assessment by a notified body. The manufacturer must use either EU-type examination followed by conformity to type based on internal production control, or an assessment based on full quality assurance. Self-assessment is not permitted for this product category.
Key Takeaways
The Cyber Resilience Act covers a wide range of products with digital elements, whether or not they incorporate artificial intelligence: connected devices, industrial software, smart home assistants, cryptographic components and commercialised open-source software.
Product classification is the starting point for any compliance approach. It determines the applicable cybersecurity requirements, the conformity assessment procedure to follow, whether a third-party body must be involved, and the obligations relating to documentation and vulnerability management.
Move from Regulatory Analysis to Operational Compliance
The CRA is part of a broader regulatory landscape that includes the AI Act, the GDPR, the NIS2 Directive and sector-specific regulations. To ensure consistent compliance, organisations need to identify how these frameworks interact and manage them centrally.
At Naaia, we help organisations structure and manage their compliance through a platform dedicated to artificial intelligence management.
Our platform enables you to:
- Classify your products and AI systems;
- Map applicable regulatory requirements;
- Carry out your risk assessments;
- Document your compliance measures;
- Manage your CRA, AI Act and cybersecurity obligations on an ongoing basis.
Want to assess the impact of the CRA on your product portfolio? Discover the Naaia platform and turn your regulatory obligations into a concrete, manageable action plan.
