Signalements CRA : l’horloge de 24 h, 72 h et 14 jours expliquée

Depuis le 11 septembre 2026, tout fabricant d’un produit couvert par le Cyber Resilience Act doit signaler deux types d’événements aux autorités : les vulnérabilités activement exploitées dans ses produits, et les incidents graves qui touchent leur sécurité. L’obligation vaut pour tous les produits concernés déjà sur le marché de l’UE, pas seulement pour les nouveaux. Les signalements passent par la plateforme unique de signalement de l’ENISA, qui les transmet en un seul envoi au CSIRT désigné comme coordinateur et à l’ENISA.

Ce qui déclenche l’horloge

Une vulnérabilité activement exploitée

Une vulnérabilité est activement exploitée quand des éléments fiables montrent qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation de son propriétaire. Une vulnérabilité seulement grave, ou démontrée par un chercheur, ne suffit pas. Les signaux habituels sont une entrée dans le catalogue des vulnérabilités exploitées de la CISA (KEV) ou dans la base européenne des vulnérabilités (EUVD), un avis d’éditeur indiquant une exploitation en conditions réelles, ou vos propres constats d’incident.

L’horloge démarre quand vous en avez connaissance, y compris quand c’est un composant de votre produit, par exemple une bibliothèque open source, qui est exploité.

Un incident grave

Un incident est grave quand il porte atteinte, ou peut porter atteinte, à la capacité de votre produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes, ou quand il a conduit, ou peut conduire, à introduire ou exécuter du code malveillant dans votre produit ou dans les réseaux de vos utilisateurs. Un serveur de mises à jour compromis en est l’exemple type.

Les trois signalements

Étape	Vulnérabilité activement exploitée	Incident grave
Alerte précoce	Sous 24 heures après en avoir eu connaissance, en indiquant dans quels pays de l’UE le produit est disponible	Sous 24 heures, en indiquant aussi si l’incident est soupçonné d’avoir une origine illicite ou malveillante
Notification	Sous 72 heures : le produit, la nature de l’exploitation et de la vulnérabilité, les mesures correctives ou d’atténuation prises, les mesures que les utilisateurs peuvent prendre, la sensibilité des informations	Sous 72 heures : la nature de l’incident, une première évaluation, les mesures prises et celles que les utilisateurs peuvent prendre, la sensibilité des informations
Rapport final	Au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation : description, gravité et impact, ce que l’on sait de l’acteur malveillant, détails de la mise à jour de sécurité	Dans le mois qui suit la notification : description détaillée, type probable de menace ou cause première, mesures d’atténuation appliquées et en cours

Le CSIRT peut demander un rapport intermédiaire entre les deux. Vous devez aussi informer les utilisateurs concernés, et leur indiquer les mesures qu’ils peuvent prendre, en temps utile ; à défaut, le CSIRT peut le faire.

Qui peut être sanctionné, et l’exception pour les petites entreprises

Manquer à ces obligations peut coûter jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Les micro et petites entreprises ne peuvent pas être sanctionnées pour un retard de l’alerte précoce à 24 heures, mais l’obligation elle-même, la notification à 72 heures et le rapport final s’appliquent toujours. Les intendants de logiciels ouverts signalent aussi, dans la mesure où ils sont concernés, et ne peuvent pas recevoir d’amende.

Comment être prêt avant

Les 24 heures sont courtes parce que les premières heures d’un incident servent à comprendre ce qui est touché. L’essentiel de ce travail peut se faire à l’avance.

1. Savoir ce que contient chaque produit. Une nomenclature logicielle à jour, version par version, permet de répondre à « sommes-nous touchés ? » en quelques minutes au lieu de plusieurs jours. Voir notre guide du SBOM.
2. Surveiller l’exploitation, pas seulement les vulnérabilités. Comparez vos composants chaque jour aux catalogues de vulnérabilités exploitées, pour apprendre une exploitation par vos propres outils et non par un client.
3. S’inscrire sur la plateforme unique de l’ENISA avant d’en avoir besoin, et décider qui, dans votre entreprise, peut signaler.
4. Préparer les signalements. Gardez des modèles des trois étapes avec les données de vos produits déjà remplies : nom, versions, États membres où ils sont vendus, points de contact.
5. Écrire l’avis aux utilisateurs à l’avance. Un texte court, avec des champs à compléter, qui dit aux utilisateurs ce qui est touché et quoi faire.
6. Faire un exercice. Prenez une vraie vulnérabilité exploitée l’an dernier et chronométrez le temps qu’il faut à votre équipe pour remplir l’alerte précoce.

Ce que fait Provetry, et ce qu’il ne fait pas

Avec les offres payantes, Provetry surveille chaque composant de vos produits face à CISA KEV et à la base européenne des vulnérabilités, vous alerte dès que l’un d’eux est signalé comme exploité, décompte les délais à partir du moment où vous indiquez en avoir eu connaissance, et rédige les trois signalements avec les données de votre produit. Avec l’option « Signalements relus », un expert en sécurité certifié lit chaque brouillon avant que vous l’envoyiez. Les alertes n’attendent jamais cette relecture.

Provetry ne transmet rien à l’ENISA à votre place, et ne décide pas pour vous qu’une vulnérabilité est activement exploitée : la loi confie les deux au fabricant.

Ce guide est une information générale, pas un conseil juridique.

Sources

• Règlement (UE) 2024/2847, le Cyber Resilience Act, article 3 (définitions), article 14 (signalements), article 16 (plateforme unique), article 64 (sanctions), article 71 (dates)
• ENISA : plateforme unique de signalement du CRA
• Commission européenne : résumé du texte
• CISA : catalogue des vulnérabilités exploitées (KEV)