Cyber Resilience Act étape par étape : préparation pour les fabricants

Un parcours pratique de préparation au CRA pour les fabricants : confirmez le champ d'application et la classification, comblez les lacunes des annexes I, mettez en œuvre la gestion et le signalement des vulnérabilités, et planifiez l'évaluation de la conformité et le marquage CE avant décembre 2027.

Ce guide s'adresse aux fabricants de matériel et de logiciels connectés, ainsi qu'aux équipes de sécurité des produits, d'ingénierie et de conformité qui doivent mettre en œuvre le Cyber Resilience Act (CRA). Les rôles des importateurs, distributeurs et responsables de logiciels libres sont également couverts. À la fin, vous aurez confirmé le périmètre et le rôle par produit, pris une décision de classification, effectué une analyse des écarts de l'annexe I, mis en place un processus opérationnel de traitement et de signalement des vulnérabilités, et établi un plan pour la documentation, l'évaluation de la conformité et le marquage CE.

Avant de commencer

Le CRA est une législation relative aux produits dans la tradition du marquage CE, et non une norme organisationnelle comme ISO/IEC 27001. La conformité est évaluée par produit. Vous avez besoin d'une liste de portefeuille qui inclut les produits logiciels uniquement, les microprogrammes, les applications complémentaires et les serveurs dorsaux cloud ; d'un responsable de la sécurité des produits nommé (généralement un responsable PSIRT) ayant une influence sur les décisions de mise en production ; et d'un accès aux diagrammes d'architecture, aux pipelines de compilation et aux manifestes de dépendances. Le texte juridique se trouve sur EUR-Lex^[1], et la Commission publie des orientations et des questions fréquemment posées sur sa page de mise en œuvre^[3]. Pour un aperçu, consultez notre page Cyber Resilience Act.

Étape 1 : Confirmez le champ d'application et votre rôle par produit

Le CRA couvre les produits comportant des éléments numériques dont l'utilisation prévue ou raisonnablement prévisible inclut une connexion de données à un appareil ou à un réseau, y compris le traitement des données à distance qu'un produit doit effectuer pour remplir ses fonctions. Les produits couverts par des règles sectorielles spécifiques, tels que les dispositifs médicaux, les véhicules automobiles et l'aviation civile, sont exclus. Les services SaaS autonomes relèvent généralement de NIS2 plutôt que du CRA.

• Enregistrez par produit s'il est dans le champ d'application et toute exclusion sur laquelle vous vous appuyez.
• Déterminez votre rôle. Un fabricant développe le produit ou le fait développer et le commercialise sous son propre nom. Un importateur place le produit d'un fabricant non-UE sur le marché de l'UE. Un distributeur le met à disposition plus loin dans la chaîne. Un gestionnaire de logiciels libres et open source est une personne morale qui soutient systématiquement les logiciels libres et open source destinés à des activités commerciales.
• Attention aux changements de rôle : un importateur ou un distributeur qui rebaptise ou modifie substantiellement un produit assume les obligations du fabricant.
• Listez les produits déjà sur le marché. Ils ne sont soumis aux exigences complètes que s'ils sont substantiellement modifiés après le 11 décembre 2027, mais le signalement au titre de l'article 14 leur est applicable.

Étape 2 : Classer chaque produit

La plupart des produits relèvent de la catégorie par défaut. L'annexe III énumère les produits importants. La classe I comprend les systèmes d'exploitation, les navigateurs, les gestionnaires de mots de passe, les VPN, les routeurs, les systèmes SIEM et les produits de sécurité pour maison intelligente tels que les serrures et les caméras. La classe II comprend les hyperviseurs et les environnements d'exécution de conteneurs, les pare-feu et les systèmes de détection ou de prévention des intrusions, ainsi que les microprocesseurs et microcontrôleurs résistants aux altérations. L'annexe IV énumère les produits critiques : les appareils matériels dotés de boîtes de sécurité, les passerelles de compteurs intelligents et les cartes à puce et éléments sécurisés.

Le règlement d'exécution (UE) 2025/2392 du 28 novembre 2025 donne la description technique de chaque catégorie et est entré en vigueur le 21 décembre 2025^[2]. Ce qui compte, c'est la fonctionnalité principale du produit. Un produit qui intègre simplement un composant énuméré ne devient pas un produit important pour cette seule raison.

• Comparez la fonctionnalité principale de chaque produit avec les descriptions du règlement d'exécution, et non seulement les étiquettes courtes des annexes.
• Rédigez une courte justification par produit, en particulier pour les cas limites.

Étape 3 : Évaluer les risques et mettre en correspondance les lacunes par rapport à l'annexe I

L'article 13 exige une évaluation des risques de cybersécurité qui informe la planification, la conception, le développement, la production, la livraison et la maintenance, et qui détermine comment chaque exigence de l'annexe I s'applique. L'annexe I, partie I, demande, en résumé, des produits livrés sans vulnérabilités exploitables connues, avec une configuration sécurisée par défaut, avec des mises à jour de sécurité (automatiques par défaut le cas échéant), un contrôle d'accès, une protection de la confidentialité et de l'intégrité, une minimisation des données, une disponibilité, une surface d'attaque limitée, une réduction de l'impact des incidents, une journalisation de la sécurité et une suppression sécurisée des données.

• Modélisez les menaces pour chaque produit ou famille de produits sur le matériel, le micrologiciel, les logiciels et le serveur principal.
• Pour chaque exigence de l'annexe I, enregistrez l'applicabilité, la façon dont elle est satisfaite, les preuves et l'écart restant. Justifiez tout ce qui est marqué comme non applicable.

Le modèle d'accompagnement comprend une liste de contrôle de l'annexe I couvrant chaque exigence des parties I et II, une feuille de calcul de classification et un calendrier.

Étape 4 : Mettre en place la gestion des vulnérabilités, y compris une SBOM

L'annexe I partie II s'applique pendant toute la période de support. Les fabricants doivent documenter les composants, y compris une nomenclature des logiciels (SBOM) dans un format commun lisible par machine couvrant au moins les dépendances de premier niveau ; corriger les vulnérabilités sans délai ; tester régulièrement ; divulguer les vulnérabilités corrigées ; maintenir une politique de divulgation coordonnée des vulnérabilités (CVD) et un contact de signalement ; distribuer les mises à jour de manière sécurisée ; et fournir les mises à jour de sécurité gratuitement avec des avis de sécurité.

• Générez des SBOM par build (SPDX ou CycloneDX) et stockez-les par version. Vous n'avez pas à les publier.
• Définissez la période de support : au moins cinq ans sauf si le produit est censé être utilisé moins longtemps, et visible pour les acheteurs.
• Publiez une politique CVD et un contact de sécurité, par exemple via security.txt, et mettez en place un processus d'intake PSIRT avec des objectifs de triage.
• Signalez les vulnérabilités que vous trouvez dans les composants intégrés, y compris le code open source, à leurs responsables.

Étape 5 : Rendre la déclaration opérationnelle maintenant

Depuis le 11 septembre 2026, les fabricants doivent notifier chaque vulnérabilité activement exploitée et chaque incident grave affectant la sécurité du produit via la plateforme de notification unique d'ENISA^[4]. Le rapport parvient simultanément au CSIRT coordinateur de l'État membre de l'établissement principal et à ENISA.

Étape	Vulnérabilité activement exploitée	Incident grave
Alerte précoce	24 heures après en avoir pris connaissance	24 heures après en avoir pris connaissance
Notification	72 heures après en avoir pris connaissance	72 heures après en avoir pris connaissance
Rapport final	14 jours après la disponibilité d'une mesure corrective	Un mois après la notification

• Définissez qui décide qu'une vulnérabilité est activement exploitée, et quand le délai commence.
• Inscrivez-vous sur la plateforme et répétez une soumission.
• Préparez des modèles de rapport et un processus pour informer les utilisateurs affectés. Notre guide opérationnel de notification des incidents aligne la notification CRA avec NIS2, DORA et RGPD.

Étape 6 : Choisir la voie d'évaluation de la conformité

Selon l'article 32, les produits par défaut peuvent utiliser le contrôle interne (module A). Les produits importants de classe I ne peuvent utiliser le module A que si des normes harmonisées, des spécifications communes ou un schéma de certification au niveau « substantiel » ont été entièrement appliqués ; sinon, ils ont besoin des modules B et C ou du module H avec un organisme notifié. Les produits de classe II nécessitent toujours un tiers. Les produits critiques doivent utiliser un schéma européen de certification en cybersécurité lorsqu'un acte délégué l'exige, sinon les routes de classe II s'appliquent. Les produits libres et open-source importants peuvent utiliser le module A si leur documentation technique est publique.

• Suivez les normes harmonisées. Au moment de la rédaction, la Commission prévoit les premiers livrables en 2026 et d'autres en 2027^[3].
• Si vous avez besoin d'un organisme notifié, réservez rapidement. Leurs règles s'appliquent à partir du 11 juin 2026 et les capacités seront limitées à proximité de décembre 2027.

Étape 7 : Compiler la documentation technique

L'article 31 et l'annexe VII exigent une documentation couvrant le produit et son usage prévu, la conception et la production, le processus de gestion des vulnérabilités, la SBOM, l'évaluation des risques, la justification de la période de support, les normes appliquées, les rapports d'essai et la déclaration de conformité. Conservez-la pendant dix ans après la mise sur le marché, ou pendant la période de support si elle est plus longue. L'annexe II définit les informations destinées à l'utilisateur, y compris le contact pour les vulnérabilités et la fin du support.

Dans Secrato, cette étape correspond à Politiques et preuves, où chaque résultat de contrôle de l'annexe I et ses preuves sont liés à l'ensemble de documentation du produit.

Étape 8 : Déclarer la conformité, apposer le marquage CE et assurer la maintenance

Après l'évaluation, établissez la déclaration UE de conformité (article 28, annexe V) et apposez le marquage CE (article 30). Pour les logiciels, il peut être placé sur la déclaration ou sur le site web d'accompagnement. La conformité se poursuit pendant la période de support : continuez à gérer les vulnérabilités, maintenez chaque mise à jour de sécurité disponible pendant au moins dix ans ou la période de support restante si elle est plus longue, et évaluez si les modifications constituent des modifications substantielles nécessitant une nouvelle évaluation.

• Informez les importateurs et distributeurs sur ce qu'ils doivent vérifier avant de vendre.
• Réexaminez l'évaluation des risques et la matrice de l'annexe I à chaque version majeure, et tenez un examen de direction annuel.

Comment cela se connecte à d'autres référentiels

Le CRA réglemente le produit ; NIS2, ISO/IEC 27001 et CyFun réglementent l'organisation. Le développement sécurisé, la gestion des vulnérabilités, la gestion des fournisseurs et la réponse aux incidents au titre de l'annexe A d'ISO/IEC 27001 ou de l'article 21 de NIS2 fournissent toujours une grande partie des preuves de processus que le CRA attend. En l'absence de normes harmonisées CRA, IEC 62443-4-1 et 4-2 (industriel) et ETSI EN 303 645 (IoT grand public) sont des références utiles.

Questions fréquemment posées

Le CRA s'applique-t-il aux produits que nous vendons déjà ?

Les produits mis sur le marché avant le 11 décembre 2027 ne doivent respecter les exigences complètes que s'ils sont substantiellement modifiés par la suite. L'article 14 relatif aux rapports s'applique à partir du 11 septembre 2026.

Devons-nous publier notre nomenclature des composants ?

Non. Elle fait partie de la documentation technique et doit être fournie aux autorités de surveillance du marché sur demande.

Nous développons uniquement des logiciels libres. Sommes-nous un fabricant ?

Pas nécessairement. Les logiciels libres fournis en dehors d'une activité commerciale sont hors du champ d'application. Une fondation qui les soutient systématiquement pour un usage commercial peut être un gestionnaire, avec un régime allégé et sans amendes. Si vous monétisez le produit lui-même, vous êtes probablement un fabricant.

Le SaaS est-il concerné ?

Le SaaS autonome ne l'est généralement pas. Un back-end cloud dont un appareil a besoin pour remplir ses fonctions fait partie de ce produit.

Quels outils aident les fabricants de logiciels à se préparer au CRA ?

Commencez par notre liste de contrôle de préparation au CRA gratuite pour voir où se situe chaque produit. Une plateforme GRC comme Secrato met ensuite en correspondance les exigences du CRA avec les contrôles, responsables et preuves, et vous permet de réutiliser le travail déjà effectué pour ISO/IEC 27001 ou NIS2.