Le Cyber Resilience Act (règlement (UE) 2024/2847) conditionne la mise sur le marché européen des produits comportant des éléments numériques au respect d’exigences essentielles de cybersécurité. Réunies à l’annexe I du règlement, elles portent, d’une part sur les propriétés du produit (treize exigences), et d’autre part sur la gestion des vulnérabilités par le fabricant (huit exigences).
Ces exigences définissent des objectifs de sécurité applicables à tout produit comportant des éléments numériques, et non des solutions techniques. Il appartient au fabricant de déterminer, à partir de son évaluation des risques, celles qui s’appliquent à son produit et la manière de les mettre en œuvre, puis d’en apporter la preuve dans la documentation technique. Cet article présente chacune de ces exigences, ce qu’elle implique concrètement et les éléments permettant d’en démontrer le respect.
Pour une vue d’ensemble du règlement (champ d’application, classification des produits, opérateurs, calendrier et sanctions), consultez notre article Le Cyber Resilience Act (CRA) : décryptage global du nouveau cadre européen de cybersécurité des produits numériques.
Comment lire les exigences essentielles ?
Avant d’énumérer les exigences détaillées, l’annexe I du CRA pose une règle générale : le niveau de cybersécurité du produit doit être approprié aux risques, dès sa conception, et durant tout son développement et sa mise à disposition sur le marché.
Les exigences détaillées de la partie I s’appliquent ensuite « sur la base de l’évaluation des risques de cybersécurité ». Une exigence peut donc être jugée non applicable, à condition que ce choix soit justifié dans la documentation technique. Les exigences de la partie II s’imposent quant à elles au fabricant pendant toute la période d’assistance du produit.
Partie I : les exigences relatives aux propriétés du produit
a) Aucune vulnérabilité exploitable connue
Le produit doit être mis sur le marché sans vulnérabilité exploitable connue. L’exigence ne vise pas l’absence de toute faille, elle interdit de commercialiser un produit alors qu’une vulnérabilité connue, et effectivement exploitable dans ce produit, n’a pas été corrigée ou atténuée.
En pratique, le fabricant confronte les composants de son produit aux bases de vulnérabilités publiques et réalise des scans et des tests d’intrusion avant la mise sur le marché. Lorsqu’une vulnérabilité connue n’est pas exploitable dans son produit, par exemple parce que le code concerné n’est pas atteignable, il le justifie dans sa documentation.
b) Une configuration sécurisée par défaut
Le produit doit être livré « avec une configuration de sécurité par défaut », c’est-à-dire que celui-ci doit être sûr dès sa première mise en service, sans que l’utilisateur ait à modifier ses réglages ou paramètres. Cela exclut notamment les mots de passe identiques sur tous les appareils et les services non indispensables activés d’office.
Le texte impose également la possibilité de réinitialiser le produit à son état d’origine. Seul un produit sur mesure peut déroger à cette exigence, en cas d’accord contraire entre le fabricant et l’entreprise utilisatrice. La configuration d’usine et la procédure de réinitialisation sont décrites dans la documentation technique et dans la notice d’utilisation.
c) La correction des vulnérabilités par des mises à jour de sécurité
Le produit doit être conçu pour que ses vulnérabilités puissent être corrigées par des mises à jour de sécurité. Lorsque c’est pertinent, ces mises à jour sont automatiques et activées par défaut. L’utilisateur doit alors pouvoir les désactiver facilement, être informé des mises à jour disponibles et pouvoir les reporter temporairement.
Le fabricant décrit le mécanisme de mise à jour retenu et les options proposées à l’utilisateur. La notice explique comment désactiver l’installation automatique, ce qui fait partie des informations qu’elle doit obligatoirement contenir.
d) La protection contre les accès non autorisés
Le produit doit disposer de mécanismes de contrôle des accès adaptés, tels que l’authentification et la gestion des identités et des droits, et signaler tout accès non autorisé.
Selon les risques, cela peut se traduire par une politique de mots de passe robustes, une authentification multifacteurs pour les fonctions d’administration, un verrouillage après plusieurs tentatives infructueuses et une alerte en cas d’accès suspect.
e) La protection de la confidentialité des données
Les données stockées, transmises ou traitées, qu’elles soient personnelles ou non, doivent être protégées contre tout accès non autorisé. Le chiffrement au repos et en transit, au moyen de mécanismes conformes à l’état de l’art, en est l’exemple type.
Le fabricant identifie les données sensibles traitées par le produit et documente les protocoles et algorithmes utilisés, ainsi que la manière dont les clés de chiffrement sont générées, stockées et renouvelées.
f) La protection de l’intégrité des données, des commandes et des programmes
Le produit doit empêcher toute manipulation non autorisée de ses données, de ses commandes, de ses programmes et de sa configuration, et signaler les corruptions.
La signature et la vérification du micrologiciel, le démarrage sécurisé ou le contrôle d’intégrité des messages reçus sont des mesures courantes, complétées par des alertes lorsqu’une altération est détectée.
g) La minimisation des données
Le produit ne doit traiter que les données adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité prévue. Cette exigence s’applique aux données personnelles comme aux autres données.
Une cartographie des données collectées, assortie d’une justification de chacune au regard de l’utilisation prévue, permet d’en rendre compte. Un thermostat connecté, par exemple, n’a pas besoin de la géolocalisation précise de son utilisateur pour réguler la température.
h) La disponibilité des fonctions essentielles
Les fonctions essentielles et de base doivent rester disponibles, y compris après un incident, grâce à des mesures de résilience et d’atténuation, notamment face aux attaques par déni de service.
La limitation du nombre de requêtes, un mode de fonctionnement dégradé en cas d’attaque et des mécanismes de redémarrage sécurisé y contribuent. Leur efficacité est vérifiée par des tests de charge et de résistance.
i) Un impact limité sur les autres appareils et réseaux
Le produit doit réduire au maximum les répercussions négatives qu’il pourrait avoir sur la disponibilité des services fournis par d’autres appareils ou réseaux, par exemple en devenant le relais d’une attaque.
Le fabricant analyse le comportement de son produit en cas de compromission et limite en conséquence le trafic sortant et les services exposés sur le réseau.
j) La limitation des surfaces d’attaque
Le produit doit être conçu, développé et fabriqué de manière à réduire les points d’entrée exploitables, en particulier les interfaces externes.
Cela suppose d’inventorier les ports, services et interfaces, y compris les interfaces de débogage, de désactiver ceux qui ne sont pas nécessaires et de justifier le maintien des autres.
k) La réduction de l’impact d’un incident
Le produit doit intégrer des mécanismes et des techniques limitant les conséquences de l’exploitation d’une faille.
Le cloisonnement des processus, l’application du principe du moindre privilège, les protections mémoire et l’isolation des composants critiques permettent qu’une faille exploitée n’entraîne pas la compromission de l’ensemble du produit.
l) L’enregistrement et la surveillance des activités
Le produit doit fournir des informations relatives à la sécurité en enregistrant et en surveillant les activités internes pertinentes, notamment l’accès aux données, aux services ou aux fonctions et leur modification. L’utilisateur doit pouvoir désactiver ce mécanisme.
Le fabricant définit les événements journalisés, protège les journaux contre toute modification et documente la manière dont l’utilisateur peut désactiver l’enregistrement.
m) La suppression et le transfert sécurisés des données
L’utilisateur doit pouvoir supprimer facilement, en toute sécurité et de manière permanente, toutes ses données et tous ses paramètres. Lorsque ces données peuvent être transférées vers un autre produit ou système, ce transfert doit être sécurisé.
Une fonction d’effacement complet, dont l’efficacité a été vérifiée, répond à cette exigence. La notice d’utilisation explique comment l’utiliser, notamment lors de la mise hors service du produit.
Partie II : les exigences relatives à la gestion des vulnérabilités
1) Recenser les composants et les vulnérabilités
Le fabricant doit recenser et documenter les vulnérabilités et les composants de son produit, notamment au moyen d’une nomenclature logicielle (SBOM) établie dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de niveau supérieur des produits.
Des formats comme SPDX ou CycloneDX sont couramment utilisés à cette fin. La SBOM est mise à jour à chaque version du produit. Elle n’a pas à être publiée : elle est communiquée à l’autorité de surveillance du marché sur demande motivée.
2) Gérer et corriger sans retard
Le fabricant doit traiter et corriger sans retard les vulnérabilités, y compris par des mises à jour de sécurité. Lorsque c’est techniquement possible, ces mises à jour sont fournies séparément des mises à jour fonctionnelles.
Une procédure de tri et de priorisation des vulnérabilités, par exemple fondée sur un score de gravité tel que le CVSS, associée à des délais cibles de correction et à un historique des correctifs publiés, permet d’en rendre compte.
3) Tester régulièrement la sécurité
Le produit doit faire l’objet de tests et d’examens de sécurité efficaces et réguliers.
Le fabricant établit un plan de tests (analyse de code, tests d’intrusion, fuzzing), en fixe la fréquence et conserve les rapports correspondants dans la documentation technique.
4) Communiquer sur les vulnérabilités corrigées
Dès qu’une mise à jour de sécurité est publiée, le fabricant informe sur les vulnérabilités corrigées : description, produits concernés, conséquences, gravité et informations claires pour y remédier. Dans des cas dûment justifiés, il peut retarder cette publication jusqu’à ce que les utilisateurs aient pu appliquer le correctif.
Ces informations prennent généralement la forme d’avis de sécurité publiés sur le site du fabricant, éventuellement dans un format structuré comme le cadre consultatif commun pour la sécurité (CSAF). Une procédure interne encadre les cas dans lesquels la publication peut être reportée.
5) Appliquer une politique de divulgation coordonnée
Le fabricant doit mettre en place et appliquer une politique de divulgation coordonnée des vulnérabilités. Celle-ci organise la manière dont les failles signalées sont reçues, traitées puis rendues publiques.
Cette politique est publiée sur le site du fabricant et peut s’appuyer sur des référentiels reconnus, comme les normes ISO/IEC 29147 et ISO/IEC 30111.
6) Faciliter le partage d’informations
Le fabricant doit prendre des mesures pour faciliter le partage d’informations sur les vulnérabilités potentielles de son produit et des composants tiers qu’il contient, notamment en fournissant une adresse de contact pour les signalements.
Une adresse dédiée ou un formulaire de signalement répondent à cette exigence. Le fabricant prévoit également un processus de remontée des failles vers les fournisseurs des composants concernés.
7) Distribuer les mises à jour de manière sécurisée
Le fabricant doit prévoir des mécanismes de distribution sécurisée des mises à jour afin que les vulnérabilités soient corrigées ou atténuées rapidement et, le cas échéant, de manière automatique.
La signature des mises à jour, un canal de distribution chiffré, la vérification de l’intégrité avant installation et un mécanisme de retour à la version précédente en cas d’échec sont des solutions couramment retenues.
8) Diffuser les correctifs sans retard et gratuitement
Les correctifs et mises à jour de sécurité disponibles doivent être diffusés sans retard, accompagnés de messages fournissant aux utilisateurs les informations utiles, y compris sur les mesures à prendre. Ils sont gratuits, sauf accord contraire entre le fabricant et un utilisateur professionnel pour un produit sur mesure.
Les conditions commerciales du fabricant mentionnent la gratuité des mises à jour de sécurité, et chaque correctif est accompagné d’un avis destiné aux utilisateurs.
Vous souhaitez évaluer vos produits au regard des exigences essentielles du CRA ?
Chez Naaia, nous aidons les organisations à structurer et piloter leur conformité. Notre plateforme vous permet de rattacher chaque exigence essentielle à vos produits, d’en documenter l’applicabilité et les justifications, et de centraliser les preuves associées, de l’évaluation des risques à la gestion des vulnérabilités.
Passez d’une gouvernance de l’IA subie à une gouvernance pilotée.
