Guide du Cyber Resilience Act
Une feuille de route pratique pour les équipes qui construisent des produits comportant des éléments numériques : quoi faire, qui s'en charge et quelles preuves conserver. Pour ce que dit la loi, lisez ce qu'est le Cyber Resilience Act.
Dernière mise à jour le 15 octobre 2026
What the Cyber Resilience Act asks manufacturers to do
Le champ d'application du règlement (UE) 2024/2847, ses dates d'entrée en application, les délais de notification et la place des obligations relatives à la SBOM et à la gestion des vulnérabilités.
Petteri Pulkkinen et Erika Marttinen lors de Kubernetes Community Days Helsinki 2026, 8:03 à 15:20 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Les étapes se suivent à peu près dans l'ordre, mais les étapes 5 à 8 passent en premier pour les produits déjà sur le marché, car le signalement s'y applique dès maintenant.
Listez chaque produit comportant des éléments numériques que vous mettez à disposition dans l'UE, y compris les logiciels vendus séparément et les backends cloud nécessaires au fonctionnement des produits. Pour chacun, confirmez qu'il n'est pas exclu (dispositifs médicaux, véhicules, aéronautique, équipements marins, défense) et si vous en êtes le fabricant, l'importateur ou le distributeur.
Vérifier un produit avec le CRA Checker →La plupart des produits relèvent de la catégorie par défaut. Comparez les vôtres aux listes des produits importants (annexe III) et critiques (annexe IV) ; le règlement d'exécution (UE) 2025/2392 en donne les descriptions techniques. La catégorie détermine si vous pouvez procéder à une auto-évaluation ou s'il vous faut un organisme notifié ou une certification.
Rédigez une évaluation des risques de cybersécurité pour chaque produit. Elle détermine comment s'appliquent les exigences essentielles de l'annexe I et fait partie de la documentation technique. Mettez-la à jour lorsque le produit ou les menaces évoluent.
Décidez pendant combien de temps vous traitez les vulnérabilités de chaque produit : au moins cinq ans, sauf si la durée d'utilisation prévue du produit est plus courte. Informez les utilisateurs de la fin du support et gardez chaque mise à jour de sécurité disponible pendant au moins 10 ans.
Le CRA demande une nomenclature logicielle dans un format courant et lisible par machine, couvrant au moins les dépendances de niveau supérieur. La générer dans le build qui produit la release, plutôt qu'une seule fois à la main, la maintient fidèle à ce qui a été livré.
La place de CRACI : CRACI enregistre la SBOM pendant l'exécution de chaque build, y compris les dépendances transitives et les paquets restaurés depuis les caches, et l'exporte en CycloneDX ou SPDX.
Surveillez les versions publiées, pas seulement la branche principale, face aux nouvelles vulnérabilités pendant toute la période de support. Corrigez-les sans délai, livrez gratuitement les mises à jour de sécurité et, lorsque c'est possible, séparément des mises à jour fonctionnelles.
La place de CRACI : CRACI revérifie les SBOM surveillées face aux nouvelles vulnérabilités après la livraison, et les équipes de sécurité trient les résultats et les transmettent aux équipes responsables de la correction. Les gates de politique peuvent bloquer un build en fonction des résultats.
Donnez aux chercheurs et aux clients un contact pour signaler les vulnérabilités et une politique de divulgation coordonnée des vulnérabilités. Dès qu'une mise à jour est disponible, publiez des informations sur les vulnérabilités qu'elle corrige.
Depuis le 11 septembre 2026, une vulnérabilité activement exploitée ou un incident grave exige une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final, via la plateforme unique de signalement. Désignez qui confirme l'exploitation active, qui dépose les notifications et qui informe les utilisateurs. Le plus difficile est de savoir en quelques heures quels produits et releases contiennent le composant vulnérable.
La place de CRACI : L'historique des builds de CRACI indique quels builds contenaient une dépendance vulnérable, sa vue d'inventaire montre quelles versions sont déployées sur quels produits, et CRACI soumet les notifications prévues par le CRA en votre nom.
Livrez sans vulnérabilité exploitable connue et avec une configuration sécurisée par défaut, protégez les données et les accès, limitez la surface d'attaque et rendez possibles les mises à jour de sécurité, automatiques par défaut le cas échéant. Testez et passez en revue la sécurité régulièrement.
La place de CRACI : CRACI applique une politique de trafic sortant sur ce que les builds peuvent télécharger, et les gates de politique peuvent bloquer un build en fonction des résultats.
Rassemblez la documentation technique décrite à l'annexe VII, réalisez l'évaluation de la conformité correspondant à votre catégorie, établissez la déclaration UE de conformité et apposez le marquage CE. Conservez la documentation et la déclaration pendant au moins 10 ans ou pendant la période de support, la plus longue des deux durées étant retenue.
La place de CRACI : CRACI exporte les SBOM en CycloneDX ou SPDX, y compris les vulnérabilités détectées dans leurs composants, et son API renvoie les SBOM, les traces réseau et la provenance pour votre documentation technique. L'évaluation et la déclaration restent votre processus.
Les autorités de surveillance du marché peuvent demander votre documentation technique. Voici ce que laisse chaque exigence, et ce que CRACI en enregistre à partir de vos builds.
| Exigence | Où | Preuves à conserver | Côté CRACI |
|---|---|---|---|
| Évaluation des risques de cybersécurité | Article 13, annexe I | Évaluation documentée par produit | Votre processus |
| Aucune vulnérabilité exploitable connue à la mise sur le marché | Annexe I, partie I | État des vulnérabilités du build de release | SBOM du build de release contrôlée face aux avis ; gates de politique |
| Nomenclature logicielle | Annexe I, partie II | SBOM lisible par machine pour chaque release | Enregistrée à chaque build, CycloneDX ou SPDX |
| Traitement des vulnérabilités pendant la période de support | Article 13, annexe I, partie II | Résultats, décisions de tri, corrections, avis | Réévaluation continue, tri, VEX |
| Diligence raisonnable sur les composants tiers | Article 13 | Données sur les composants, logiciels achetés compris | SBOM fournisseurs surveillées avec les vôtres ; licences déclarées |
| Signalement des vulnérabilités exploitées et des incidents graves | Article 14 | Alertes précoces, notifications, rapports finaux | Soumet les notifications en votre nom |
| Période de support | Article 13 | Date de fin de support publiée | Votre processus |
| Documentation technique et déclaration | Article 13, annexe VII | Conservées 10 ans ou pendant la période de support | Export de SBOM et données d'API pour la documentation |
Cyber Resilience Act
Utilisez cette checklist pour attribuer les responsabilités et réunir les preuves à mesure que vous préparez au CRA vos produits comportant des éléments numériques.
Les questions pratiques que se posent les équipes qui abordent le CRA
Respecter les exigences essentielles de l'annexe I sur la base d'une évaluation des risques de cybersécurité, tenir une SBOM, traiter les vulnérabilités pendant une période de support d'au moins cinq ans, signaler les vulnérabilités activement exploitées et les incidents graves, tenir une documentation technique, réussir une évaluation de la conformité et apposer le marquage CE.
Par le champ d'application et le signalement. Déterminez quels produits le CRA couvre, puis assurez-vous de pouvoir émettre l'alerte précoce sous 24 heures pour une vulnérabilité activement exploitée, car le signalement s'applique depuis le 11 septembre 2026, y compris pour les produits déjà sur le marché. Le reste s'applique à partir du 11 décembre 2027.
L'annexe VII en dresse la liste. Elle comprend l'évaluation des risques de cybersécurité du produit, la SBOM et des informations sur la façon dont le fabricant traite les vulnérabilités. Elle est conservée pendant au moins 10 ans ou pendant la période de support, la plus longue des deux durées étant retenue, et remise aux autorités de surveillance du marché sur demande.
Non. La SBOM fait partie de la documentation technique et est remise à une autorité de surveillance du marché sur demande. Le règlement n'exige pas de la publier.
Oui. Le 27 juillet 2026, la Commission européenne a publié des orientations non contraignantes, C(2026) 5252, avec 67 exemples pratiques. Elles couvrent le traitement de données à distance, les logiciels libres et open source, la modification substantielle, les périodes de support, le signalement et l'évaluation des risques. Le règlement d'exécution (UE) 2025/2392 décrit les catégories de produits importants et critiques.
Les obligations sont les mêmes, mais les micro et petites entreprises ne sont pas sanctionnées pour le non-respect du délai de 24 heures de l'alerte précoce, et les orientations de la Commission sont rédigées en pensant aux microentreprises et aux PME.
Non. Satisfaire au CRA relève du processus du fabricant, y compris l'évaluation des risques, l'évaluation de la conformité et la déclaration. CRACI automatise une part importante de la visibilité sur la chaîne d'approvisionnement et des preuves requises par ce processus : des SBOM à chaque build, le suivi des vulnérabilités après la release et les notifications prévues par le CRA.
Découvrez comment CRACI enregistre une SBOM à chaque build, surveille ce que vous avez livré et soumet les notifications prévues par le CRA en votre nom