Cyber Resilience Act : 24 heures pour notifier, à partir du 11 septembre 2026

TL;DR

Dans un mois, tout fabricant d’un produit numérique vendu dans l’Union devra signaler à l’ENISA et au CSIRT national toute vulnérabilité activement exploitée, sous vingt-quatre heures. Ce n’est pas le gros du Cyber Resilience Act — celui-là arrive en décembre 2027 — mais c’est la première obligation réellement opposable, et elle suppose une chaîne interne qui ne s’improvise pas en trois jours.

Trois paliers, et un seul qui vous engage maintenant

Le Cyber Resilience Act se déploie par étapes, ce qui explique qu’une partie de l’écosystème n’ait pas encore bougé.

11 juin 2026. Le chapitre IV est entré en vigueur : il organise la désignation des organismes chargés d’évaluer la conformité des produits numériques. En France, l’ANSSI joue le rôle d’autorité notifiante, sur la base d’une accréditation délivrée par le Comité français d’accréditation. La période de juin à décembre 2026 voit l’accréditation puis la notification de ces organismes. C’est de la tuyauterie institutionnelle : aucune obligation ne pèse encore sur les fabricants à ce stade.

11 septembre 2026. C’est la première échéance réellement opposable. Les obligations de signalement des vulnérabilités activement exploitées et des incidents graves entrent en application, au titre de l’article 14.

11 décembre 2027. L’ensemble des obligations devient contraignant pour les fabricants, importateurs et distributeurs : exigences essentielles de sécurité, documentation technique, marquage CE sur les produits numériques. Le texte s’appliquera aux produits mis sur le marché après cette date, mais aussi aux produits existants faisant l’objet de mises à jour ou de modifications significatives.

Autrement dit : dans un mois, vous n’aurez pas à prouver que votre produit est sécurisé. Vous aurez à prouver que vous savez signaler quand il ne l’est plus.

Ce qui compte : « activement exploitée »

Le seuil de déclenchement est plus étroit qu’une simple découverte de faille, et c’est ce qui rend l’obligation tenable.

L’obligation vise deux catégories d’événements : les vulnérabilités activement exploitées affectant votre produit, et les incidents graves ayant un impact sur sa sécurité. Une CVE publiée dont personne ne se sert n’entre pas dans le périmètre. Une faille dont vous avez connaissance d’une exploitation en conditions réelles, si.

Ce qui déplace la difficulté vers un problème de détection et de qualification. Comment savez-vous qu’une de vos vulnérabilités est exploitée ? Les sources classiques — remontées support, télémétrie, catalogues publics de vulnérabilités exploitées connues, alertes de vos hébergeurs — existent, mais elles supposent que quelqu’un les surveille et que la qualification soit tracée. Le chronomètre de vingt-quatre heures démarre à la prise de connaissance, notion que vous aurez à documenter en cas de contrôle.

Le point à retenir : la charge nouvelle n’est pas le formulaire, c’est la capacité à dater ce que vous saviez et quand.

La mécanique de notification

Le rythme s’inspire du RGPD, avec une granularité supérieure.

24 heures après la prise de connaissance : alerte précoce à l’ENISA et au CSIRT compétent.

72 heures : notification complète, avec une première évaluation de la gravité et de l’impact.

14 jours après la mise à disposition d’une mesure corrective : rapport final, pour une vulnérabilité activement exploitée.

Un mois après la notification initiale : rapport final, pour un incident grave.

Tout passe par la plateforme unique de signalement opérée par l’ENISA, opérationnelle à la date du 11 septembre. Une seule soumission vaut notification simultanée à l’ENISA et au CSIRT national désigné — en France, le CERT-FR de l’ANSSI. Les informations sont ensuite redistribuées aux centres nationaux de réponse aux incidents concernés.

Le changement de posture est réel : il ne suffit plus de corriger discrètement une faille dans une mise à jour de routine. Il faut la déclarer, la documenter et la tracer auprès des autorités.

Qui est « fabricant », et qui ne l’est pas

C’est la question qui angoisse le plus la communauté open source, et la réponse est plus rassurante que la rumeur.

Le logiciel libre développé et distribué sans finalité commerciale est exempté. Les développeurs individuels ne sont pas considérés comme des fabricants au sens du règlement.

En revanche, un régime spécifique — allégé, mais réel — s’applique aux stewards : les fondations et structures qui soutiennent durablement des projets open source à visée commerciale. Si votre projet est porté par une fondation qui en tire un modèle économique, vous n’êtes pas dans la case « hobbyiste ».

Côté périmètre produit, le texte est large. Un « produit avec éléments numériques » couvre le matériel, le logiciel, et les composants vendus séparément comme les puces ou les systèmes d’exploitation. Un logiciel industriel — SCADA, MES, historisation — est un produit numérique au même titre qu’un automate, et son éditeur est soumis aux mêmes obligations. Certains produits sont classés critiques et suivront un régime renforcé en 2027 : pare-feu, antivirus, gestionnaires de mots de passe, VPN, systèmes de détection d’intrusion.

Quatre situations, quatre priorités

Éditeur SaaS ou logiciel B2B. Vous êtes pleinement dans le périmètre, et l’échéance de septembre est un chantier de processus plus que de technique. Point fort : si vous avez déjà une chaîne DevOps mature — inventaire des composants, surveillance des vulnérabilités, déploiement rapide de correctifs, traçabilité —, l’essentiel est en place et il reste à formaliser la qualification et le circuit de décision. Limite honnête : sans procédure écrite désignant qui qualifie, qui décide et qui notifie, vingt-quatre heures un vendredi soir sont intenables. Idéal si vous démarrez maintenant par un test à blanc du processus de notification.

Fabricant de matériel connecté ou d’équipement industriel. Vos produits ont des cycles de vie longs et un parc installé que vous ne maîtrisez pas entièrement. Point fort : vos obligations de suivi vous poussent à construire l’inventaire de parc que vous auriez dû avoir de toute façon, et qui servira aussi pour décembre 2027. Limite honnête : la chaîne d’approvisionnement logicielle d’un équipement embarque des composants tiers dont vous ne connaissez pas toujours l’état, ce qui rend la détection d’exploitation nettement plus difficile que sur du SaaS. Idéal si vous commencez par cartographier vos dépendances avant de vous préoccuper du formulaire.

Mainteneur ou fondation open source. Votre exposition dépend entièrement du modèle économique du projet, pas de sa popularité. Point fort : un projet purement communautaire, sans finalité commerciale, reste hors périmètre — l’inquiétude qui a circulé dans la communauté était largement disproportionnée. Limite honnête : la frontière entre « sans finalité commerciale » et « steward » n’est pas toujours nette pour les projets adossés à une entreprise ou financés par des sponsors industriels, et c’est une question à trancher explicitement plutôt qu’à supposer. Idéal si vous clarifiez maintenant le statut de votre structure porteuse.

RSSI d’une entreprise utilisatrice. L’obligation ne pèse pas sur vous : c’est votre fournisseur d’automate, de passerelle ou de logiciel qui notifie. Point fort : l’échéance ouvre un flux d’alertes amont sur les failles réellement exploitées chez vos fournisseurs, et fait de la rapidité de signalement un critère contractuel exigible en appel d’offres. Limite honnête : ce flux ne sert à rien sans un inventaire à jour de vos produits numériques en service et de leurs éditeurs. Idéal si vous profitez de septembre pour ajouter une clause de notification à vos contrats en renouvellement.

Ce qu’il faut avoir en place avant le 11 septembre

Quatre éléments, dans cet ordre.

Un inventaire produit. Quels produits vous mettez sur le marché européen, avec quelles versions supportées et quels composants tiers. Sans ce point de départ, rien d’autre ne tient.

Une source de veille sur l’exploitation. Surveillance des catalogues publics de vulnérabilités exploitées, remontées support qualifiées, télémétrie si vous en avez. L’objectif n’est pas l’exhaustivité mais la traçabilité de ce que vous surveillez.

Une procédure de qualification écrite. Qui reçoit l’information, qui décide si le seuil « activement exploitée » est atteint, qui déclenche le compteur, qui rédige. Avec un suppléant, parce que les vulnérabilités ne respectent pas les congés d’août.

Un compte et un test. Créez l’accès à la plateforme ENISA, faites un passage à blanc, mesurez le temps réel entre la détection et la soumission. C’est ce test qui révélera les vrais points de blocage — souvent la validation juridique ou la disponibilité d’un décideur.

Côté sanctions, l’article 64 prévoit des amendes pouvant atteindre 2,5 % du chiffre d’affaires mondial pour non-conformité aux exigences essentielles. Les montants exacts applicables aux manquements de notification varient selon les analyses sectorielles ; la vérification auprès d’un conseil s’impose si vous devez chiffrer le risque en interne.

FAQ

Dois-je notifier toutes les CVE de mon produit ?
Non. L’obligation vise les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit. Une vulnérabilité connue mais non exploitée relève de votre gestion normale des correctifs, pas du signalement réglementaire.

Que se passe-t-il si je découvre l’exploitation un vendredi soir ?
Le délai de vingt-quatre heures court à partir de la prise de connaissance, week-end compris. C’est précisément pourquoi la procédure doit désigner un suppléant et prévoir un canal d’alerte hors heures ouvrées. L’absence de ressources disponibles n’est pas un motif recevable.

Mon produit est vendu uniquement en France, suis-je concerné ?
Oui. Le règlement s’applique aux produits mis sur le marché de l’Union, ce qui inclut le marché national. La notification passe par la plateforme ENISA, avec transmission simultanée au CERT-FR.

Le CRA remplace-t-il NIS2 ?
Non, les deux se complètent et visent des acteurs différents. Le CRA porte sur la sécurité des produits et pèse sur leurs fabricants ; NIS2 porte sur la sécurité des organisations et pèse sur les entités des secteurs concernés. Une même entreprise peut relever des deux à des titres distincts.

Ce qu’il faut retenir

Le 11 septembre n’est pas l’entrée en vigueur du Cyber Resilience Act — c’est l’entrée en vigueur de son obligation la plus opérationnelle et la plus sous-estimée. Le gros du texte, avec ses exigences de sécurité et son marquage CE, arrive en décembre 2027.

Mais l’obligation de notification a une caractéristique désagréable : elle ne se rattrape pas. Une exigence documentaire manquée en 2027 se corrige ; un signalement non fait dans les vingt-quatre heures est constaté et daté.

Si vous éditez du logiciel ou fabriquez du matériel connecté, la seule chose vraiment urgente est la procédure interne — qui qualifie, qui décide, qui notifie, et avec quel suppléant. Testez-la avant septembre plutôt que pendant votre premier incident.

Cet article est un guide de vulgarisation et ne constitue pas un conseil juridique. Pour évaluer votre exposition, rapprochez-vous d’un conseil spécialisé.

Le calendrier du CRA s’entrelace avec NIS2, DORA et l’AI Act, avec des jalons qui se succèdent jusqu’en 2028. C’est ce que nous suivons chez Savvys : une veille tech quotidienne curée pour les CTO, RSSI et éditeurs qui doivent tenir plusieurs calendriers réglementaires à la fois.

Abonnez-vous à la veille du vendredi : 5 actus essentielles, 1 coup de cœur, 0 spam.

Sources principales : Cyber Resilience Act (article 14, article 64), ENISA, ANSSI/CERT-FR, L’Usine Digitale, IT Social, InformatiqueNews, Coditrust, Intrinsec. Données arrêtées au 9 août 2026.