Le Cyber Resilience Act (CRA), règlement (UE) 2024/2847, établit un cadre européen harmonisé destiné à renforcer la cybersécurité des produits comportant des éléments numériques mis à disposition sur le marché de l’Union européenne.
Il impose notamment aux fabricants d’intégrer la cybersécurité dès la conception du produit, de gérer les vulnérabilités et d’assurer son maintien en conditions de sécurité tout au long de sa période de support.
Toutefois, les modalités d’évaluation de la conformité diffèrent selon la nature du produit, sa fonctionnalité de base et son niveau de criticité. Le CRA distingue ainsi :
- Les produits comportant des éléments numériques ne relevant d’aucune catégorie particulière, couramment qualifiés de produits « standard » ;
- Les produits importants énumérés à l’Annexe III, répartis entre les classes I et II ;
- Les produits critiques énumérés à l’Annexe IV ;
- Les logiciels libres et open source, auxquels un régime particulier peut s’appliquer selon leurs conditions de développement et de mise à disposition.
À travers huit cas d’usage issus de secteurs variés, cet article décrypte concrètement la qualification d’un produit au regard du CRA ainsi que les principales mesures de conformité à mettre en œuvre.
1. Produits comportant des éléments numériques « standard »
Cas d’usage n°1 : Robot de nettoyage autonome pour aéroport utilisant l’IA
Présentation du produit
Un fabricant développe un robot de nettoyage autonome destiné aux grands hubs de transport tels que les aéroports internationaux.
Le robot circule de manière autonome dans les terminaux afin d’assurer le nettoyage des sols en continu, y compris dans les zones à forte fréquentation.
Pour fonctionner, le produit intègre :
- Des capteurs LiDAR et des caméras permettant de détecter son environnement ;
- Un logiciel embarqué de cartographie, de navigation et d’évitement des obstacles ;
- Une connexion Wi-Fi ou 5G permettant son administration à distance ;
- Une plateforme cloud destinée à la supervision et à la gestion de la flotte ;
- Un système d’IA analysant les données issues des capteurs afin d’optimiser les itinéraires de nettoyage en fonction de la configuration des lieux, des obstacles détectés et des flux de passagers.
Le robot peut également détecter certaines situations nécessitant une intervention prioritaire, telles qu’un déversement au sol ou l’encombrement inhabituel d’une zone. Les équipes d’exploitation peuvent suivre son activité, modifier ses paramètres ou interrompre son fonctionnement depuis l’interface de supervision.
Qualification réglementaire
Au sens du CRA, le robot constitue un produit comportant des éléments numériques puisqu’il intègre des composants matériels et logiciels et peut être connecté directement ou indirectement à un réseau ou à un dispositif.
Il ne relève d’aucune des catégories de produits importants énumérées à l’Annexe III ni des catégories de produits critiques énumérées à l’Annexe IV du CRA.
Le robot relève donc de la catégorie générale des produits comportant des éléments numériques, couramment qualifiés de produits « standard ».
Au sens de l’AI Act, le système d’IA intégré au robot présente un risque minimal, sous réserve qu’il soit exclusivement destiné à optimiser les itinéraires de nettoyage et qu’il n’assure aucune fonction liée à la sécurité des personnes.
Risques potentiels
La connectivité du robot et ses fonctions d’administration à distance l’exposent notamment à des risques de prise de contrôle non autorisée, d’altération de ses trajectoires, d’interruption de son fonctionnement ou de compromission de la plateforme de gestion de flotte.
Mesures de conformité applicables
Le fabricant doit donc notamment :
- Réaliser une évaluation des risques de cybersécurité ;
- Appliquer les exigences essentielles de l’Annexe I ;
- Mettre en œuvre une conception sécurisée (« secure by design ») ;
- Documenter les vulnérabilités identifiées ;
- Fournir des mises à jour de sécurité pendant la période de support ;
- Établir une documentation technique et une déclaration UE de conformité ;
- Apposer le marquage CE.
Cas d’usage n°2 : Borne de réservation numérique dans une mairie
Présentation du produit
Une collectivité locale déploie des bornes permettant aux citoyens de réserver des salles municipales, d’effectuer certaines démarches administratives ou de consulter des informations locales.
La borne permet notamment :
- De réserver une salle ou un équipement municipal ;
- De prendre rendez-vous avec un service administratif ;
- D’effectuer certaines démarches en ligne ;
- De consulter des informations relatives aux services, activités et événements locaux ;
- D’imprimer ou de transmettre un justificatif de réservation.
Pour fonctionner, le produit intègre :
- Un écran tactile et une interface logicielle accessible au public ;
- Une connexion au réseau de la collectivité ;
- Un système d’échange de données avec les services municipaux concernés ;
- Une interface d’administration permettant la configuration et la maintenance à distance ;
- Un mécanisme de mise à jour du logiciel.
Qualification au sens du CRA
La borne constitue un produit comportant des éléments numériques puisqu’elle intègre des composants matériels et logiciels et que son utilisation prévue comprend une connexion directe ou indirecte à un dispositif ou à un réseau.
Elle entre dans le champ d’application du CRA mais ne relève d’aucune des catégories de produits importants énumérées à l’Annexe III ni des catégories de produits critiques énumérées à l’Annexe IV.
La borne relève donc de la catégorie générale des produits comportant des éléments numériques, couramment qualifiés de produits « standard ».
Risques potentiels
La connexion de la borne au réseau de la collectivité et ses fonctions d’administration à distance l’exposent notamment à des risques d’accès non autorisé, de compromission des comptes administrateurs, d’altération des informations affichées, d’interception des données échangées ou d’exploitation de la borne comme point d’entrée vers le système d’information municipal.
Mesures de conformité applicables
Le fabricant devra notamment :
- Sécuriser les mécanismes d’authentification et d’administration ;
- Réaliser une évaluation des risques de cybersécurité ;
- Protéger les données transmises par les utilisateurs de la borne ;
- Garantir la confidentialité et l’intégrité des données traitées ou transmises ;
- Limiter la collecte des données au strict nécessaire ;
- Assurer la disponibilité des fonctions essentielles ;
- Réduire la surface d’attaque en désactivant les interfaces et services inutiles ;
- Identifier, documenter et corriger les vulnérabilités ;
- Fournir des mises à jour de sécurité pendant la période de support.
2. Produits importants au sens de l’Annexe III
Les produits importants sont des produits comportant des éléments numériques qui exercent des fonctions essentielles pour la cybersécurité d’autres produits, réseaux ou services, notamment en matière d’authentification, de contrôle des accès, de détection des intrusions ou de protection des réseaux.
Ils peuvent également présenter un risque important d’effets néfastes en raison de leur capacité à perturber, contrôler ou endommager un grand nombre d’autres produits, ou à porter atteinte à la santé, à la sécurité ou à la sûreté de leurs utilisateurs.
Ces produits sont énumérés à l’Annexe III et répartis entre les classes I et II.
Cas d’usage n°3 : Assistant vocal domestique reposant sur l’IA générative
Présentation du produit
L’utilisateur peut interagir avec le produit en langage naturel afin de rechercher des informations, de gérer ses activités quotidiennes ou de contrôler les équipements connectés de son logement.
Pour fonctionner, le produit intègre :
- Des microphones permettant de recevoir les commandes vocales ;
- Une connexion à Internet et aux autres équipements de la maison connectée ;
- Une application mobile permettant sa configuration et son administration ;
- Une plateforme cloud assurant le traitement de certaines requêtes ;
- Un système d’IA générative permettant de comprendre les demandes de l’utilisateur et de produire des réponses en langage naturel ;
- Des interfaces permettant de piloter des équipements tels que l’éclairage, le chauffage, les serrures ou les systèmes d’alarme.
L’assistant peut notamment répondre aux questions de l’utilisateur, gérer son calendrier, programmer des rappels et exécuter des commandes sur les équipements connectés autorisés.
Qualification réglementaire
Au sens du CRA, l’assistant vocal constitue un produit comportant des éléments numériques puisqu’il intègre des composants matériels et logiciels et que son utilisation prévue comprend une connexion directe ou indirecte à des dispositifs et à des réseaux.
Sa fonctionnalité de base correspond à celle des assistants virtuels généralistes pour la maison intelligente, catégorie expressément énumérée à l’Annexe III du Cyber Resilience Act. Il est donc qualifié de produit important de classe I.
Au sens de l’AI Act, le système d’IA intégré à l’assistant vocal domestique est soumis aux obligations de transparence prévues à l’article 50 de l’AI Act.
Risques potentiels
La connectivité de l’assistant et sa capacité à contrôler d’autres équipements l’exposent notamment à des risques d’accès non autorisé, d’interception des commandes vocales, de compromission des comptes utilisateurs, d’exécution de commandes malveillantes ou de prise de contrôle des équipements connectés au logement.
Mesures de conformité applicables
Le fabricant doit notamment :
- Réaliser une évaluation des risques de cybersécurité ;
- Appliquer les exigences essentielles de cybersécurité de l’Annexe I ;
- Sécuriser les communications entre l’assistant, l’application mobile, la plateforme cloud et les équipements connectés ;
- Mettre en place des mécanismes appropriés d’authentification et de contrôle des accès ;
- Protéger la confidentialité et l’intégrité des commandes vocales ainsi que des autres données stockées, transmises ou traitées ;
- Limiter les données collectées et traitées à celles nécessaires au fonctionnement du produit ;
- Empêcher l’exécution de commandes non autorisées sur les équipements connectés ;
- Identifier, documenter et corriger les vulnérabilités ;
- Fournir des mises à jour de sécurité pendant la période de support ;
- Établir la documentation technique et la déclaration UE de conformité ;
- Apposer le marquage CE.
En tant que produit important de classe I, l’assistant vocal est soumis à une procédure d’évaluation de la conformité renforcée. Le recours au contrôle interne dépend notamment de l’application intégrale des normes harmonisées, spécifications communes ou schémas de certification pertinents couvrant les exigences applicables. À défaut, le fabricant doit recourir à l’une des procédures impliquant un organisme notifié prévues par le Cyber Resilience Act.
Cas d’usage n°4 : Système d’exploitation industriel pour automates de production
Présentation du produit
Un fabricant développe un système d’exploitation dédié aux automates utilisés dans les lignes de production industrielles.
Le logiciel assure le fonctionnement de l’automate et permet de superviser l’exécution des différentes opérations de production, telles que le pilotage des équipements, le traitement des commandes et l’échange de données avec les autres systèmes de l’usine.
Pour fonctionner, le produit intègre :
- Un environnement d’exécution permettant de piloter les fonctions de l’automate ;
- Des interfaces de communication avec les machines et les capteurs de la ligne de production ;
- Un mécanisme de gestion des comptes utilisateurs et des droits d’accès ;
- Une interface permettant la configuration et la maintenance à distance ;
- Un mécanisme de téléchargement et d’installation des mises à jour logicielles.
Qualification au sens du CRA
Le système d’exploitation constitue un produit comportant des éléments numériques puisqu’il s’agit d’un logiciel destiné à être connecté directement ou indirectement aux automates, équipements et réseaux de l’environnement industriel.
Sa fonctionnalité de base correspond à la catégorie des systèmes d’exploitation, expressément énumérée à l’Annexe III du Cyber Resilience Act. Il est donc qualifié de produit important de classe I.
Risques potentiels
La compromission du système d’exploitation peut notamment entraîner l’exécution de commandes non autorisées, l’altération des paramètres de production, l’interruption du fonctionnement des automates, la propagation d’un logiciel malveillant sur le réseau industriel ou la perte de disponibilité de la ligne de production.
Mesures de conformité applicables
Le fabricant doit notamment :
- Réaliser une évaluation des risques de cybersécurité ;
- Appliquer les exigences essentielles de cybersécurité de l’Annexe I ;
- Mettre le système d’exploitation sur le marché avec une configuration sécurisée par défaut ;
- Sécuriser les mécanismes de démarrage, d’authentification et d’administration à distance ;
- Protéger l’intégrité des commandes, des programmes et des paramètres de configuration ;
- Limiter les interfaces, services et droits d’accès au strict nécessaire ;
- Assurer la disponibilité des fonctions essentielles du système ;
- Identifier, documenter et corriger les vulnérabilités ;
- Distribuer les mises à jour de sécurité au moyen de mécanismes sécurisés pendant la période de support ;
- Mettre en place une politique de divulgation coordonnée des vulnérabilités ;
- Établir la documentation technique et la déclaration UE de conformité ;
- Apposer le marquage CE.
En tant que produit important de classe I, le système d’exploitation est soumis à une procédure d’évaluation de la conformité renforcée. Le fabricant peut recourir au contrôle interne lorsqu’il applique intégralement les normes harmonisées, les spécifications communes ou, le cas échéant, un schéma européen de certification couvrant les exigences applicables. À défaut, il doit suivre une procédure impliquant un organisme notifié, telle que l’examen UE de type suivi du contrôle interne de la production ou l’assurance complète de la qualité.
3. Produits critiques au sens de l’Annexe IV
Les produits critiques sont des produits comportant des éléments numériques dont certaines entités essentielles peuvent dépendre de manière critique pour exercer leurs activités.
Les incidents ou l’exploitation de vulnérabilités affectant ces produits peuvent également entraîner de graves perturbations des chaînes d’approvisionnement critiques du marché intérieur.
Ces produits sont énumérés à l’Annexe IV du Cyber Resilience Act.
Cas d’usage n°5 : Module cryptographique sécurisé pour infrastructure hospitalière
Présentation du produit
Un fabricant développe un module matériel de sécurité destiné à protéger les accès, les échanges de données et les opérations cryptographiques au sein du système d’information d’un établissement hospitalier.
Le module est notamment utilisé pour sécuriser l’accès à une plateforme d’IA assistant les professionnels de santé dans l’analyse d’images médicales. Il ne réalise lui-même aucun diagnostic et n’intervient pas dans les résultats produits par la plateforme.
Pour fonctionner, le produit intègre :
- Un environnement matériel sécurisé permettant de générer et de stocker des clés cryptographiques ;
- Des mécanismes de chiffrement et de déchiffrement des données ;
- Des fonctions de signature électronique et de vérification de l’intégrité des échanges ;
- Des interfaces de communication avec les applications et les serveurs de l’établissement ;
- Un système de gestion des identités, des habilitations et des accès administrateurs ;
- Un système d’IA analysant les comportements d’accès afin de détecter les activités inhabituelles.
Lorsqu’une anomalie est détectée, le produit peut générer une alerte ou déclencher des mesures de protection prédéfinies, telles que le blocage temporaire d’une tentative d’accès.
Qualification réglementaire
Au sens du CRA, le module constitue un produit comportant des éléments numériques puisqu’il associe des composants matériels et logiciels et communique avec les applications, serveurs et réseaux de l’établissement hospitalier.
Sa fonctionnalité de base consiste à assurer un traitement cryptographique sécurisé et à protéger les clés utilisées par le système d’information. Sous réserve de ses caractéristiques techniques précises, il peut donc relever des dispositifs destinés à des fins de sécurité avancées, notamment au traitement cryptographique sécurisé, énumérés à l’Annexe IV du Cyber Resilience Act. Il est alors qualifié de produit critique.
Au sens de l’AI Act, le système d’IA intégré au module cryptographique ne relève pas des catégories de systèmes d’IA à haut risque et présente donc un niveau de risque minimal, dès lors qu’il est uniquement destiné à détecter des anomalies de sécurité et que sa défaillance ne mettrait pas en danger la santé ou la sécurité des personnes.
Risques potentiels
La compromission du module peut notamment entraîner l’exposition ou l’utilisation frauduleuse des clés cryptographiques, le contournement des contrôles d’accès, le déchiffrement de données sensibles, l’altération des échanges ou l’indisponibilité des applications hospitalières protégées.
Mesures de conformité applicables
- Réaliser une évaluation des risques de cybersécurité ;
- Appliquer les exigences essentielles de cybersécurité de l’Annexe I ;
- Mettre en œuvre une conception et une configuration sécurisées par défaut ;
- Protéger les clés cryptographiques contre les accès, extractions et modifications non autorisés ;
- Sécuriser les mécanismes d’authentification, de gestion des habilitations et d’administration ;
- Garantir la confidentialité, l’intégrité, l’authenticité et la disponibilité des données, commandes et opérations cryptographiques ;
- Enregistrer et surveiller les événements de sécurité pertinents ;
- Identifier, documenter et corriger les vulnérabilités ;
- Distribuer de manière sécurisée les mises à jour de sécurité pendant la période de support ;
- Établir la documentation technique et la déclaration UE de conformité ;
- Apposer le marquage CE.
Le fabricant doit notamment :
En tant que produit critique, le module est soumis à une procédure d’évaluation de la conformité renforcée. Lorsqu’un acte délégué impose le recours à un schéma européen de certification de cybersécurité, le fabricant doit obtenir le certificat correspondant. À défaut, il doit appliquer l’une des procédures prévues pour les produits importants de classe II, notamment l’examen UE de type suivi du contrôle interne de la production ou l’assurance complète de la qualité.
Cas d’usage n°6 : Carte à puce de contrôle d’accès pour réseau électrique
Présentation du produit
Un fabricant développe une carte à puce sécurisée destinée aux opérateurs chargés de l’exploitation et de la maintenance d’infrastructures électriques.
La carte permet d’authentifier les techniciens et de contrôler leur accès aux locaux sensibles, aux postes de travail d’administration et aux systèmes de supervision du réseau électrique.
Pour fonctionner, le produit intègre :
- Un composant matériel sécurisé permettant de stocker les données d’identification et les clés cryptographiques ;
- Un mécanisme d’authentification de l’utilisateur ;
- Des fonctions de signature et de chiffrement des échanges ;
- Une interface de communication avec les lecteurs de cartes et les postes d’administration ;
- Un système de gestion des certificats et des droits d’accès ;
- Des mécanismes de protection contre l’extraction ou la modification non autorisée des données stockées.
Qualification au sens du CRA
La carte à puce constitue un produit comportant des éléments numériques puisqu’elle associe des composants matériels et logiciels et communique avec des lecteurs, des postes d’administration et des systèmes de contrôle d’accès.
Sa fonctionnalité de base correspond à la catégorie des cartes à puce ou dispositifs similaires, y compris les éléments sécurisés, expressément énumérée à l’Annexe IV du Cyber Resilience Act. Elle est donc qualifiée de produit critique.
Cette qualification repose sur la fonctionnalité de base de la carte à puce, et non sur son utilisation dans le secteur de l’énergie. En effet, la fonctionnalité de base du produit détermine son rattachement à une catégorie de produits importants ou critiques et, par conséquent, la procédure d’évaluation de la conformité applicable.
Risques potentiels
La compromission de la carte peut notamment entraîner l’usurpation de l’identité d’un technicien, l’accès non autorisé aux systèmes d’administration, l’extraction ou l’utilisation frauduleuse des clés cryptographiques, l’altération des droits d’accès ou la perturbation des opérations d’exploitation du réseau électrique.
Mesures de conformité applicables
Le fabricant doit donc notamment :
- Réaliser une évaluation des risques de cybersécurité ;
- Appliquer les exigences essentielles de cybersécurité de l’Annexe I ;
- Mettre en œuvre une conception et une configuration sécurisées par défaut ;
- Protéger les données d’identification et les clés cryptographiques contre l’accès, l’extraction ou la modification non autorisés ;
- Sécuriser les mécanismes d’authentification, de signature et de communication avec les lecteurs de cartes ;
- Protéger l’intégrité des certificats, des droits d’accès et des autres données stockées ;
- Assurer la résistance du produit aux attaques physiques et logiques pertinentes ;
- Identifier, documenter et corriger les vulnérabilités ;
- Distribuer de manière sécurisée les mises à jour de sécurité pendant la période de support ;
- Établir la documentation technique et la déclaration UE de conformité ;
- Apposer le marquage CE.
En tant que produit critique, la carte à puce ne peut pas faire l’objet d’une simple auto-évaluation. Lorsqu’un acte délégué impose une certification européenne de cybersécurité, le fabricant doit obtenir le certificat correspondant. Dans les autres cas, le produit est soumis à une évaluation obligatoire par un tiers selon les procédures applicables aux produits importants de classe II.
4. Logiciels open source
Le CRA distingue les logiciels libres et open source selon leurs conditions de mise à disposition. Ceux fournis en dehors du cadre d’une activité commerciale ne relèvent pas des obligations applicables aux fabricants. Ceux mis à disposition dans le cadre d’une activité commerciale y sont soumis, tandis que les intendants de logiciels libres bénéficient d’un régime spécifique et allégé.
Cas d’usage n°7 : Bibliothèque open source d’analyse d’images médicales
Présentation du produit
Une communauté de chercheurs développe une bibliothèque logicielle open source destinée à l’analyse d’images médicales dans le cadre de projets de recherche.
La bibliothèque permet aux chercheurs et aux développeurs d’entraîner, d’évaluer et d’utiliser des modèles d’apprentissage automatique pour identifier certaines caractéristiques dans des images radiologiques.
Pour fonctionner, le produit intègre :
- Des fonctions de prétraitement et de classification des données ;
- Des interfaces permettant d’intégrer la bibliothèque dans d’autres applications ;
- Des composants logiciels et bibliothèques open source développés par des tiers ;
- Une documentation technique permettant l’installation et l’utilisation du logiciel.
Le code source est publié gratuitement sous une licence libre et ouverte sur une plateforme collaborative. La communauté ne commercialise pas la bibliothèque, ne facture pas son utilisation et ne fournit pas de service payant associé.
Qualification réglementaire
Au sens du CRA, la bibliothèque constitue un produit logiciel comportant des éléments numériques. Toutefois, les logiciels libres et open source ne relèvent du champ d’application du CRA que lorsqu’ils sont mis à disposition sur le marché, c’est-à-dire fournis aux fins de distribution ou d’utilisation dans le cadre d’une activité commerciale.
Dans ce cas, la bibliothèque est développée et fournie gratuitement, sans monétisation par ses développeurs et en dehors du cadre d’une activité commerciale. Elle n’est donc pas soumise aux obligations du CRA applicables aux fabricants.
Cette qualification devra néanmoins être réévaluée si la bibliothèque est ultérieurement commercialisée, intégrée dans un produit mis sur le marché ou accompagnée de services susceptibles de caractériser une activité commerciale.
Risques potentiels
Malgré l’absence d’obligations applicables au fabricant au titre du CRA, la bibliothèque peut notamment présenter des vulnérabilités dans son code ou ses dépendances, permettre l’exécution de composants malveillants, compromettre la confidentialité ou l’intégrité des images traitées, ou transmettre ces vulnérabilités aux produits dans lesquels elle est intégrée.
Mesures de cybersécurité recommandées
La communauté peut notamment :
- Documenter les composants et dépendances intégrés à la bibliothèque ;
- Mettre en place des procédures de revue et de sécurisation du code ;
- Identifier, documenter et traiter les vulnérabilités signalées ;
- Publier une politique de divulgation coordonnée des vulnérabilités ;
- Mettre à disposition un point de contact permettant leur signalement ;
- Distribuer les correctifs et mises à jour au moyen de mécanismes sécurisés ;
- Informer les utilisateurs des vulnérabilités connues et des mesures correctives disponibles.
Si une personne morale apporte un soutien systématique et durable au développement de cette bibliothèque, destinée à être utilisée dans le cadre d’activités commerciales, et joue un rôle essentiel dans sa viabilité, elle peut être qualifiée d’intendant de logiciels libres et relever des obligations spécifiques prévues à l’article 24 du CRA. Celles-ci comprennent notamment l’adoption d’une politique de cybersécurité, la coopération avec les autorités de surveillance du marché et certaines obligations de signalement des vulnérabilités et incidents.
Cas d’usage n°8 : Pare-feu open source maintenu commercialement
Présentation du produit
Une entreprise développe et commercialise une distribution professionnelle d’un pare-feu reposant sur un logiciel open source.
Le produit est destiné aux entreprises et aux administrations qui souhaitent contrôler les communications entre leurs réseaux internes, Internet et leurs différents systèmes d’information.
Pour fonctionner, le produit intègre :
- Un moteur de filtrage du trafic réseau ;
- Des règles permettant d’autoriser ou de bloquer certaines communications ;
- Une interface d’administration permettant de configurer les politiques de sécurité ;
- Des fonctions de journalisation et de surveillance des événements réseau ;
- Des composants et bibliothèques logiciels open source ;
- Un mécanisme permettant de distribuer et d’installer les mises à jour de sécurité.
L’entreprise commercialise le produit sous son propre nom et propose des services de maintenance, d’assistance technique et de fourniture de mises à jour.
Qualification au sens du CRA
Le pare-feu constitue un produit comportant des éléments numériques puisqu’il s’agit d’un logiciel destiné à être connecté aux réseaux et systèmes d’information de ses utilisateurs.
Bien qu’il repose sur un logiciel open source, il est mis à disposition dans le cadre d’une activité commerciale. L’entreprise qui le commercialise sous son nom ou sa marque est donc soumise aux obligations du CRA applicables aux fabricants de produits comportant des éléments numériques.
Sa fonctionnalité de base correspond à la catégorie des pare-feu et systèmes de détection ou de prévention des intrusions, expressément énumérée à l’Annexe III du Cyber Resilience Act. Il est donc qualifié de produit important de classe II.
Risques potentiels
La compromission du pare-feu peut notamment permettre le contournement des règles de filtrage, l’accès non autorisé au réseau protégé, l’interception ou l’altération des communications, l’exécution de code malveillant ou l’indisponibilité des systèmes et services concernés.
Mesures de conformité applicables
Le fabricant doit donc notamment :
- Réaliser une évaluation des risques de cybersécurité ;
- Appliquer les exigences essentielles de cybersécurité de l’Annexe I ;
- Mettre en œuvre une conception et une configuration sécurisées par défaut ;
- Protéger les fonctions d’administration contre les accès non autorisés ;
- Assurer la confidentialité et l’intégrité des communications et des paramètres de configuration ;
- Limiter les interfaces, services et droits d’accès au strict nécessaire ;
- Recenser les composants intégrés au produit, y compris les composants open source ;
- Identifier, documenter et corriger les vulnérabilités ;
- Mettre en place une politique de divulgation coordonnée des vulnérabilités ;
- Distribuer de manière sécurisée les mises à jour pendant la période de support ;
- Notifier les vulnérabilités activement exploitées et les incidents graves conformément au CRA ;
- Établir la documentation technique et la déclaration UE de conformité ;
- Apposer le marquage CE.
En tant que produit important de classe II, le pare-feu doit obligatoirement faire l’objet d’une évaluation par un organisme notifié. Le fabricant doit recourir à l’examen UE de type suivi de la conformité au type sur la base du contrôle interne de la production, ou à une évaluation fondée sur l’assurance complète de la qualité. L’auto-évaluation n’est pas admise pour cette catégorie de produits.
Ce qu’il faut retenir
Le Cyber Resilience Act couvre une grande diversité de produits comportant des éléments numériques, qu’ils intègrent ou non de l’intelligence artificielle : équipements connectés, logiciels industriels, assistants pour maison connectée, composants cryptographiques ou encore logiciels open source commercialisés.
La qualification du produit constitue le point de départ de toute démarche de conformité. Elle permet de déterminer les exigences de cybersécurité applicables, la procédure d’évaluation de la conformité à suivre, l’intervention éventuelle d’un organisme tiers ainsi que les obligations relatives à la documentation et à la gestion des vulnérabilités.
Passez de l’analyse réglementaire à la mise en conformité opérationnelle
Le CRA s’inscrit dans un environnement réglementaire plus large, comprenant notamment l’AI Act, le RGPD, la directive NIS2 et les réglementations sectorielles. Pour assurer une conformité cohérente, les organisations doivent identifier les interactions entre ces différents cadres et centraliser leur pilotage.
Chez Naaia, nous aidons les organisations à structurer et piloter leur conformité grâce à une plateforme dédiée au management de l’intelligence artificielle.
Notre plateforme permet notamment de :
- Qualifier vos produits et systèmes d’IA ;
- Cartographier les exigences réglementaires applicables ;
- Réaliser vos évaluations de risques ;
- Documenter vos mesures de conformité ;
- Piloter la gestion continue des obligations CRA, AI Act et cybersécurité.
Vous souhaitez évaluer les impacts du CRA sur votre portefeuille de produits ? Découvrez la plateforme Naaia et transformez vos obligations réglementaires en un plan d’action concret et pilotable.
Anticiper l’imbrication des réglementations numériques avec Naaia
Avec Naaia, identifiez automatiquement les produits concernés par le CRA, déterminez les obligations applicables à chaque acteur de votre chaîne de valeur et pilotez votre mise en conformité grâce à un plan d’action opérationnel, centralisé et continuellement actualisé. En centralisant la cartographie des produits et systèmes, la qualification des rôles et des cas d’usage, le pilotage des obligations et la traçabilité des décisions, Naaia aide les organisations à passer d’une conformité fragmentée à une gouvernance numérique cohérente, articulant AI Act, RGPD et Cyber Resilience Act.
