Plateforme unique de signalement

La plateforme unique de signalement (Single Reporting Platform, SRP) est le portail web par lequel les fabricants envoient les notifications qu'exige le Cyber Resilience Act (CRA) : vulnérabilités activement exploitées et incidents graves touchant leurs produits. L'ENISA, l'Agence de l'Union européenne pour la cybersécurité, l'exploite en vertu de l'article 16 du règlement (UE) 2024/2847. Elle a été lancée le 11 septembre 2026, le jour où les obligations de signalement du CRA ont commencé à s'appliquer.

Ce qui est signalé, et dans quels délais

Les fabricants signalent deux types d'événements : une vulnérabilité activement exploitée dans un produit comportant des éléments numériques, et un incident grave ayant un impact sur la sécurité d'un tel produit. Les deux notions sont définies dans le règlement. Chacun suit trois étapes :

Étape	Délai	S'applique à
Alerte précoce	Dans les 24 heures après en avoir pris connaissance	Les deux
Notification	Dans les 72 heures après en avoir pris connaissance	Les deux
Rapport final	Dans les 14 jours après la mise à disposition d'un correctif ou d'une mesure d'atténuation	Vulnérabilités activement exploitées
Rapport final	Dans un délai d'un mois après la notification	Incidents graves

Les délais sont fixés par l'article 14 du CRA, et non par le portail ; la FAQ de la SRP de l'ENISA les reprend. L'obligation couvre les produits déjà sur le marché, et pas seulement ceux mis sur le marché après l'application complète du CRA. L'article 14 impose aussi aux fabricants d'informer les utilisateurs concernés, ce qu'ils font eux-mêmes : la plateforme s'adresse aux autorités, pas aux clients.

Qui reçoit une notification

Un fabricant soumet chaque notification une seule fois. Elle parvient en même temps au CSIRT désigné comme coordinateur dans l'État membre de l'établissement principal du fabricant et à l'ENISA, sauf circonstances particulièrement exceptionnelles. Le coordinateur la transmet aux CSIRT des autres États membres où le produit est disponible. L'ENISA publie la liste des coordinateurs désignés sur sa page SRP.

Une fois qu'une vulnérabilité notifiée est corrigée, l'ENISA peut la divulguer dans la base européenne des vulnérabilités (EUVD), en accord avec le fabricant. Le lien entre l'EUVD et les identifiants CVE est expliqué à l'entrée CVE.

Comment fonctionne l'accès

Les fabricants agissent sur la plateforme par l'intermédiaire d'Assigned Representatives (AR). Chaque AR se connecte avec un compte EU Login personnel doté de l'authentification multifacteur. Un fabricant a un Primary AR, qui peut inviter jusqu'à 20 Secondary AR, et ceux-ci peuvent soumettre et mettre à jour les notifications du fabricant. Un fabricant comptant plusieurs sociétés dans son groupe coordonne en interne qui signale pour quelle entité.

Ce que la plateforme ne fait pas encore

En novembre 2026, selon la FAQ de la SRP :

• Pas d'API. Aucune interface de programmation n'est fournie dans la première version : les notifications se saisissent dans l'interface web. L'ENISA indique qu'une API pourrait être envisagée dans une phase ultérieure et que les organisations peuvent automatiser leurs propres processus internes de signalement.
• Pas encore de signalement volontaire. Les notifications volontaires au titre de l'article 15, par exemple d'une vulnérabilité qui n'est pas activement exploitée, sont prévues pour une phase ultérieure. Pour l'instant, la plateforme n'accepte que les notifications obligatoires.

L'ENISA qualifie la version de lancement de capacité opérationnelle initiale et prévoit de l'étendre. Son annonce de lancement précise aussi que les obligations de signalement des gestionnaires de logiciels libres (open-source software stewards) s'appliquent à partir du 11 décembre 2027.

Se préparer à signaler

Les 24 heures commencent quand vous prenez connaissance de l'exploitation : l'essentiel du travail se fait donc avant que quiconque se connecte.

• Enregistrez vos Assigned Representatives avant d'en avoir besoin, avec un suppléant dans un autre fuseau horaire.
• Convenez à l'avance de qui décide qu'une vulnérabilité est considérée comme activement exploitée, et en combien de temps.
• Tenez, pour chaque version, un registre des composants de chaque produit, afin de pouvoir nommer les produits et versions concernés en quelques heures. Voir SBOM au moment du build et sommes-nous concernés par une CVE ?.
• Préparez l'avis aux utilisateurs concernés, puisque la plateforme ne l'envoie pas.
• Conservez le texte soumis et les horodatages dans vos propres archives.

CRACI prépare le contenu des notifications du CRA (alerte précoce, notification et rapport final) ; une personne chez le fabricant les soumet via la plateforme unique de signalement.

Pour le règlement dans son ensemble, voir qu'est-ce que le CRA, le guide du CRA et l'entrée du glossaire CRA. La façon dont une équipe de sécurité produit gère cela au quotidien est traitée sous PSIRT.