CRA : préparer les notifications de vulnérabilités et incidents avant le 11 septembre

Le 11 septembre 2026, une partie très concrète du Cyber Resilience Act (CRA) devient applicable : les fabricants devront notifier les vulnérabilités activement exploitées et les incidents sévères ayant un impact sur la sécurité de leurs produits avec éléments numériques.15

L’échéance ne signifie pas que toutes les obligations du CRA s’appliquent déjà. Les principales obligations du règlement entreront en application le 11 décembre 2027. Mais le dispositif de notification, lui, démarre dès septembre 2026.2

Pour un fabricant, la difficulté opérationnelle n’est donc plus seulement de connaître le texte. Elle est de répondre à une question beaucoup plus concrète : si une vulnérabilité est exploitée demain matin, savons-nous identifier le produit concerné, les versions affectées, l’état du correctif et les faits nécessaires à une première notification en moins de 24 heures ?

Trois échéances, mais une seule chronologie à maîtriser

Pour une vulnérabilité activement exploitée comme pour un incident sévère, le processus commence lorsque le fabricant en a connaissance.13

Une première alerte doit être transmise sans retard injustifié et, dans tous les cas, dans les 24 heures. Une notification plus complète doit suivre dans les 72 heures. Le rapport final intervient ensuite selon un calendrier différent : au plus tard quatorze jours après qu’une mesure corrective est disponible pour une vulnérabilité activement exploitée, et dans le mois suivant la notification pour un incident sévère.13

Étape	Délai maximal	Question interne à résoudre
Prise de connaissance	T0	Que savons-nous réellement et qui qualifie l’événement ?
Alerte précoce	24 h	Quel produit est concerné et quelle est la nature de l’événement ?
Notification	72 h	Quel périmètre, quelles versions, quel impact et quelle première évaluation ?
Rapport final — vulnérabilité	≤ 14 jours après disponibilité d’une mesure corrective	Quelle analyse et quelle remédiation consolidées ?
Rapport final — incident sévère	≤ 1 mois après la notification	Quelle cause, quelles conséquences et quelles mesures définitives ?

Cette progressivité est importante : le CRA n’exige pas que l’entreprise connaisse toute l’histoire dans les premières heures. Il exige en revanche qu’elle sache identifier ce qu’elle sait, quand elle l’a su et à quel produit cette information se rattache.

Une CVE n’est pas encore un dossier CRA

Une vulnérabilité activement exploitée est une vulnérabilité pour laquelle il existe des éléments fiables montrant qu’un acteur malveillant l’a exploitée sans l’autorisation du propriétaire du système.35

Cette définition crée une distinction opérationnelle importante. Une vulnérabilité connue, même critique, n’entre pas automatiquement dans cette catégorie du seul fait de sa sévérité. Le déclencheur réglementaire dépend ici de l’existence d’éléments fiables d’exploitation active.

Inversement, recevoir un identifiant CVE ou une alerte de sécurité ne suffit pas à constituer le dossier. Il faut encore pouvoir déterminer quels produits sont concernés, quelles versions embarquent le composant vulnérable, quelles versions sont maintenues, quelles mesures existent et quel est l’état de l’analyse.

C’est à cet endroit que la gestion des vulnérabilités rencontre la gestion du cycle de vie produit.

Le vrai objet à suivre est le produit dans une version donnée

Une organisation peut disposer d’un inventaire de vulnérabilités très correct et rester lente face au CRA si cet inventaire n’est pas relié au référentiel produit.

Cybercoria propose de raisonner autour d’un dossier interne minimal de ce type :

cra_case:
  id: CRA-...
  event_type: actively_exploited_vulnerability | severe_incident
  aware_at: ...
  evidence_refs: [...]
  products:
    - product_id: ...
      version_range: ...
      support_status: ...
      markets: [...]
  vulnerability:
    identifier: ...
    component: ...
    exploitation_evidence: ...
  incident:
    security_properties_affected: [...]
    impact: ...
  corrective_measure:
    status: ...
    available_at: ...
    affected_versions: [...]
  reporting:
    coordinator_csirt: ...
    early_warning_at: ...
    notification_72h_at: ...
    final_report_due_at: ...
  evidence_refs: [...]

Cette structure est une proposition éditoriale Cybercoria, pas un modèle imposé par le règlement. Elle met en évidence les jointures qui risquent de coûter du temps : événement → vulnérabilité → composant → produit → version → support → correctif → notification.

Une nomenclature produit ambiguë devient ici un problème de conformité. Si l’équipe sécurité parle d’un composant par son nom technique, le support d’un produit par son nom commercial et l’équipe de développement par le nom du dépôt, la première difficulté sera simplement de démontrer qu’ils parlent du même périmètre.

La Single Reporting Platform ne remplacera pas le travail de préparation

ENISA met en place une Single Reporting Platform (SRP) destinée à servir de point d’entrée unique pour les notifications CRA. Elle doit être opérationnelle au 11 septembre 2026.13

Le fabricant soumettra sa notification électroniquement en sélectionnant le CSIRT désigné comme coordinateur, déterminé à partir de son établissement principal. La plateforme organise ensuite le routage prévu par le dispositif européen.3

ENISA a déjà publié des guides d’utilisation. Le processus prévoit notamment une alerte précoce, puis la notification à 72 heures et enfin le rapport final. Une notification peut être enregistrée comme brouillon ou mise à jour tant qu’elle n’est pas clôturée et que le rapport final n’a pas été soumis.4

Cette interface résout le problème de transmission. Elle ne résout pas le problème de collecte interne. Si l’entreprise découvre au moment de remplir le dossier qu’elle ne sait pas précisément quelles versions sont affectées, quel composant est embarqué ou qui peut valider l’information, le portail ne raccourcira pas cette enquête.

Cas construit : une bibliothèque compromise dans trois versions d’un produit

Prenons un éditeur fictif qui commercialise une application installable chez ses clients. Trois branches existent encore sur le terrain : 4.8, 5.2 et 6.0. Seules les versions 5.2 et 6.0 sont encore dans leur période de support.

À 09 h 15, l’équipe sécurité reçoit des éléments fiables indiquant qu’une vulnérabilité affectant une bibliothèque embarquée est activement exploitée. À 09 h 40, elle confirme que la bibliothèque est présente dans les trois branches. À 11 h 10, l’équipe produit établit précisément les versions affectées et les statuts de support. Un correctif pour 6.0 est prêt le lendemain ; celui de 5.2 demande davantage de travail.

Le dossier ne peut pas être piloté uniquement depuis le ticket de vulnérabilité. Il faut relier au moins quatre référentiels : composants logiciels, versions produit, politique de support et chaîne de publication des correctifs.

Dans une organisation préparée, ces relations permettent de répondre rapidement à des questions simples : où le composant est-il utilisé ? quelles versions sont affectées ? lesquelles sont encore supportées ? qui décide de la mesure corrective ? à quelle date celle-ci devient-elle disponible ?

Dans une organisation moins structurée, ces mêmes questions déclenchent des recherches dans les dépôts, des échanges avec plusieurs équipes et parfois une reconstruction de l’historique des versions.

Le cas est volontairement simplifié. La qualification juridique précise d’un événement, le contenu attendu de chaque notification et les obligations applicables dépendent de la situation réelle et doivent être appréciés au regard du règlement et des orientations officielles.

La période de support devient une donnée de cybersécurité

Les orientations publiées par la Commission le 27 juillet 2026 apportent des précisions pratiques sur plusieurs notions du CRA, dont les périodes de support, les modifications substantielles, l’évaluation des risques et les obligations de reporting.2

Pour l’architecture de l’information, cela renforce une idée simple : le catalogue produit ne peut pas s’arrêter au nom et à la version. Il doit permettre de retrouver le statut de support, les composants pertinents et les décisions de maintenance associées.

Cette information sert plusieurs usages : qualifier le périmètre d’une vulnérabilité, organiser la remédiation, informer les équipes concernées et documenter le traitement dans la durée. Le CRA transforme ainsi une donnée parfois gérée comme une information commerciale ou de support en donnée utile au pilotage de la cybersécurité produit.

Ce qu’il faut tester avant le 11 septembre

Il reste peu de temps avant l’entrée en application des obligations de notification. Un exercice utile ne consiste pas nécessairement à simuler une crise complète.

Choisir un produit réel et une vulnérabilité fictive dans l’un de ses composants. Déclencher un chronomètre. Demander ensuite aux équipes de retrouver : les versions concernées ; leur statut de support ; le responsable produit ; les éléments permettant d’établir l’exploitation ; le statut du correctif ; le CSIRT coordinateur ; et les personnes habilitées à préparer la notification.

Mesurer surtout le temps passé à chercher l’information plutôt que le temps passé à la saisir.

ENISA précise que les représentants utiliseront un compte EU Login pour accéder à la plateforme et que la validation de leur capacité à agir pour un fabricant sera effectuée par le CSIRT coordinateur. Les modalités peuvent varier selon les CSIRT et ENISA recommande de consulter les guides à jour.3

Ce point mérite donc lui aussi d’être intégré à l’exercice : savoir qui peut agir, et non seulement qui possède l’information.

Le 11 septembre ne transforme pas instantanément toute l’organisation de sécurité produit. Il crée en revanche une contrainte mesurable : passer d’un signal de vulnérabilité ou d’incident à un dossier produit traçable dans un délai réglementaire court. Pour beaucoup d’organisations, le meilleur test de préparation est désormais de vérifier si cette chaîne peut être parcourue sans reconstruire le contexte à chaque étape.