Depuis le 11 septembre 2026, les fabricants doivent notifier dans toute l'UE les vulnérabilités activement exploitées et les incidents graves — alerte précoce sous 24 heures, via la Single Reporting Platform (SRP) de l'ENISA. Nous vous rendons prêts à notifier avant que le chrono ne démarre pour vous la première fois.
Le Cyber Resilience Act ne s'applique pleinement qu'à partir de décembre 2027 — mais les obligations de notification de l'article 14 s'appliquent depuis le 11 septembre 2026, soit 15 mois plus tôt. Depuis, les fabricants de produits comportant des éléments numériques doivent notifier deux types d'événements : les vulnérabilités activement exploitées dans leurs produits et les incidents graves ayant un impact sur la sécurité du produit. L'obligation s'attache au produit — y compris aux produits présents sur le marché depuis longtemps. Il n'existe aucune clause d'antériorité pour la notification.
La notification passe par la Single Reporting Platform (SRP) : une plateforme centrale exploitée par l'ENISA, qui transmet automatiquement chaque notification au CSIRT national coordinateur, aux CSIRT de tous les États membres où le produit est mis à disposition et à l'ENISA elle-même — une seule notification au lieu de 27. La plateforme est en service depuis le 11 septembre 2026 ; en Allemagne, le CERT-Bund du BSI est le CSIRT coordinateur.
L'alerte précoce et la notification courent à partir de la prise de connaissance (« becoming aware ») — pas à partir de la correction. Les week-ends comptent.
Dans les 24 heures suivant la prise de connaissance : une notification succincte au CSIRT coordinateur et à l'ENISA — pour que les alertes atteignent les autres avant la vague d'exploitation.
Dans les 72 heures : des informations générales et une première évaluation — gravité, impact et, si déjà disponibles, mesures correctives ou d'atténuation engagées.
Pour les vulnérabilités, au plus tard 14 jours après la disponibilité d'une mesure corrective ; pour les incidents, un mois après la notification des 72 heures : causes, déroulé et contre-mesures.
Deux faits générateurs, un seul canal : la Single Reporting Platform de l'ENISA.
Il existe des preuves fiables qu'un attaquant a exploité une vulnérabilité de votre produit sans l'autorisation du propriétaire du système. Les preuves peuvent provenir de votre télémétrie, de signalements de CSIRT, de clients ou de chercheurs en sécurité, ou de catalogues d'exploits.
Un incident est grave s'il porte atteinte — ou est susceptible de porter atteinte — à la capacité du produit à protéger des données et fonctions sensibles, ou s'il a conduit ou peut conduire à l'introduction ou à l'exécution de code malveillant. Le potentiel suffit : serveurs de build et canaux de mise à jour compromis en sont le cas d'école.
La SRP achemine votre notification vers le CSIRT désigné coordinateur, la met simultanément à disposition de l'ENISA et la diffuse sans délai aux CSIRT de tous les États membres où le produit est disponible. Les autorités de surveillance du marché reçoivent des informations sélectionnées pour leur mission.
La plateforme est conçue pour la confidentialité. La diffusion ne peut être différée que dans des cas exceptionnels justifiés — par exemple lorsqu'un correctif est imminent — et à la discrétion du CSIRT (art. 16, § 2 CRA ; règlement délégué (UE) 2026/881). Aucun opt-out n'est prévu pour les fabricants.
La plateforme est volontairement sobre — la vraie préparation se joue chez vous.
L'accès à la SRP se fait avec un compte EU Login. Créez des comptes pour au moins deux personnes et organisez les suppléances — l'incident réel ne respecte pas les plannings de congés.
Aucun enregistrement préalable n'est obligatoire — en cas de besoin, l'enregistrement et la notification prennent quelques minutes. Votre CSIRT vérifie les représentants en parallèle, sans bloquer les notifications ; le représentant principal ne peut toutefois inviter d'autres représentants qu'après cette vérification.
Selon l'ENISA, il n'existe toujours pas d'API : chaque notification est saisie manuellement dans le formulaire web — en trois étapes, avec des champs communs et des champs spécifiques vulnérabilité ou incident, et en anglais. Des blocs de texte préparés en anglais et un mapping des champs sont votre levier de vitesse.
Après un incident ou une vulnérabilité exploitée, vous devez aussi informer sans retard les utilisateurs concernés — y compris sur les risques et les mesures correctives. À défaut, le CSIRT peut informer vos utilisateurs lui-même.
Depuis le lancement, le BSI propose un tutoriel vidéo sur l'utilisation de la SRP. Si la plateforme est indisponible, le CERT-Bund accepte exceptionnellement la notification obligatoire par e-mail. Les notifications envoyées peuvent être mises à jour jusqu'au rapport final.
CRA et NIS2 notifient des choses différentes à des autorités différentes. Un même événement peut déclencher plusieurs obligations.
Le fabricant notifie les vulnérabilités activement exploitées et les incidents graves qui touchent le produit — via la SRP au CSIRT et à l'ENISA, au rythme 24 h / 72 h / 14 jours ou 1 mois.
Les entités essentielles et importantes notifient les incidents significatifs de leur organisation via les canaux nationaux (en Allemagne : le BSI) — au rythme 24 h / 72 h / 1 mois.
Un ransomware chez un éditeur de logiciels avec serveur de mise à jour touché peut déclencher à la fois des notifications CRA, NIS2 et RGPD — plus DORA dans le secteur financier. La SRP ne vous décharge que de la notification CRA : construisez une cartographie des obligations avec un processus commun.
Six étapes pour tenir le délai de 24 heures de manière fiable.
Établir l'inventaire des produits et évaluer l'applicabilité du CRA produit par produit — inclure les produits existants, car la notification ne connaît pas de clause d'antériorité.
Déterminer le CSIRT compétent à partir de l'établissement principal (art. 14, § 7), créer des comptes EU Login pour au moins deux personnes et fixer les règles de suppléance.
Définir en interne quand la « connaissance » est acquise, qui la constate et comment l'horodatage est documenté — c'est l'ancre de tous les délais. Organiser la disponibilité le week-end.
Mapper les champs du formulaire SRP sur vos sources internes, préparer des blocs de texte en anglais pour les notifications à 24 h et 72 h et obtenir les validations à l'avance — pas de boucles de comités en situation d'urgence.
Exercice sur table contre la montre avec un scénario réaliste — y compris la communication aux utilisateurs selon l'art. 14, § 8 et le cas inconfortable du vendredi soir.
Mettre en place la veille sur les composants (base de vulnérabilités EUVD, CISA KEV), tenir la SBOM à jour et sécuriser contractuellement les obligations d'information de vos fournisseurs.
Des réponses concises — nous examinons vos produits concrets lors d'un premier entretien.
Oui. Depuis le 11 septembre 2026, l'obligation de l'article 14 s'applique au produit — y compris aux produits déjà commercialisés. Les autres obligations du CRA, comme le marquage CE, s'appliquent à partir du 11 décembre 2027.
À la prise de connaissance (« becoming aware ») : dès que votre entreprise apprend l'exploitation active ou l'incident grave. Pas à la correction, ni après une validation interne — d'où l'importance de définir et documenter à l'avance les déclencheurs et le processus de notification.
Il existe des preuves fiables qu'un attaquant a exploité la vulnérabilité sans l'accord du propriétaire du système (art. 3, pt 42 CRA). Un signalement externe crédible, par exemple d'un CSIRT ou d'un client, peut déclencher le chrono. Les découvertes issues de la recherche en sécurité ou de programmes de bug bounty sans indice d'exploitation malveillante ne sont en revanche pas soumises à notification obligatoire.
Pour les incidents graves, le potentiel suffit : même si l'incident est seulement susceptible d'affecter la capacité du produit à protéger données et fonctions, ou si l'exécution de code malveillant est possible, il est notifiable (art. 14, § 5). Dans le doute : notifiez — une notification n'est pas un aveu de faute.
Pas encore. Selon la FAQ de l'ENISA, la SRP a été lancée sans API ; une API pourrait être envisagée dans une phase ultérieure. Les notifications sont saisies manuellement dans le formulaire web — en anglais. Raison de plus pour préparer des blocs de texte, un mapping des champs et des procédures répétées.
En principe, le CSIRT de l'État membre de votre établissement principal — là où se prennent les décisions essentielles de cybersécurité pour vos produits (art. 14, § 7). Sans établissement dans l'UE, la cascade passe par le mandataire, l'importateur puis le distributeur. En Allemagne, le CERT-Bund du BSI est le CSIRT coordinateur ; l'ENISA publie la liste officielle des CSIRT.
Des amendes jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial — le montant le plus élevé étant retenu — plus des mesures de surveillance du marché pouvant aller jusqu'au rappel. Et si vous n'informez pas vous-même les utilisateurs concernés, le CSIRT peut le faire à votre place — sans votre ton.
Du readiness check à la notification de 24 heures répétée — pragmatique, proche du produit, opposable en audit.
Portefeuille produits, applicabilité et écarts évalués de manière compacte : périmètre, capacité de notification et gestion des vulnérabilités — avec un plan d'action priorisé.
Définir déclencheurs, rôles et chaînes d'escalade, préparer les accès EU Login et l'affectation CSIRT, créer les mappings de champs et blocs de texte pour les notifications à 24 h et 72 h.
Créer ou renforcer votre équipe de réponse produit : politique CVD, point de contact vulnérabilités, tenue de la SBOM et veille exploits comme source fiable de connaissance.
Nous répétons le cas réel contre la montre — y compris l'évaluation à 72 heures, le rapport final et la communication aux utilisateurs selon l'art. 14, § 8. Ensuite, chaque rôle connaît sa partition.
Quand cela arrive : appui à l'évaluation, au confinement et à la notification dans les délais — technique et réglementaire d'une seule main.
Notification aujourd'hui, exigences de l'annexe I et évaluation de conformité demain : nous vous accompagnons jusqu'au marquage CE — en mode projet ou en GRC as a Service.
Dès que vous enregistrez un incident ou une vulnérabilité activement exploitée, VamiGRC lance les workflows de notification adéquats, suit les délais et prépare des notifications pour le BSI et l’ENISA, que votre équipe vérifie et soumet elle-même.
Lors d'un premier entretien sans engagement, nous clarifions où en est votre portefeuille, quels écarts menacent le délai de 24 heures et comment devenir rapidement capable de notifier.
