Aller au contenu
spilma

CRA : la plateforme de signalement ouverte, mais inachevée

L'ENISA a mis en service la plateforme unique de signalement du Cyber Resilience Act le 11 septembre 2026, le jour même où l'obligation de l'utiliser est devenue contraignante. Ouverte ne veut pas dire achevée : l'ENISA qualifie cette version de « capacité opérationnelle initiale », elle n'accepte que les notifications obligatoires de l'article 14, elle est livrée sans API, et le canal de signalement volontaire de l'article 15 est reporté à une phase ultérieure. La plateforme est arrivée à l'heure et incomplète, ce qui laisse aux fabricants une obligation pleinement applicable et un outil partiel.

En bref :

  • La plateforme est le portail SRP et l'inscription exige un compte EU Login avec authentification multifacteur.
  • Chaque fabricant dispose d'un seul représentant désigné principal et d'au maximum 20 représentants secondaires. Ces derniers ne peuvent pas s'inscrire eux-mêmes.
  • Aucune API dans cette version : une première notification est une saisie manuelle par une personne nommément désignée.
  • Si la plateforme est indisponible, la réponse de l'ENISA est d'attendre son rétablissement puis de soumettre. Rien dans ses indications ne dit que le délai de 24 heures est suspendu.
  • Le règlement délégué (UE) 2026/881 autorise le CSIRT destinataire à retenir une notification vis-à-vis des autres équipes nationales, pour une durée n'excédant pas le strict nécessaire.

La Commission décrit la plateforme comme opérationnelle depuis le 11 septembre 2026, gérée par l'ENISA en coopération avec le réseau des CSIRT. La formulation de l'ENISA est plus étroite. Elle a « déployé la capacité opérationnelle initiale » et indique qu'elle continuera d'améliorer et d'étendre ses fonctionnalités dans les mois à venir, sur la base de l'expérience opérationnelle et des besoins des utilisateurs.

Deux de ces manques comptent immédiatement.

Le signalement volontaire de l'article 15 n'est pas disponible. Le CRA permet aux fabricants, et à d'autres, de signaler des vulnérabilités ou des incidents hors du champ obligatoire. L'ENISA indique que ce canal sera introduit lors d'une phase ultérieure. D'ici là, la plateforme est un instrument de conformité, pas un lieu où partager ce que l'écosystème gagnerait à savoir.

Il n'y a pas d'API. Dans cette première version, chaque notification est saisie à la main, dans un navigateur, par une personne disposant du bon rôle. Une équipe qui comptait déclencher l'alerte précoce depuis son outillage d'incident doit insérer une étape humaine à la place, et cette étape doit fonctionner à trois heures du matin.

Seuls les fabricants et les stewards de logiciels libres peuvent soumettre une notification. L'ENISA renvoie tous les autres, y compris les chercheurs en sécurité, vers le CSIRT national compétent. Les stewards eux-mêmes ne sont concernés qu'à compter du 11 décembre 2027 : aujourd'hui, la plateforme ne sert que les fabricants.

L'inscription repose sur deux rôles, dont un point de défaillance unique

Section intitulée « L'inscription repose sur deux rôles, dont un point de défaillance unique »

L'accès s'appuie sur EU Login avec authentification multifacteur, et non sur un compte propre à la plateforme. Si personne dans la chaîne de conformité ne dispose aujourd'hui d'un EU Login, c'est la première tâche, et elle peut être anticipée.

Le modèle de rôles concentre le risque opérationnel :

RôleMode d'obtentionLimite
Représentant désigné principalS'inscrit directement sur la plateforme, en sélectionnant le CSIRT désigné comme coordinateurUn seul par fabricant
Représentant désigné secondaireUniquement sur invitation du principalJusqu'à 20

Puisque les représentants secondaires n'existent que par invitation du principal, celui-ci est un goulot d'étranglement par construction. Un fabricant dont l'unique représentant principal a quitté l'entreprise, perdu son facteur d'authentification ou simplement dort a un problème d'enrôlement au pire moment. Désigner un principal et inviter les secondaires prend cinq minutes aujourd'hui, et devient un incident dans l'incident plus tard.

À noter : le principal choisit le CSIRT désigné comme coordinateur au moment de l'inscription. Ce choix constitue la détermination de l'article 14(7), et il ne correspond pas au lieu d'immatriculation de la société. Le raisonnement est détaillé dans notre note sur les cascades de signalement de l'article 14.

La plateforme peut être indisponible, sans suspension documentée du délai

Section intitulée « La plateforme peut être indisponible, sans suspension documentée du délai »

Lors de notre note d'août, ni l'ENISA ni la Commission ne publiaient de conduite à tenir si la plateforme était injoignable. L'ENISA y répond désormais. En cas d'indisponibilité temporaire, les fabricants « doivent attendre qu'elle redevienne disponible puis soumettre la notification requise », tout en pouvant contacter directement leur CSIRT lorsqu'une communication immédiate paraît nécessaire.

À lire au regard de l'article 14. L'alerte précoce à 24 heures, la notification à 72 heures et le rapport final sont des obligations pesant sur le fabricant, déclenchées par la prise de connaissance. L'indication de l'ENISA dit quoi faire quand l'outil est hors service ; ni cette indication ni le règlement délégué (UE) 2026/881 n'énoncent que le délai du fabricant est suspendu pendant ce temps. La lecture prudente est que l'horloge continue de courir, que vous documentez l'indisponibilité et vos tentatives, et que vous empruntez la voie directe vers le CSIRT lorsque le retard deviendrait significatif.

À quoi ressemble une diffusion retardée, vue de l'autre côté

Section intitulée « À quoi ressemble une diffusion retardée, vue de l'autre côté »

Le règlement délégué (UE) 2026/881 du 11 décembre 2025 a été publié le 20 avril 2026 et est entré en vigueur le vingtième jour suivant sa publication. Il régit autre chose que votre délai : les cas dans lesquels le CSIRT qui reçoit votre notification peut la retenir vis-à-vis des autres équipes nationales.

Il retient trois familles de motifs :

  1. La nature de l'information, lorsque le risque cyber lié à sa circulation l'emporte sur le bénéfice et que les protocoles habituels de diffusion et d'action ne suffisent pas à le contenir. Parmi les cas cités : un fabricant indiquant qu'un correctif est attendu sous 72 heures, une information permettant à un acteur peu qualifié d'exploiter facilement la faille, une situation où une information partielle suffit aux autres pour atténuer le risque, et un processus de divulgation coordonnée en cours.
  2. La situation du CSIRT destinataire, lorsqu'une équipe destinataire a elle-même subi un incident de cybersécurité ou ne peut démontrer une capacité de sécurité adéquate.
  3. La compromission de la plateforme elle-même.

Le retard n'excède pas le strict nécessaire, avec un maximum de 72 heures lorsqu'une mise à jour de sécurité est attendue. Pendant ce temps, l'ENISA ne reçoit qu'une confirmation de l'existence d'une notification, des informations générales sur le produit, un résumé de la nature de l'exploitation et l'indication que des motifs de sécurité ont été invoqués, plutôt que le détail sensible.

Pour un fabricant, la conséquence pratique est étroite mais utile à connaître : le principe du signalement unique ne signifie pas une circulation immédiate partout, et un correctif en préparation est un motif explicite et reconnu pour qu'un CSIRT retienne le détail.

  1. Créer les comptes EU Login et activer le MFA, pour le représentant principal et au moins deux secondaires. C'est la seule étape qui ne s'improvise pas.
  2. Inscrire le principal et envoyer les invitations aux secondaires dès maintenant. La dépendance à l'invitation est le mode de défaillance ; la découvrir pendant un incident est le scénario à éviter.
  3. Consigner votre détermination au titre de l'article 14(7) et le CSIRT retenu, avec le raisonnement. Le lieu où les décisions de cybersécurité sont principalement prises est une question de fait.
  4. Remplacer toute automatisation prévue par une étape humaine nommée, faute d'API, et la répéter en dehors des heures ouvrées.
  5. Écrire le cas de l'indisponibilité dans la procédure : tenter la plateforme, conserver la preuve de l'indisponibilité, et escalader directement vers le CSIRT plutôt que de traiter la panne de l'outil comme un délai supplémentaire.

Sources & références

  1. The CRA Single Reporting Platform is launched, ENISA www.enisa.europa.eu/news/the-cra-single-reporting-platform-is-launched
  2. Single Reporting Platform (SRP), foire aux questions, ENISA www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
  3. Cyber Resilience Act, obligations de signalement, Commission européenne digital-strategy.ec.europa.eu/en/policies/cra-reporting
  4. Règlement délégué (UE) 2026/881 du 11 décembre 2025, EUR-Lex eur-lex.europa.eu/eli/reg_del/2026/881/oj/eng
  5. Règlement (UE) 2024/2847, Cyber Resilience Act, articles 14 à 16, EUR-Lex eur-lex.europa.eu/eli/reg/2024/2847/oj