Reporting ENISA : simulation d'une notification de vulnérabilité sous 24h
Le Cyber Resilience Act impose de notifier l'ENISA sous 24h en cas d'exploitation active. Découvrez notre simulation pas à pas pour maîtriser cette urgence.
Dès le 11 septembre 2026, les fabricants de produits numériques devront se conformer à l'une des exigences les plus strictes du Cyber Resilience Act (CRA) : l'obligation de notification précoce sous 24 heures à l'ENISA et aux CSIRT nationaux en cas de vulnérabilité activement exploitée ou d'incident de sécurité majeur.
Le compte à rebours des 24 heures : une exigence du CRA
L'article 14 du règlement européen 2024/2847 instaure une procédure rigoureuse. Le délai de 24 heures ne débute pas à la découverte de la vulnérabilité dans le code, mais dès la confirmation qu'elle fait l'objet d'une exploitation active. Face à cette contrainte, improviser une réponse en pleine crise expose l'entreprise à des sanctions pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.
Simulation chronologique : du constat au premier rapport
T0 à T+4h : Détection et qualification technique
Votre équipe reçoit une alerte ou détecte une anomalie en production. Deux points doivent être validés immédiatement : le composant affecté appartient-il à votre produit distribué, et l'exploitation est-elle avérée ? Si une exploitation réelle est confirmée sans correctif disponible, l'obligation légale de notification est déclenchée.
T+4h à T+12h : Cartographie de l'impact et collecte
L'objectif n'est pas encore de déployer un correctif, mais d'isoler le périmètre. Vous devez identifier les versions logicielles concernées, consulter votre SBOM (Software Bill of Materials) pour vérifier les dépendances tierces, et évaluer si des mesures de contournement (workarounds) peuvent être communiquées aux utilisateurs.
T+12h à T+24h : Rédaction et transmission de l'alerte
Avant la fin des 24 heures, l'alerte précoce (early warning) doit être transmise via la plateforme unique de l'ENISA, notifiant simultanément le CSIRT national compétent (ex: l'ANSSI en France). Cette notification préliminaire informe les autorités de la menace sans exiger une analyse forensique exhaustive.
Contenu obligatoire de l'alerte des 24 heures
Pour éviter toute rétention d'information, le règlement impose des éléments minimaux dès cette première étape :
- Identification précise du fabricant, du produit et des versions logicielles impactées.
- Nature de la vulnérabilité (ex: injection, dépassement de tampon, contournement d'authentification).
- Preuves tangibles qu'une exploitation malveillante est en cours.
- Premières mesures correctives envisagées ou consignes de mitigation immédiates.
Les erreurs classiques qui font dépasser le délai légal
L'erreur fatale consiste à attendre la disponibilité d'un patch définitif pour notifier les autorités. Le cadre européen distingue clairement l'alerte précoce (24h), la notification détaillée (72h) et le rapport final (sous un mois). Attendre le correctif constitue une infraction formelle au calendrier du CRA.
Le second écueil est organisationnel : l'absence de cartographie à jour des composants tiers. Si vos équipes perdent un temps précieux à identifier manuellement le paquet vulnérable, vous ne serez pas en mesure de respecter les délais de déclaration officiels.
Anticipez vos flux de reporting avec CRAcheck
Le reporting ENISA deviendra obligatoire dès septembre 2026. Pour éviter la panique lors d'une crise, il est impératif d'industrialiser votre documentation technique dès maintenant.
En connectant votre dépôt GitHub à CRAcheck, vous maintenez un SBOM automatisé et accédez à des modèles de reporting ENISA pré-remplis. CRAcheck vous aide à identifier instantanément les dépendances vulnérables et à structurer les informations requises pour respecter le délai légal des 24 heures sans surcharger vos équipes.