Dans vingt jours, le 11 septembre 2026, le Cyber Resilience Act entre dans sa phase la plus opérationnelle. Toute organisation qui fabrique ou édite un produit comportant des éléments numériques — logiciel, firmware, objet connecté — devra notifier une vulnérabilité activement exploitée à l'ENISA dans les 24 heures suivant sa détection. La plateforme unique de déclaration, le Single Reporting Platform, sera accessible ce jour-là. Le délai n'est pas négociable : il découle directement du règlement (UE) 2024/2847, publié au Journal officiel de l'Union européenne en octobre 2024.
Ce qui surprend encore beaucoup d'équipes : l'obligation ne couvre pas seulement les produits lancés après le 11 septembre. Elle s'applique à tout produit déjà présent sur le marché européen. Un logiciel SaaS commercialisé depuis 2021, un routeur industriel déployé en 2019, une bibliothèque open source embarquée dans un équipement médical : si l'éditeur ou le fabricant a son établissement principal dans l'Union européenne — ou commercialise en Europe depuis l'extérieur — il est soumis à cette obligation dès la date d'entrée en vigueur.
Ce que le règlement impose concrètement
Le mécanisme de notification fonctionne en trois temps. Dans les 24 heures suivant la détection d'une vulnérabilité activement exploitée : une déclaration initiale à l'ENISA via le Single Reporting Platform, mentionnant la nature de la vulnérabilité et les produits concernés. Dans les 72 heures : une notification complète avec l'évaluation de l'impact et les mesures prises ou planifiées. Dans les 14 jours suivant la disponibilité d'un correctif : un rapport final documentant la remédiation.
La notification transite par un point d'entrée unique — le CSIRT national du pays où l'entreprise a son établissement principal. En France, c'est le CERT-FR, rattaché à l'ANSSI. L'information est transmise simultanément à l'ENISA, qui coordonne au niveau européen. Cette architecture évite la multiplication des interlocuteurs : une seule déclaration, un seul canal, deux destinataires automatiques.
Les sanctions pour non-respect atteignent 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial annuel. La Commission européenne estime que 60 % des fabricants concernés sont des PME — ce qui signifie que l'essentiel du travail de mise en conformité reste à faire dans des structures sans équipe GRC dédiée.
Le prérequis que la plupart des équipes n'ont pas encore
Pour notifier une vulnérabilité en 24 heures, il faut d'abord être capable de la détecter dans ce délai. Ce n'est pas trivial. Une vulnérabilité activement exploitée peut toucher un composant tiers embarqué — une bibliothèque open source, un SDK, un moteur de rendu — que l'éditeur ne surveille pas directement. La Commission européenne, dans son guide pratique publié le 27 juillet 2026, est explicite : sans SBOM (Software Bill of Materials) à jour et sans processus de surveillance des vulnérabilités par composant, la conformité est impossible.
Un SBOM est l'inventaire formel de tous les composants logiciels d'un produit : bibliothèques, dépendances directes et transitives, versions, licences. Il permet de savoir en quelques minutes si un composant annoncé vulnérable — par exemple via une CVE publiée sur le NVD — est présent dans un produit. Sans cet inventaire, la chaîne de détection est aveugle.
L'article sur les SBOM sous NIS2 et DORA détaille les méthodes de génération et les outils disponibles. Pour le CRA, l'exigence est identique mais le périmètre est différent : il couvre les fabricants de produits, pas seulement les opérateurs de services essentiels.
Ce que l'échéance du 11 septembre ne couvre pas encore
Il est utile de séparer ce qui entre en vigueur le 11 septembre de ce qui reste à venir. La phase de septembre 2026 couvre uniquement les obligations de notification de vulnérabilités et d'incidents. Les exigences relatives à la conception sécurisée des produits — notamment l'obligation d'intégrer la sécurité dès la conception, de fournir une documentation technique conforme et de réaliser une évaluation de conformité — s'appliquent à partir du 11 décembre 2027, pour les nouveaux produits mis sur le marché à cette date ou après.
Cela ne signifie pas que les exigences de conception peuvent attendre 2027. Les organismes d'évaluation de la conformité (OEC) ont été désignés en juin 2026 : les éditeurs de produits classés "importants" ou "critiques" au sens du CRA peuvent dès maintenant soumettre leurs produits à évaluation. Les premiers certifiés seront en position favorable pour répondre aux appels d'offres publics et aux exigences d'achat des grands groupes qui, eux, ont déjà intégré le CRA dans leurs grilles de qualification fournisseurs.
Trois actions à engager dans les vingt prochains jours
Cartographier les produits dans le périmètre CRA. Le règlement vise les produits comportant des "éléments numériques" mis sur le marché européen. La notion est large : un logiciel vendu en licence, un service SaaS avec une composante logicielle autonome, un équipement connecté. L'exclusion concerne les logiciels développés exclusivement en interne, sans mise sur le marché. Pour chaque produit dans le périmètre, identifier le responsable de la notification : c'est le fabricant ou l'éditeur, pas le distributeur.
Mettre en place ou auditer le processus de gestion des vulnérabilités. La chaîne doit couvrir : la surveillance des sources (NVD, CERT-FR, listes CVE des composants utilisés), la corrélation avec le SBOM pour identifier les produits affectés, une procédure de décision sous 24 heures (qui valide, qui notifie, par quel canal), et un registre traçable des notifications émises. L'ENISA a publié un modèle de notification sur son site en juillet 2026. Le tester avant le 11 septembre évite de le découvrir sous pression.
Désigner un point de contact réglementaire. La notification doit provenir d'un interlocuteur identifiable. Le CRA n'impose pas une fonction dédiée, mais le processus doit être documenté : qui est l'interlocuteur CERT-FR, qui signe les notifications, qui assure la continuité en cas d'absence. Dans une PME, cela peut être le RSSI ou le DSI ; dans une grande structure, l'équipe PSIRT (Product Security Incident Response Team).
Ce que cela change pour les acheteurs de produits numériques
Le CRA ne concerne pas uniquement les fabricants. Les organisations qui achètent des produits numériques — logiciels, équipements connectés, plateformes SaaS avec composante on-premise — ont un intérêt direct à vérifier que leurs fournisseurs sont en conformité. Un fournisseur qui ne respecte pas l'obligation de notification est un fournisseur qui ne vous informera pas en temps utile d'une vulnérabilité affectant votre infrastructure.
Les directions achats et les équipes GRC gagneraient à ajouter une clause CRA dans leurs questionnaires fournisseurs dès maintenant : le fournisseur dispose-t-il d'un SBOM pour les produits livrés ? A-t-il un processus de notification conforme au CRA ? A-t-il testé ce processus ? Ces questions rejoignent les obligations NIS2 sur la chaîne d'approvisionnement et les exigences DORA sur les prestataires ICT : elles ne doublonnent pas, elles se complètent.
Conclusion
Le 11 septembre 2026 n'est pas une date symbolique. C'est le premier jalon opérationnel du CRA, celui où les obligations de notification deviennent exécutoires, pour tous les produits déjà sur le marché, sous peine de sanctions significatives. L'ENISA a ouvert son portail. Le CERT-FR est prêt à recevoir les notifications. La question n'est plus si votre organisation est concernée, mais si elle peut respecter le délai de 24 heures.
La mise en place d'un SBOM et d'un processus de gestion des vulnérabilités n'est pas un projet de plusieurs mois : les équipes qui s'y sont attelées en juin 2026 ont tenu en six à huit semaines. Pour les organisations qui n'ont pas commencé, vingt jours suffisent pour au moins cartographier le périmètre et désigner les responsables — conditions minimales pour éviter une notification ratée lors du premier incident.