À partir du 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 nouvelle Single Reporting Platform (SRP) de l'ENISA. Nous vous rendons prêts à notifier avant que le chrono ne démarre pour 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 démarrent 15 mois plus tôt. Dès le 11 septembre 2026, 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 entre en service le 11 septembre 2026 ; l'ENISA a publié les documents d'accompagnement (factsheet, FAQ et guides utilisateurs) le 31 juillet 2026.
Tous les délais 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 — que la tentative ait réussi ou non. 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.
Après le premier accès, votre CSIRT valide les représentants désignés — selon la FAQ de l'ENISA, en parallèle du processus de notification. Le dépôt de la notification n'en est pas retardé.
Selon la FAQ de l'ENISA, la SRP ne proposera pas d'API dans un premier temps : 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. Des blocs de texte préparés 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.
L'ENISA prévoit une phase de test avant la mise en service ainsi qu'un webinaire d'onboarding environ deux semaines avant le lancement. Profitez des deux — avec des dossiers de notification préparés, le 11 septembre devient un jour ouvré comme un autre.
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 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. À partir du 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, ou a tenté de le faire — le succès de l'attaque est indifférent (art. 3, pt 42 CRA). Un signalement externe crédible, par exemple d'un CSIRT ou d'un client, peut déclencher le chrono.
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 au lancement. Selon la FAQ de l'ENISA, la SRP fonctionnera d'abord sans API — les notifications sont saisies manuellement dans le formulaire web. 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 BSI est le point de contact central ; 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é jusqu'au 11 septembre.
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.
Lors d'un premier entretien sans engagement, nous clarifions où en est votre portefeuille, quels écarts menacent le délai de 24 heures et à quoi ressemble votre feuille de route jusqu'au 11 septembre.
