ENISA Single Reporting Platform : préparer les notifications CRA

Par Alex Varabyou · 22 octobre 2026

Sommaire

Les affirmations juridiques ont été vérifiées le 21 octobre 2026 dans le texte du règlement (UE) 2024/2847 publié au Journal officiel. Les informations sur le fonctionnement proviennent des pages publiques de l’ENISA consultées à cette date (FAQ « Mise à jour : 15 octobre 2026 »). L’ENISA fait évoluer la plateforme et ses instructions. Vérifiez-les de nouveau avant de vous y fier. Cette page fournit des informations, pas un conseil juridique. Elle ne détermine pas si un événement doit être notifié.

Les deux premiers délais de notification commencent lorsque le fabricant a connaissance de l’événement. Ouvrir le portail ne déclenche pas ces délais. Cette distinction doit être intégrée à la préparation, avant que quelqu’un ait besoin de transmettre une notification.

Le rôle de la Single Reporting Platform

La Single Reporting Platform, ou SRP, est la plateforme unique de signalement prévue par l’article 16 du règlement sur la cyberrésilience. L’ENISA la met en place et en assure la gestion et la maintenance au quotidien. L’article 16, paragraphe 1, couvre les notifications obligatoires de l’article 14, paragraphes 1 et 3, et les notifications volontaires de l’article 15, paragraphes 1 et 2.

L’objectif déclaré est de « simplifier les obligations de signalement des fabricants » (article 16, paragraphe 1). Les fabricants notifient simultanément le CSIRT désigné comme coordinateur et l’ENISA par la plateforme (article 14, paragraphes 1 et 3). L’architecture permet aux États membres et à l’ENISA de mettre en place leurs propres points finaux de notification électronique. La notification est transmise par le point final du CSIRT compétent désigné comme coordinateur (article 16, paragraphe 1 ; article 14, paragraphe 7).

Le CSIRT qui reçoit la notification en premier la diffuse sans délai par la plateforme aux CSIRT désignés comme coordinateurs des États membres où le fabricant a indiqué avoir mis le produit à disposition (article 16, paragraphe 2). Dans des circonstances exceptionnelles, cette diffusion peut être retardée pour des raisons justifiées liées à la cybersécurité (article 16, paragraphe 2 ; règlement délégué (UE) 2026/881 de la Commission). Dans les circonstances particulièrement exceptionnelles énumérées à l’article 16, paragraphe 2, troisième alinéa, l’ENISA ne reçoit initialement que des informations limitées. Notifier les destinataires désignés ne signifie pas partager les informations sans restriction.

La page publique de l’ENISA explique le service. Pour transmettre une notification, utilisez le portail. Selon l’ENISA, la plateforme est opérationnelle depuis le 11 septembre 2026 et accessible à l’adresse portal.cra-srp.enisa.europa.eu (s’ouvre dans un nouvel onglet) (page SRP de l’ENISA ; FAQ 4 et 28).

Qui l’utilise et pour quels événements ?

L’article 14 impose aux fabricants des obligations de notification. Il couvre une vulnérabilité activement exploitée contenue dans un produit comportant des éléments numériques et un incident grave ayant des répercussions sur la sécurité d’un tel produit. Ce sont des motifs de notification distincts (article 14, paragraphes 1, 3 et 5). L’article 14 s’applique à partir du 11 septembre 2026 (article 71, paragraphe 2).

La découverte d’une vulnérabilité justifie une évaluation de la situation. Elle ne doit pas automatiquement conduire à décider de notifier au titre de l’article 14. Le fabricant doit vérifier si le fait générateur prévu par le droit est établi et consigner les preuves. Une vulnérabilité activement exploitée suppose des preuves fiables qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire du système (article 3, point 42)).

L’article 15 prévoit des notifications volontaires. Les fabricants et d’autres personnes physiques ou morales peuvent notifier à un CSIRT désigné comme coordinateur ou à l’ENISA toute vulnérabilité et les cybermenaces susceptibles d’affecter le profil de risque d’un produit (article 15, paragraphe 1). Ils peuvent aussi notifier tout incident ayant des répercussions sur la sécurité du produit et les incidents évités qui auraient pu entraîner un tel incident (article 15, paragraphe 2). Une notification volontaire et une décision concluant à une obligation de notification doivent rester distinctes.

Selon l’ENISA, la plateforme ne prend pas encore en charge les notifications volontaires de l’article 15. Seules les notifications obligatoires des fabricants au titre de l’article 14 peuvent actuellement être transmises. Les personnes qui ne sont pas des fabricants sont invitées à contacter directement le CSIRT national concerné (FAQ 4, 27 et 30). Les intendants de logiciels ouverts sont soumis aux obligations de notification de l’article 24, paragraphe 3, à partir du 11 décembre 2027 (article 71, paragraphe 2).

L’explication de la plateforme unique de signalement dans le glossaire et le guide de l’article 14 présentent les termes et les délais associés.

Le délai court avant l’ouverture du formulaire

Les deux premiers délais courent à partir du moment où le fabricant a connaissance de l’événement. Créer un compte ou commencer un brouillon ne déclenche pas ces délais. Les deux étapes exigent d’agir sans retard injustifié, dans les limites maximales indiquées (article 14, paragraphe 2, points a) et b), et paragraphe 4, points a) et b)).

Étape	Vulnérabilité activement exploitée	Incident grave ayant des répercussions sur la sécurité du produit
Alerte précoce	Sans retard injustifié et, en tout état de cause, au plus tard 24 heures après en avoir eu connaissance. Indiquer, le cas échéant, les États membres où le produit a été mis à disposition. Article 14, paragraphe 2, point a).	Sans retard injustifié et, en tout état de cause, au plus tard 24 heures après en avoir eu connaissance. Indiquer au moins si des actes illicites ou malveillants sont soupçonnés et, le cas échéant, les États membres où le produit a été mis à disposition. Article 14, paragraphe 4, point a).
Notification de vulnérabilité ou notification d’incident	À moins que les informations pertinentes n’aient déjà été communiquées : au plus tard 72 heures après en avoir eu connaissance. Informations générales disponibles sur le produit, la nature générale de l’exploitation et de la vulnérabilité, les mesures de correction ou d’atténuation prises et celles que les utilisateurs peuvent prendre, et, s’il y a lieu, la sensibilité des informations. Article 14, paragraphe 2, point b).	À moins que les informations pertinentes n’aient déjà été communiquées : au plus tard 72 heures après en avoir eu connaissance. Informations générales disponibles sur la nature de l’incident, première évaluation de l’incident, mesures de correction ou d’atténuation prises et celles que les utilisateurs peuvent prendre, et, s’il y a lieu, sensibilité des informations. Article 14, paragraphe 4, point b).
Rapport final	À moins que les informations pertinentes n’aient déjà été communiquées : au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation. Article 14, paragraphe 2, point c).	À moins que les informations pertinentes n’aient déjà été communiquées : dans un délai d’un mois à compter de la présentation de la notification d’incident. Article 14, paragraphe 4, point c).

Le rapport final sur la vulnérabilité comprend au moins une description de la vulnérabilité, de sa gravité et de ses répercussions ; le cas échéant, des informations sur tout acteur malveillant qui l’a exploitée ou l’exploite ; et des précisions sur la mise à jour de sécurité ou les autres mesures correctives mises à disposition (article 14, paragraphe 2, point c)).

Le rapport final sur l’incident grave comprend au moins une description détaillée de l’incident, de sa gravité et de ses répercussions ; le type de menace ou la cause profonde ayant probablement déclenché l’incident ; et les mesures d’atténuation appliquées et en cours (article 14, paragraphe 4, point c)). Utilisez la liste de contrôle correspondant à l’événement que vous notifiez. La liste du rapport final sur une vulnérabilité ne remplace pas celle d’un incident grave.

Si nécessaire, le CSIRT qui a reçu la notification en premier peut demander un rapport intermédiaire sur les évolutions pertinentes de la situation (article 14, paragraphe 6). Selon l’ENISA, tout représentant affecté au même fabricant peut actualiser une notification aux étapes suivantes (FAQ 9). Continuez à tenir le dossier pendant ces étapes. Transmettre le premier formulaire n’est qu’une partie du travail.

Quel CSIRT reçoit la notification ?

Le destinataire est le CSIRT désigné comme coordinateur, un CSIRT désigné au titre de l’article 12, paragraphe 1, de la directive (UE) 2022/2555 (article 3, point 51)). Le nom familier d’une équipe de réponse ou sa proximité avec le client touché ne suffit pas pour choisir le destinataire. L’ENISA publie une liste des CSIRT désignés comme coordinateurs. Selon l’ENISA, si le mauvais CSIRT est sélectionné, la notification peut être invalidée et doit être transmise de nouveau au bon destinataire (FAQ 18).

Un fabricant dont l’établissement principal se trouve dans l’Union notifie le CSIRT désigné comme coordinateur de cet État membre. L’établissement principal est situé dans l’État membre où sont prises l’essentiel des décisions relatives à la cybersécurité de ses produits. Si cet État ne peut pas être déterminé, il s’agit de celui où le fabricant possède l’établissement comptant le plus grand nombre de salariés dans l’Union (article 14, paragraphe 7). Le siège statutaire ne suffit pas, à lui seul, à trancher la question.

Un fabricant sans établissement principal dans l’Union applique l’ordre suivant, sur la base des informations dont il dispose (article 14, paragraphe 7) :

l’État membre où est établi le mandataire agissant pour le plus grand nombre de ses produits ;
l’État membre où est établi l’importateur qui met sur le marché le plus grand nombre de ses produits ;
l’État membre où est établi le distributeur qui met à disposition sur le marché le plus grand nombre de ses produits ;
l’État membre où se trouve le plus grand nombre d’utilisateurs de ses produits.

Si le point 4 a été utilisé, le fabricant peut adresser ses notifications ultérieures au même CSIRT que celui de sa première notification (article 14, paragraphe 7). Suivez cet ordre plutôt que de choisir le destinataire le plus pratique.

Avant tout événement, préparez une courte note sur le choix du destinataire. Elle doit identifier le fabricant au sens juridique, l’établissement concerné ou l’opérateur retenu à défaut, et les faits justifiant ce choix. Consignez la disposition appliquée et faites vérifier la note par le responsable juridique ou sécurité compétent.

Qui peut transmettre et qui peut voir un brouillon ?

Ces précisions sur les accès proviennent de l’ENISA (FAQ 9, 15, 24 et 28, consultées le 21 octobre 2026). Elles décrivent le processus publié. Elles ne reposent pas sur un test de la plateforme.

Les notifications sont transmises par les représentants affectés au fabricant (Assigned Representatives, AR). Chaque AR doit disposer d’un compte personnel EU Login avec authentification multifacteur.
Chaque fabricant a un AR principal (Primary AR) et jusqu’à 20 AR secondaires (Secondary ARs), invités par l’AR principal. Le CSIRT désigné comme coordinateur valide le rattachement de l’AR au fabricant. Des notifications peuvent être transmises dans l’attente de cette validation, dans la limite de 20 par fabricant.
Les brouillons sont enregistrés dans le compte individuel de l’AR et ne sont pas visibles par les autres AR.
La première version ne propose pas d’API. Les notifications sont saisies dans l’interface de la plateforme. La plateforme est disponible uniquement en anglais.

Le 20 octobre 2026, l’ENISA a annoncé la version 1.2.1 de la plateforme, avec un processus modifié pour inviter les AR secondaires, et a indiqué que sa documentation était en cours de mise à jour. Vérifiez aussi la date des instructions que vous utilisez.

Que préparer en interne

Commencez par un dossier de l’événement. La découverte, le moment où le fabricant a connaissance de l’événement et la transmission doivent avoir des champs distincts, avec leurs dates, heures et preuves à l’appui. Désignez un responsable et un suppléant. Conservez la décision de notifier et ses motifs avec les constats techniques.

Rassemblez les éléments d’identification du produit et les composants touchés, puis les preuves d’exploitation et les répercussions connues. Séparez les faits confirmés des constats provisoires et des inconnues. Notez les mesures de confinement immédiates. Tenez une liste distincte des mesures de correction et d’atténuation, avec la date à laquelle chacune est devenue disponible.

Il s’agit de conseils de préparation. Pour les champs réels de la plateforme, utilisez le SRP Glossary de l’ENISA. Il décrit les champs de chaque type et étape de notification, ainsi que les champs obligatoires (FAQ 11 et 16). Consultez-le avant de vous fier à un processus précis.

Préparez la communication aux utilisateurs en parallèle de la notification. La transmission à la plateforme ne remplace pas l’obligation du fabricant d’informer les utilisateurs touchés et, s’il y a lieu, tous les utilisateurs de la vulnérabilité ou de l’incident et, si nécessaire, des mesures qu’ils peuvent appliquer (article 14, paragraphe 8).

Où trouver les instructions à jour de l’ENISA

Commencez par la page Single Reporting Platform de l’ENISA (s’ouvre dans un nouvel onglet). Elle donne accès au portail, à la fiche d’information, aux conditions d’utilisation, au manuel des AR, aux pages d’instructions et à la liste des CSIRT désignés comme coordinateurs.

Consultez ensuite la FAQ Single Reporting Platform de l’ENISA (s’ouvre dans un nouvel onglet) et le SRP Glossary (s’ouvre dans un nouvel onglet).

Si la plateforme est temporairement indisponible, l’ENISA demande d’attendre puis de transmettre la notification dès son rétablissement. Un fabricant qui estime nécessaire de communiquer immédiatement peut contacter directement son CSIRT, mais doit tout de même transmettre ensuite sa notification par la plateforme (FAQ 25).

Tenez votre propre chronologie. Un compteur affiché ou un brouillon enregistré ne prouve pas que les délais prévus à l’article 14 ont été respectés. Selon l’ENISA, le compteur actuel de 72 heures indique une échéance 48 heures après la transmission de l’alerte précoce, et non 72 heures après le moment où le fabricant a eu connaissance de l’événement. Aucun compteur n’est prévu pour le rapport final sur une vulnérabilité (FAQ 26). Les compteurs ne remplacent pas les délais prévus à l’article 14.

Sources

Règlement (UE) 2024/2847 (s’ouvre dans un nouvel onglet), texte du Journal officiel (Office des publications) : article 3, points 42) et 51) ; article 14, paragraphes 1 à 8 ; article 15, paragraphes 1 et 2 ; article 16, paragraphes 1 et 2 ; article 24, paragraphe 3 ; article 71, paragraphe 2.
Rectificatif JO L 2025/90555 (s’ouvre dans un nouvel onglet) du 2 juillet 2025 : dans la version française, il rectifie l’article 64, paragraphe 10, et l’article 69, paragraphe 3. Il ne modifie pas les articles 3, 14, 15 ou 16, pas plus que les autres rectificatifs de la version française (JO L 2025/90768, JO L 2025/90828, JO L 2026/90243).
Règlement délégué (UE) 2026/881 de la Commission (s’ouvre dans un nouvel onglet) relatif au report de la diffusion des notifications (adopté au titre de l’article 14, paragraphe 9).
Commission européenne : règlement sur la cyberrésilience, obligations de notification (s’ouvre dans un nouvel onglet) (consulté le 21 octobre 2026).
ENISA : Single Reporting Platform (s’ouvre dans un nouvel onglet) (consulté le 21 octobre 2026).
ENISA : FAQ Single Reporting Platform (s’ouvre dans un nouvel onglet), « Mise à jour : 15 octobre 2026 » : FAQ 4, 9, 11, 15, 16, 18, 24 à 28, 30.

Pour une aide distincte sur les délais, utilisez le calculateur de délais de notification crAcken.