Cyber Resilience Act : comment tenir les délais de notification de 24 h et 72 h ?
Dev Together · Expertise cybersécurité
Depuis le 11 septembre 2026, les fabricants concernés par le Cyber Resilience Act doivent signaler les vulnérabilités activement exploitées et les incidents graves affectant la sécurité de leurs produits comportant des éléments numériques. La première alerte doit partir sous 24 heures, avant même que l’enquête soit terminée. Pour respecter ce délai sans envoyer une information imprécise, il faut préparer les responsabilités, les preuves et le circuit de décision en amont.
Ce qui change depuis le 11 septembre 2026
L’ANSSI présente le cadre réglementaire du CRA comme une réglementation européenne applicable aux produits comportant des éléments numériques mis sur le marché de l’Union. La plupart des exigences de sécurité produit s’appliqueront à partir du 11 décembre 2027, mais les obligations de notification de l’article 14 sont déjà entrées en application.
La FAQ officielle de l’ANSSI rappelle les deux premières échéances : une alerte précoce dans les 24 heures, puis une notification complétée dans les 72 heures suivant la prise de connaissance. Ces obligations concernent deux situations distinctes : une vulnérabilité dont l’exploitation active est connue et un incident grave ayant un impact sur la sécurité du produit.
Qui doit préparer ce dispositif ?
Le CRA vise les fabricants de produits avec des éléments numériques proposés sur le marché européen. Selon le contexte, un éditeur de logiciel, un fabricant d’objet connecté ou une entreprise qui commercialise une solution sous son nom peut donc être concerné. La qualification exacte dépend du produit, du rôle de l’organisation et des exclusions prévues par le règlement : elle doit être validée avec les équipes juridiques ou conformité plutôt que déduite d’une simple étiquette « SaaS » ou « open source ».
La FAQ de la plateforme européenne de signalement précise que les obligations de l’article 14 peuvent aussi couvrir des produits mis sur le marché avant le 11 décembre 2027 lorsqu’ils entrent dans le périmètre du CRA. Elle indique en revanche qu’une exploitation active déjà connue du fabricant avant le 11 septembre 2026 n’a pas à être déclarée rétroactivement au seul titre de cette entrée en application.
La chronologie à intégrer dans la réponse à incident
Le texte du règlement européen 2024/2847 fixe une séquence progressive. Pour une vulnérabilité activement exploitée, l’alerte précoce intervient au plus tard sous 24 heures, la notification détaillée sous 72 heures et le rapport final au plus tard 14 jours après la disponibilité d’une mesure corrective ou d’atténuation. Pour un incident grave, les deux premiers délais sont identiques et le rapport final doit être transmis dans le mois suivant la notification initiale.
Ces délais commencent à la prise de connaissance, pas à la fin de l’analyse technique. Le premier signalement doit donc pouvoir distinguer clairement les faits confirmés, l’évaluation en cours et les informations encore inconnues. Une organisation qui attend une cause racine certaine avant d’alerter risque de dépasser l’échéance.
Une déclaration unique via la plateforme de l’ENISA
L’ENISA opère la Single Reporting Platform (SRP), ouverte depuis le 11 septembre 2026. Le fabricant y choisit le CSIRT coordinateur correspondant en principe à son principal établissement. La plateforme transmet ensuite l’information à l’ENISA et aux autorités concernées. Les comptes, représentants autorisés et moyens d’accès doivent être préparés avant un incident ; les découvrir pendant les premières 24 heures crée un risque de retard évitable.
Plan d’action concret pour tenir 24 heures
Commencez par inventorier les produits potentiellement concernés, leurs versions maintenues, leurs dépendances, leurs responsables et les pays où ils sont proposés. Associez à chaque produit un propriétaire métier, un référent sécurité et un suppléant habilité à déclencher le signalement. Formalisez ensuite une grille qui qualifie une exploitation active ou un incident grave, sans confondre une vulnérabilité théorique avec une attaque observée.
Le processus de sécurité doit préserver les journaux, horodater la prise de connaissance et relier chaque alerte au produit, à ses versions et à ses composants. Les équipes produit, support, exploitation, sécurité, juridique et communication doivent partager un canal d’escalade et un modèle de notification déjà validé. Un exercice sur table permet de vérifier qu’un incident détecté un soir ou un week-end peut réellement être qualifié et déclaré dans le délai.
Cette préparation rejoint une démarche d’architecture logicielle maîtrisée : inventaire des dépendances, versions traçables, chaîne de mise à jour fiable et périmètres de responsabilité explicites. Sans cette cartographie, déterminer rapidement quels clients et quels produits sont concernés devient incertain.
Automatiser la collecte, conserver la décision humaine
La surveillance des vulnérabilités, la correspondance avec une nomenclature de composants, l’ouverture d’un dossier d’incident et la préparation des champs connus peuvent être automatisées. Cette automatisation réduit le temps perdu à consolider des données dispersées. La qualification réglementaire, le niveau de sensibilité des informations et la décision de notifier doivent cependant rester sous le contrôle de personnes habilitées.
Un dispositif de suivi cybersécurité utile relie ainsi veille, inventaire, détection, réponse, correctif et preuve de clôture. Les tests d’intrusion et les contrôles automatisés peuvent identifier des faiblesses ; ils ne remplacent ni la supervision en production ni le processus de notification lorsqu’une exploitation active ou un incident grave est découvert.
La checklist à valider maintenant
Vérifiez le périmètre des produits, le responsable de chaque déclaration, l’accès effectif à la SRP, le point de départ documenté des délais, les modèles 24 heures et 72 heures, la conservation des preuves, la capacité à identifier les versions affectées, le circuit de publication d’un correctif et l’information des utilisateurs. Enfin, testez le dispositif avec un scénario réaliste et consignez les écarts dans une feuille de route priorisée.
Le CRA transforme la sécurité produit en capacité opérationnelle
L’entrée en application des notifications CRA ne se résume pas à un formulaire. Tenir 24 heures suppose de savoir quels produits sont concernés, qui décide, quelles preuves sont disponibles et comment une mesure corrective sera distribuée. Les organisations qui construisent cette chaîne maintenant gagnent à la fois en conformité, en vitesse de réponse et en fiabilité produit.