Votre première notification sur la plateforme de l'ENISA : le pas à pas du CRA pour les PME

Depuis le 11 septembre 2026, l'obligation de notification de l'article 14 du règlement (UE) 2024/2847, le Cyber Resilience Act, s'applique, et l'ENISA a ouvert le même jour la plateforme par laquelle ces notifications transitent : la Single Reporting Platform, accessible à l'adresse portal.cra-srp.enisa.europa.eu. Le calendrier légal, le contenu des trois échéances et le champ des événements à notifier sont traités dans notre article CRA : la notification en 24 h et 72 h. Le présent guide prend la suite sur un terrain plus concret : à quoi ressemble l'usage réel de la plateforme pour une PME qui n'y a jamais déposé de notification, et ce qu'il faut avoir réglé avant le premier incident plutôt que pendant.

Le périmètre du CRA lui-même, les produits couverts et le calendrier complet sont décrits dans notre guide CRA pour les PME. Ce qui suit suppose qu'un événement de l'article 14 s'est produit, c'est-à-dire une vulnérabilité activement exploitée dans le produit ou un incident grave affectant sa sécurité.

Créer le compte avant d'en avoir besoin

L'accès à la plateforme repose sur un compte EU Login avec authentification multifacteur activée. Les comptes sont personnels : ils sont rattachés à une personne, pas à une boîte fonctionnelle. Pour un fabricant donné, l'ENISA prévoit un compte principal, qui procède à l'enregistrement du fabricant, et jusqu'à vingt comptes secondaires invités par le compte principal. Cette distinction a une conséquence pratique pour une PME : la personne qui détient le compte principal ne doit pas être un point de défaillance unique. Prévoir au moins un compte secondaire actif évite qu'une notification reste bloquée parce que la seule personne enregistrée est indisponible le jour de l'incident.

L'enregistrement demande des informations sur le fabricant et le choix du CSIRT compétent. Il n'y a pas de raison de le faire dans l'urgence : le compte, la double authentification et le rattachement au bon CSIRT se mettent en place hors crise, et se vérifient une fois par une connexion de contrôle.

Choisir le bon CSIRT

La plateforme dépose une notification unique qui est transmise à l'ENISA et au CSIRT désigné coordinateur. Le bon CSIRT est celui de l'État membre où le fabricant a son établissement principal, c'est-à-dire le lieu où les décisions de cybersécurité sont principalement prises. Pour une entreprise établie en France, ce rôle revient au CERT-FR, au sein de l'ANSSI.

Lorsque le fabricant n'a pas d'établissement principal dans l'Union, l'ENISA retient un ordre de rattachement : le lieu du représentant autorisé, puis celui de l'importateur, puis celui du distributeur, puis l'État membre où se trouve la plus forte concentration d'utilisateurs. Une PME qui vend hors de son pays d'origine a intérêt à trancher cette question au moment de l'enregistrement, pas au moment du dépôt, car elle détermine quelle autorité recevra le signalement et le coordonnera ensuite avec les CSIRT des autres pays concernés.

Ce que chaque étape demande sur la plateforme

L'article 14 organise la notification en trois temps, et la plateforme reprend cette structure. L'alerte précoce, due dans les 24 heures suivant la prise de connaissance, appelle un contenu réduit : indiquer si l'exploitation est suspectée ou confirmée, et les États membres concernés le cas échéant. La notification des 72 heures demande les informations générales disponibles et une première évaluation de la vulnérabilité ou de l'incident. Le rapport final intervient au plus tard 14 jours après la mise à disposition d'une mesure corrective pour une vulnérabilité exploitée, et au plus tard un mois après la notification pour un incident grave.

L'ENISA publie un glossaire de la plateforme qui précise, champ par champ, ce qui est attendu à chaque étape, avec les formats et des exemples. Le lire une fois à froid vaut mieux que de le découvrir en remplissant l'alerte des 24 heures. Le contenu exact des trois échéances, du côté du droit, est détaillé dans notre article dédié à la notification en 24 h et 72 h.

Ce que la prise de connaissance déclenche

Le compteur des 24 heures ne part pas de l'incident lui-même, mais de la prise de connaissance par le fabricant. Ni le règlement, ni la page de la Commission sur les obligations de notification ne donnent de définition chiffrée de ce moment, ce qui laisse une marge d'appréciation qu'il vaut mieux réduire à l'avance plutôt que sur le moment.

En pratique, la lecture prudente rattache la prise de connaissance à l'information fiable. Pour une vulnérabilité, l'ENISA qualifie l'exploitation active par l'existence d'une preuve fiable qu'un acteur malveillant l'a exploitée sans autorisation dans un système : c'est cette preuve, et non la simple découverte d'une faille, qui fait courir le délai. Pour un incident, la prise de connaissance correspond au moment où le fabricant sait qu'un incident grave affectant la sécurité du produit s'est produit, un incident grave étant défini comme un événement qui porte atteinte, ou est susceptible de porter atteinte, à la capacité du produit à protéger la disponibilité, l'authenticité, l'intégrité ou la confidentialité. Deux points méritent d'être fixés dans le processus interne : le délai court de façon continue, week-ends compris, et il vaut mieux un critère écrit décidant à partir de quel signal l'entreprise considère qu'elle a pris connaissance, plutôt qu'une décision improvisée le jour venu.

Ce que la plateforme fait, et ne fait pas encore

À son ouverture, la plateforme fonctionne uniquement par son interface web : il n'y a pas d'API dans cette version, les notifications se saisissent à la main. Un fabricant peut automatiser ses flux internes de préparation, mais le dépôt final passe par le navigateur. L'ENISA indique qu'une fonction d'interface applicative pourrait arriver dans une phase ultérieure.

La plateforme est disponible en anglais à son lancement, les supports d'accompagnement étant traduits progressivement, dont une fiche en français. Les signalements volontaires prévus par l'article 15, portant sur des vulnérabilités, des menaces ou des incidents évités, sont annoncés pour une phase ultérieure : au lancement, la plateforme sert les notifications obligatoires de l'article 14. Un mécanisme est prévu pour les circonstances exceptionnelles au titre de l'article 16, paragraphe 2, lorsque le dépôt par la plateforme n'est pas possible.

Rattacher le dépôt à la réponse à incident existante

Déposer dans les temps ne dépend pas de la plateforme mais du processus qui l'alimente. Dans NIST CSF 2.0, la qualification et le traitement d'un incident relèvent de la catégorie RS.MA (gestion des incidents), et les déclarations obligatoires vers les autorités et les utilisateurs de la catégorie RS.CO (communication). Les canaux qui alimentent la détection, dont la divulgation coordonnée des vulnérabilités, et l'articulation avec les autres régimes qui peuvent se déclencher sur le même événement, décrite dans notre article sur la notification sous RGPD, NIS2 et CRA, font partie du même dispositif. Le compte ENISA, le choix du CSIRT et les modèles de notification sont les éléments que l'article 14 ajoute à une réponse à incident déjà structurée.

L'évaluation Komplyo mesure la maturité de la fonction RESPOND, dont les catégories RS.MA et RS.CO, et la feuille de route générée positionne les écarts de gestion d'incident par priorité. Le scénario CRA a sa place dans le registre des risques, avec l'obligation réglementaire documentée en conséquence. Le diagnostic gratuit (23 questions, environ 5 minutes) donne un premier état de cette fonction.