Comment déposer une notification CRA sur la plateforme unique de l'ENISA, d'après son propre manuel

L'article 14(7) du Cyber Resilience Act, règlement (UE) 2024/2847, dispose que les notifications d'un fabricant concernant une vulnérabilité activement exploitée ou un incident grave « sont soumises via la plateforme unique de notification visée à l'article 16 ». Pas par courriel à un CSIRT, pas par un portail national : via la plateforme. L'ENISA l'a ouverte le 11 septembre 2026, le jour où l'obligation a commencé, à l'adresse portal.cra-srp.enisa.europa.eu, et a publié à côté un manuel d'utilisation, un glossaire de chaque champ, une série de pages de guidance et 31 réponses aux questions fréquentes.

Cet article est la lecture de ces documents de bout en bout, pour un fabricant qui n'a jamais vu la plateforme et la rencontrera à la première heure d'un incident. Tout ce qui suit vient des pages de l'ENISA telles qu'elles étaient le 12 septembre 2026, ou du règlement. Là où la plateforme fait quelque chose que le règlement ne prévoit pas, c'est dit.

Ce qu'est la plateforme, et ce qu'elle n'est pas encore

La plateforme de l'ENISA est celle que l'article 16(1) lui a demandé de construire : « une plateforme unique de notification est mise en place par l'ENISA. Les opérations quotidiennes de cette plateforme unique de notification sont gérées et maintenues par l'ENISA. » Son objet est que vous déposiez une seule fois. La notification est mise à la disposition de l'ENISA et du CSIRT désigné comme coordinateur que vous avez sélectionné, et ce CSIRT la diffuse ensuite aux coordinateurs des autres États membres où vous avez indiqué que le produit est disponible, et à son autorité de surveillance du marché. La diffusion est leur travail, pas le vôtre.

Quatre limites au lancement, chacune énoncée dans la FAQ de l'ENISA :

• Elle ne prend que les notifications obligatoires de l'article 14. La notification volontaire au titre de l'article 15, par les fabricants ou toute autre personne, n'est pas disponible au lancement. Les obligations des gestionnaires de logiciels libres au titre de l'article 24(3) s'appliquent à partir du 11 décembre 2027, et la plateforme les prendra alors.
• Elle est en anglais seulement. D'autres langues seront examinées dans une phase ultérieure ; la fiche d'information est en cours de traduction, la plateforme non.
• Il n'y a pas d'API. Selon les termes de l'ENISA, aucune interface de programmation n'est fournie dans la version initiale, de sorte que les notifications doivent être soumises via l'interface de la plateforme. Un fabricant qui a de nombreux produits soumet chacun à la main.
• Une notification par vulnérabilité ou incident, pour tout le groupe. Quel que soit le nombre de filiales d'un fabricant dans l'UE et où que se trouve sa maison mère, la FAQ dit qu'une seule notification est requise et que se coordonner en interne pour qu'exactement une soit déposée relève de la responsabilité du fabricant.

Qui se connecte : les représentants désignés

La plateforme ne connaît pas les entreprises. Elle connaît des personnes, appelées représentants désignés, qui agissent pour un fabricant. Chacune a besoin d'un compte EU Login personnel avec l'authentification multifacteur activée ; la FAQ dit que le compte peut être créé à l'avance, qu'aucun mécanisme d'authentification d'entreprise n'est utilisé, et que, les comptes EU Login étant personnels, la personne qui notifie utilise le sien.

Il y a deux rôles. Le Primary AR s'inscrit directement : il ouvre la plateforme, sélectionne le rôle, sélectionne le CSIRT désigné comme coordinateur dans un menu déroulant, s'authentifie via EU Login, accepte l'accord juridique, confirme le nom et le courriel fournis par EU Login, et saisit le nom du fabricant. Cela crée le fabricant dans la plateforme et soumet l'association entre la personne et le fabricant au coordinateur pour validation. Il y a un Primary AR par fabricant. Un Secondary AR rejoint sur invitation par courriel d'un Primary AR dont l'association a déjà été validée et apparaît comme Verified ; le lien d'invitation expire après 7 jours. Il peut y avoir jusqu'à 20 Secondary AR par fabricant. Un Secondary AR peut soumettre et mettre à jour des notifications, mais ne voit que celles qu'il a lui-même soumises ; le Primary AR voit tout ce qui est déposé pour le fabricant, gère l'association et invite ou retire les autres. Un Secondary AR peut revendiquer le rôle de Primary, sous réserve de l'approbation du coordinateur.

Deux choses sur la validation comptent à la première heure. D'abord, elle ne vous bloque pas : le coordinateur valide l'association après l'inscription et en parallèle de la notification, et un représentant non vérifié peut soumettre jusqu'à 20 notifications avant que la vérification ne devienne obligatoire. Ensuite, l'ENISA vous demande de ne pas le faire trop tôt. Sa guidance indique qu'il est conseillé aux fabricants « de s'inscrire et de lancer le processus de validation uniquement lorsqu'ils doivent soumettre une notification précise, plutôt que de s'inscrire par anticipation », pour limiter la charge de validation des coordinateurs, et ajoute qu'avec un EU Login déjà en place l'inscription prend quelques minutes. La préparation, c'est donc l'EU Login avec MFA, pour la personne qui notifie et un suppléant ; l'inscription est une tâche du jour même.

Les conditions d'utilisation, version 1.0 du 10 septembre 2026, ajoutent la partie que votre service juridique voudra voir : en s'inscrivant ou en soumettant, les utilisateurs « déclarent et garantissent qu'ils sont le ou les représentants désignés de leur organisation et sont autorisés à agir en son nom », et le coordinateur peut le vérifier. Mettez l'autorisation par écrit avant le jour où elle sera nécessaire.

Quel coordinateur choisir

Le menu déroulant à l'inscription, et le champ de chaque notification, c'est le CSIRT désigné comme coordinateur de l'État membre où le fabricant a son établissement principal dans l'Union, que l'article 14(7) définit comme l'État « dans lequel les décisions liées à la cybersécurité de ses produits comportant des éléments numériques sont principalement prises », ou, si cela ne peut être déterminé, l'État où il compte le plus de salariés ; et, à défaut d'établissement principal dans l'Union, l'État du mandataire, puis celui de l'importateur, du distributeur, et l'État comptant le plus d'utilisateurs. La FAQ de l'ENISA reprend toute la cascade et ajoute une conséquence que le règlement n'énonce pas : « si le mauvais CDaC est sélectionné, la notification peut être invalidée et devra être soumise à nouveau au bon CDaC ». Une alerte rouge sur le tableau de bord est la façon dont vous l'apprenez.

L'ENISA a publié la liste des coordinateurs le 10 septembre 2026, et dans deux États ce n'est pas le CSIRT national. La liste, et les deux exceptions, font l'objet d'un article distinct ; le tableau figure aussi sur la page des délais de notification.

Les trois soumissions, et ce que chacune demande

L'article 14 exige trois soumissions : une alerte précoce dans les 24 heures suivant la prise de connaissance, une notification dans les 72 heures, et un rapport final. Sur la plateforme, ce sont trois onglets d'un même dossier de notification. Vous ouvrez une nouvelle notification pour l'alerte précoce, puis revenez au même dossier pour la notification de 72 heures et encore pour le rapport final ; chaque étape ultérieure est pré-remplie avec ce que vous avez saisi auparavant, et le glossaire marque chaque champ comme requis, optionnel ou repris de l'étape précédente. Le tableau ci-dessous est la colonne des exigences du glossaire, par étape. Les champs qui ne s'appliquent qu'à un seul type sont marqués AEV pour une vulnérabilité activement exploitée et SI pour un incident grave.

C'est la structure même du règlement, avec les limites des champs tracées dessus. L'article 14(2)(a) demande à l'alerte précoce d'indiquer « le cas échéant, les États membres sur le territoire desquels le fabricant sait que leur produit comportant des éléments numériques a été mis à disposition » ; c'est le champ des États membres, requis dès la première minute. L'article 14(2)(b) demande à la notification de 72 heures des informations générales sur le produit, la nature générale de l'exploit et de la vulnérabilité, les mesures correctives ou d'atténuation prises et celles que les utilisateurs peuvent prendre, et la sensibilité que le fabricant attribue à l'information ; ce sont les champs qui passent d'optionnels à requis à la deuxième étape. L'article 14(2)(c) demande au rapport final la gravité et l'impact, l'acteur lorsqu'il est connu, et la mise à jour de sécurité ou la mesure corrective ; la troisième colonne.

Deux contraintes pratiques tirées du glossaire : un titre tient en 255 caractères et un résumé en 4 000, et chaque horodatage est saisi en UTC. Le glossaire demande aussi de ne pas mettre de détail technique confidentiel dans le titre, et de préciser dans la description si l'heure de prise de connaissance est une estimation. Une note de bas de page vaut d'être connue avant de chercher un champ qui n'existe pas : pour une vulnérabilité, le glossaire marque la date de prise de connaissance comme requise, puis indique que le champ « sera disponible dans la prochaine version de la plateforme » ; pour un incident, il existe aujourd'hui sous le nom « date et heure à laquelle l'incident a été détecté ».

Le compteur que la plateforme calcule mal, de son propre aveu

Le tableau de bord affiche des compteurs pour la notification de 72 heures et le rapport final, avec des courriels de rappel et des alertes de retard pilotés par eux. La FAQ 26 explique comment ils sont calculés, et cela vaut deux lectures. Le compteur de 72 heures « affiche une échéance 48 heures après la soumission de l'alerte précoce de 24 heures », et non 72 heures après la prise de connaissance. Si vous avez déposé l'alerte précoce à la quatrième heure, la plateforme affichera la notification comme due à l'heure 52, et « dans certains cas, une notification peut être affichée comme en retard avant que 72 heures ne se soient écoulées depuis que le fabricant ou le gestionnaire de logiciels libres a eu connaissance de l'événement ». L'ENISA indique que la logique sera modifiée dans une version future pour utiliser le champ de prise de connaissance. D'ici là, l'horloge de la plateforme n'est pas celle du règlement, et la FAQ précise que les compteurs « ne remplacent pas la responsabilité des fabricants » de respecter les délais propres de l'article 14.

Pour le rapport final, il y a deux compteurs et l'un manque volontairement. Pour un incident grave, la plateforme compte un mois à partir de la soumission de la notification de 72 heures, ce qui est l'article 14(4)(c). Pour une vulnérabilité activement exploitée, il n'y a pas de compteur, parce que l'article 14(2)(c) court 14 jours à partir de la disponibilité d'une mesure corrective ou d'atténuation, et que la plateforme ne peut pas connaître cette date avant que vous la saisissiez. C'est la même distinction que la plupart des articles sur les délais du CRA manquent, et la raison pour laquelle le calculateur de notre page des délais demande la date du correctif séparément.

Après avoir appuyé sur soumettre

Un brouillon enregistré n'est visible que par vous. La soumission de l'alerte précoce l'enregistre, la rend accessible au coordinateur et à l'ENISA, et envoie un courriel et une alerte au coordinateur, à l'ENISA et à chaque représentant du fabricant. Les coordinateurs des autres États membres que vous avez nommés ne reçoivent rien automatiquement : la guidance de l'ENISA indique que les CSIRT concernés « ne recevront l'alerte précoce qu'après diffusion manuelle par le CSIRT désigné comme coordinateur ». Il en va de même pour la notification de 72 heures et le rapport final.

Vous pouvez mettre à jour une notification à toute étape jusqu'à la soumission du rapport final ; la plateforme la rend alors non modifiable, et une notification que le coordinateur a clôturée ne peut pas non plus être mise à jour. Une mise à jour alerte le coordinateur, l'ENISA et tout CSIRT qui a déjà reçu la notification. Les alertes du tableau de bord sont bleues tant qu'elles ne sont pas lues ; les rouges « n'apparaissent que lorsqu'une action exceptionnelle ou critique s'est produite », l'exemple de l'ENISA étant que le coordinateur a invalidé une soumission.

Demander que la diffusion soit retardée

L'article 16(2) dispose que le coordinateur « diffuse sans retard la notification » aux coordinateurs des États membres où le produit est disponible, puis prévoit deux exceptions. Dans des circonstances exceptionnelles, « en particulier à la demande du fabricant et compte tenu du niveau de sensibilité des informations notifiées », le coordinateur peut retarder la diffusion pour des motifs justifiés liés à la cybersécurité pendant la période strictement nécessaire. Et dans des « circonstances particulièrement exceptionnelles », lorsque le fabricant indique dans la notification de 72 heures l'un de trois éléments, seuls le fait qu'une notification a été faite, les informations générales sur le produit, la nature générale de l'exploit et le fait que des motifs ont été invoqués parviennent à l'ENISA jusqu'à ce que la notification complète soit diffusée. Les trois, textuellement :

(a) que la vulnérabilité notifiée a été activement exploitée par un acteur malveillant et que, selon les informations disponibles, elle n'a été exploitée dans aucun autre État membre que celui du CSIRT désigné comme coordinateur auquel le fabricant a notifié la vulnérabilité ; (b) que toute diffusion ultérieure immédiate de la vulnérabilité notifiée entraînerait probablement la fourniture d'informations dont la divulgation serait contraire aux intérêts essentiels de cet État membre ; ou (c) que la vulnérabilité notifiée présente un risque élevé imminent en matière de cybersécurité découlant de sa diffusion ultérieure ;

Sur la plateforme, c'est un interrupteur, disponible à exactement un endroit : la notification de 72 heures d'une vulnérabilité activement exploitée. L'activer fait apparaître un « PEC delay reason » avec les trois motifs en cases à cocher et une justification optionnelle de 800 caractères « qui peut aider le CSIRT désigné comme coordinateur à décider ». L'état de diffusion devient « 72h Submitted under PEC », l'ENISA ne reçoit que les informations limitées, et la décision de diffuser ou non, et quand, appartient au coordinateur, pas au fabricant. Un interrupteur est une demande.

Ce que le coordinateur peut faire de cette demande est désormais fixé par le règlement délégué (UE) 2026/881 de la Commission du 11 décembre 2025, publié au Journal officiel le 20 avril 2026. L'article 3 ne permet au coordinateur de retarder la diffusion que si les risques de cybersécurité de la diffusion l'emportent sur ses bénéfices, si ces risques ne peuvent être traités par des restrictions telles que le Traffic Light Protocol, et si l'une de quatre conditions est remplie : le fabricant a indiqué qu'une atténuation efficace est attendue dans les 72 heures, auquel cas le délai prend fin si elle n'arrive pas ; la notification contient de quoi construire un exploit, « en particulier lorsque la vulnérabilité peut être facilement identifiée et exploitée par des acteurs disposant de compétences et de ressources limitées » ; le coordinateur peut partager assez pour que les autres CSIRT atténuent sans la notification complète ; ou le coordinateur a eu connaissance de la vulnérabilité en tant qu'intermédiaire de confiance dans une divulgation coordonnée. Dans les deuxième et troisième cas, la notification complète part dès qu'une atténuation est disponible. Les articles 4 et 5 ajoutent des motifs qui concernent les destinataires, non le fabricant : un CSIRT, ou la plateforme elle-même, qui a subi un incident mettant en doute sa capacité à garder la notification confidentielle.

La description honnête de l'interrupteur est donc celle-ci : si un correctif arrive dans les trois jours, ou si les détails donneraient à un attaquant peu qualifié un exploit fonctionnel, dites-le, cochez le motif qui convient, et donnez les faits au coordinateur dans les 800 caractères. Puis planifiez comme si la diffusion avait lieu de toute façon.

Si la plateforme est indisponible

FAQ 25 : si la plateforme est temporairement indisponible, attendez qu'elle revienne et soumettez alors. Si vous estimez entre-temps qu'une communication immédiate est nécessaire, vous pouvez contacter directement votre coordinateur, mais « la notification doit tout de même être soumise via la SRP dès qu'elle est à nouveau disponible ». Certains coordinateurs ont publié une solution de repli : le NCSC irlandais donne une adresse électronique d'urgence pour le cas où l'ENISA a déclaré la plateforme hors ligne, et précise que les envois à cette adresse ne sont acceptés que dans ce cas. L'article 17(6) oblige chaque coordinateur à fournir une assistance sur l'article 14, « en particulier » aux fabricants qui sont des micro, petites ou moyennes entreprises ; le service d'assistance de l'ENISA est joignable par courriel depuis la page de la FAQ.

Cinq choses que la FAQ tranche

1. Pas de notification rétroactive. Un fabricant qui avait déjà connaissance de l'exploitation active avant le 11 septembre 2026 n'est pas tenu de la notifier maintenant ; la prise de connaissance après cette date déclenche l'obligation, même si la vulnérabilité elle-même était ancienne ou connue.
2. Les produits déjà sur le marché sont concernés. L'article 14 s'applique à partir du 11 septembre 2026 à tout produit comportant des éléments numériques relevant du règlement, y compris les produits mis sur le marché avant le 11 décembre 2027.
3. Composants tiers. Pour une vulnérabilité dans un composant que vous intégrez, l'ENISA renvoie à la section 5.4 de la FAQ de la Commission sur la mise en œuvre et au paragraphe 218 des orientations de la Commission du 27 juillet 2026, plutôt que de répondre elle-même. Lisez-les avant de décider que ce n'est pas à vous de notifier.
4. La notification n'accroît pas votre responsabilité. Article 17(4) : « le simple fait de la notification ... n'expose pas la personne physique ou morale qui l'effectue à une responsabilité accrue ».
5. Après le correctif, la vulnérabilité devient publique. Article 17(5) : dès qu'une mise à jour de sécurité ou une autre mesure corrective est disponible, l'ENISA ajoute la vulnérabilité notifiée à la base de données européenne des vulnérabilités, en accord avec le fabricant.

Ce qu'il faut préparer avant d'avoir besoin de tout cela

• Des comptes EU Login avec authentification multifacteur pour la personne qui notifie et un suppléant, créés aujourd'hui, et une autorisation écrite pour les deux.
• Votre État membre et votre coordinateur, décidés selon l'article 14(7) et inscrits dans la procédure d'incident, pour que personne ne choisisse entre des entrées de menu déroulant à la première heure.
• Un inventaire des produits avec les identifiants exacts de version, de build, de modèle ou de firmware que demande le champ version, et une liste des États membres où chaque produit est mis à disposition, parce que ce champ est requis dans l'alerte précoce.
• Une convention pour « avoir connaissance », et une règle selon laquelle l'horodatage est enregistré en UTC au moment où il est fixé.
• Un brouillon d'une page des champs de l'alerte précoce dans un document d'où vous pouvez copier : titre de moins de 255 caractères, résumé de moins de 4 000, les deux dates, les États membres.
• Le nom de la personne qui décide, dans les premières 72 heures, s'il faut cocher la case des circonstances exceptionnelles, et sur quels faits.

La plateforme ne fera rien de tout cela pour vous, et cet article non plus. Ce qu'il peut faire, c'est faire de la première heure une affaire de saisie plutôt que de lecture.

Sources

• ENISA, pages de la Single Reporting Platform : la page principale, la FAQ (mise à jour le 11 septembre 2026), les pages de guidance sur l'inscription des utilisateurs, la soumission et la mise à jour des notifications, les fonctions de l'interface et les circonstances particulièrement exceptionnelles (mises à jour les 9 et 10 septembre 2026), le glossaire SRP, le manuel d'utilisation AR, et les conditions d'utilisation v1.0 du 10 septembre 2026, tous lus le 12 septembre 2026.
• ENISA, List of CSIRTs Designated as Coordinators, mise à jour le 10 septembre 2026.
• Règlement (UE) 2024/2847, articles 14, 16 et 17, et article 71(2).
• Règlement délégué (UE) 2026/881 de la Commission du 11 décembre 2025, articles 3 à 5, JO L du 20 avril 2026.
• Commission européenne, orientations C(2026) 5252 du 27 juillet 2026, et FAQ sur la mise en œuvre du CRA, section 5.
• NCSC Irlande, page sur les obligations de notification du Cyber Resilience Act, mise à jour le 11 septembre 2026.

Ceci n'est pas un avis juridique. Le glossaire est un tableau de 39 champs et la FAQ compte 31 questions ; les deux sont assez courts pour être lus avant d'en avoir besoin.