Signalement CRA : 24 heures, 72 heures, puis le rapport final

Depuis le 11 septembre 2026, le Cyber Resilience Act (CRA), ou règlement sur la cyberrésilience, vous oblige à signaler toute faille activement exploitée dans votre produit, et tout incident grave qui touche sa sécurité. Vous avez 24 heures pour une alerte précoce, 72 heures pour une notification, puis un délai fixe pour le rapport final. Tout passe par la plateforme unique de signalement de l’ENISA (article 14).

L’obligation vaut aussi pour les produits vendus avant cette date (article 69, paragraphe 3).

Ce qui déclenche l’obligation

Deux situations, pas une.

Une vulnérabilité activement exploitée. Le règlement la définit comme une faille pour laquelle il existe des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’accord de son propriétaire (article 3). Une faille théorique, même grave, ne suffit pas. Il faut une exploitation réelle.

Un incident grave ayant un impact sur la sécurité du produit. Il est grave s’il nuit, ou risque de nuire, à la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles, ou s’il a conduit à faire tourner du code malveillant dans le produit ou chez l’utilisateur (article 14, paragraphe 5).

Le délai court dès que vous en avez connaissance.

Les délais

Étape	Faille activement exploitée	Incident grave
Alerte précoce	24 heures au plus tard (art. 14(2)(a))	24 heures au plus tard (art. 14(4)(a))
Notification	72 heures au plus tard (art. 14(2)(b))	72 heures au plus tard (art. 14(4)(b))
Rapport final	14 jours au plus tard après la mise à disposition d’un correctif ou d’une mesure d’atténuation (art. 14(2)(c))	1 mois au plus tard après la notification (art. 14(4)(c))

Le texte dit « sans retard injustifié et, en tout état de cause » dans ces délais. Les heures sont un plafond, pas un objectif.

Ce que chaque envoi contient

L’alerte précoce est courte. Pour une faille, vous indiquez, si vous les connaissez, les États membres où le produit est vendu. Pour un incident, vous dites en plus s’il pourrait venir d’un acte illicite ou malveillant.

La notification à 72 heures donne les informations générales : le produit concerné, la nature de la faille et de son exploitation (ou de l’incident), ce que vous avez déjà fait pour corriger ou limiter les dégâts, et ce que les utilisateurs peuvent faire eux-mêmes. Vous pouvez préciser à quel point ces informations sont sensibles.

Le rapport final pour une faille décrit sa gravité et son impact, l’acteur malveillant s’il est connu, et la mise à jour ou la mesure qui la corrige. Pour un incident, il décrit l’incident en détail, sa cause probable et les mesures prises ou en cours.

Le CSIRT qui reçoit votre envoi peut aussi demander un rapport intermédiaire (article 14, paragraphe 6). Un CSIRT est l’équipe publique de réponse aux incidents informatiques.

Où envoyer

Vous notifiez en même temps le CSIRT désigné comme coordinateur et l’ENISA, via la plateforme unique de signalement de l’article 16. Le bon CSIRT est celui de l’État membre où vous avez votre établissement principal dans l’Union, c’est-à-dire là où se prennent surtout les décisions de cybersécurité sur vos produits (article 14, paragraphe 7).

En France, c’est le CERT-FR, le CSIRT de l’ANSSI. Notre page sur l’ANSSI et le CRA explique la répartition des rôles.

La plateforme de l’ENISA fonctionne depuis le 11 septembre 2026 dans une version de base. Elle n’a pas d’interface machine : aucun outil ne peut y déposer un signalement à votre place. Quelqu’un chez vous doit s’y connecter et envoyer.

Prévenir vos utilisateurs

Le signalement aux autorités ne suffit pas. Vous devez aussi informer les utilisateurs touchés, et si besoin tous les utilisateurs, de la faille ou de l’incident et des mesures qu’ils peuvent prendre (article 14, paragraphe 8). Si possible, dans un format structuré lisible par machine. Si vous tardez, le CSIRT peut prévenir les utilisateurs lui-même.

Le cas des petites entreprises

Les microentreprises et les petites entreprises ne reçoivent pas d’amende administrative si elles manquent le délai de 24 heures de l’alerte précoce (article 64, paragraphe 10, point a). C’est la seule souplesse. La notification à 72 heures, le rapport final et l’information des utilisateurs restent dus, avec les amendes qui vont avec. Notre guide CRA et PME détaille les seuils.

Ce qui rend les 24 heures difficiles

Le délai est court pour une raison simple : vous apprenez souvent l’exploitation par quelqu’un d’autre. Un chercheur, un client, un bulletin public. Si vous ne savez pas quelle version d’OpenSSL ou de BusyBox tourne dans le firmware 2.3 vendu l’an dernier, vous perdez la journée à chercher au lieu d’écrire.

Trois choses à préparer avant que cela arrive :

• la liste des composants et des versions de chaque produit et de chaque version encore en circulation ;
• un nom, et un suppléant, pour décider et envoyer, avec un compte sur la plateforme de l’ENISA ;
• un brouillon d’alerte et de message aux utilisateurs, à compléter le jour venu.

Ce que fait Proofsheet

Le rapport que génère Proofsheet contient déjà la liste des composants et des versions de votre fichier, avec les failles connues de la base NVD, en signalant celles qui figurent sur la liste des failles exploitées de la CISA, l’agence américaine de cybersécurité. Le dossier à 249 € inclut un guide du signalement de l’article 14.

Watchdog, un abonnement logiciel à 79 € par mois, ouvre bientôt. Il réanalyse chaque nouvelle version, vous envoie une alerte par e-mail quand un composant que vous utilisez apparaît sur la liste de la CISA, et génère le kit 24 heures : alerte précoce, notification à 72 heures, rapport final et message aux utilisateurs. Vous relisez, vous complétez, et c’est vous qui envoyez sur la plateforme de l’ENISA. L’application ne dépose rien en votre nom. Les textes générés sont des brouillons techniques, pas un avis juridique.

Découvrir Watchdog et le kit 24 heures, ou lisez le guide sur le SBOM.