Le Cyber Resilience Act ne commencera pas d’un seul bloc en décembre 2027. Son article 14 crée une échéance beaucoup plus proche : à partir du 11 septembre 2026, les fabricants devront signaler les vulnérabilités activement exploitées et les incidents graves ayant des répercussions sur la sécurité de leurs produits comportant des éléments numériques.
Cette obligation ne vise ni toute vulnérabilité découverte, ni tout incident observé. Elle impose de qualifier un produit, un événement et un moment de prise de connaissance, puis d’enrichir le signalement selon plusieurs échéances. Une organisation qui attend septembre pour identifier ses produits, ses responsables et ses sources de preuve risque donc de perdre du temps avant même d’avoir commencé l’analyse technique.
Conclusion courte : le premier signalement peut intervenir avant que l’enquête soit complète. La préparation utile consiste à savoir ce qui est établi, ce qui reste à confirmer et qui peut décider, notifier et informer les utilisateurs dans les délais.
Trois dates, trois objets différents
Le règlement (UE) 2024/2847 est entré en vigueur le 10 décembre 2024. Son calendrier d’application distingue ensuite trois étapes :
- les articles 35 à 51, relatifs notamment aux organismes d’évaluation de la conformité, s’appliquent depuis le 11 juin 2026 ;
- l’article 14, consacré aux signalements obligatoires des fabricants, s’applique à partir du 11 septembre 2026 ;
- la plupart des autres dispositions, dont les exigences essentielles de cybersécurité et les obligations générales de conformité des fabricants, s’appliqueront à partir du 11 décembre 2027.
Cette chronologie empêche un raccourci fréquent : septembre 2026 n’est pas la date d’application générale de tout le CRA. C’est la date d’entrée en application des signalements prévus par l’article 14.
Quels produits et quels acteurs sont concernés ?
Le CRA définit un produit comportant des éléments numériques comme un produit logiciel ou matériel et ses solutions de traitement de données à distance, y compris les composants logiciels ou matériels mis sur le marché séparément. Selon l’article 2, son utilisation prévue ou raisonnablement prévisible doit comprendre une connexion directe ou indirecte, logique ou physique, à un dispositif ou à un réseau.
La FAQ de la Commission, version 1.3, propose trois questions cumulatives :
- s’agit-il d’un produit comportant des éléments numériques au sens du règlement ?
- est-il mis à disposition sur le marché de l’Union ?
- son utilisation prévue ou raisonnablement prévisible comprend-elle la connexion définie par le règlement ?
Le périmètre ne peut donc pas être déduit du seul mot « logiciel », « cloud » ou « objet connecté ». La Commission précise notamment qu’un service SaaS autonome, conçu hors de la responsabilité du fabricant d’un produit, n’est pas en lui-même un produit comportant des éléments numériques. Il peut toutefois relever du CRA lorsqu’il constitue une solution de traitement de données à distance conçue sous la responsabilité du fabricant et dont l’absence empêcherait le produit d’exécuter une de ses fonctions.
Le règlement prévoit aussi des exclusions sectorielles, notamment pour certains dispositifs médicaux, dispositifs médicaux de diagnostic in vitro, véhicules, produits certifiés dans le cadre de l’aviation civile et équipements marins. La qualification doit être conduite depuis l’article 2 et les textes sectoriels concernés, pas depuis une liste commerciale simplifiée.
Les produits anciens ne sont pas automatiquement hors jeu
L’article 69, paragraphe 3, rend l’article 14 applicable aux produits relevant du champ du CRA qui ont été mis sur le marché avant le 11 décembre 2027. La FAQ de la Commission confirme que les signalements commencent le 11 septembre 2026 pour ces produits également.
Pour un ancien produit, le fabricant peut ne plus disposer de l’environnement de construction, des outils ou des compétences permettant une investigation complète. La Commission indique que l’obligation de signalement demeure, même si les autres obligations de gestion des vulnérabilités du CRA ne s’appliquent pas encore à ce produit. Ce décalage rend l’inventaire des versions anciennes particulièrement important.
La FAQ de l’ENISA précise toutefois que l’obligation ne s’étend pas à une vulnérabilité dont le fabricant connaissait déjà l’exploitation active avant l’entrée en application des signalements. Cette précision porte sur le moment de la prise de connaissance, pas sur l’âge du produit. Le dossier doit donc conserver la date et la substance du premier signal fiable au lieu de déduire la réponse de la seule date de commercialisation.
Le déclarant n’est pas toujours le fabricant d’origine
Le fabricant porte l’obligation principale. Mais les articles 21 et 22 prévoient aussi qu’un importateur, un distributeur ou une autre personne peut être considéré comme fabricant lorsqu’il met le produit sur le marché sous son propre nom ou sa propre marque, ou lorsqu’il réalise une modification substantielle puis remet le produit à disposition sur le marché.
Les intendants de logiciels ouverts relèvent d’un régime spécifique. L’article 24 leur applique le signalement des vulnérabilités activement exploitées dans la mesure où ils participent au développement des produits concernés. Le signalement des incidents graves et l’information des utilisateurs leur sont applicables lorsque ces incidents touchent les réseaux et systèmes d’information qu’ils fournissent pour le développement de ces produits.
Cette situation ne doit pas être confondue avec l’exclusion prévue à l’article 2, paragraphe 3, pour les logiciels libres et ouverts développés ou fournis hors du cadre d’une activité commerciale. Le considérant 18 précise que le mode de financement du développement ne suffit pas, à lui seul, à déterminer la nature commerciale de l’activité et que la fourniture d’un produit libre et ouvert non monétisé par son fabricant ne devrait pas être considérée comme une activité commerciale.
Quels événements doivent être signalés ?
L’article 14 sépare deux branches : la vulnérabilité activement exploitée et l’incident grave ayant des répercussions sur la sécurité du produit. Une vulnérabilité connue, une preuve de concept publique ou un incident affectant un utilisateur ne franchissent pas automatiquement ces seuils.
Une vulnérabilité doit être activement exploitée
L’article 3 définit la vulnérabilité activement exploitée comme une vulnérabilité pour laquelle il existe des éléments de preuve fiables montrant qu’un acteur malveillant l’a exploitée dans un système sans l’autorisation du propriétaire.
La FAQ de la Commission en déduit deux distinctions importantes :
- une vulnérabilité zero-day est soumise au signalement obligatoire s’il existe une preuve fiable de son exploitation malveillante ;
- une vulnérabilité découverte de bonne foi par un chercheur, un programme de bug bounty ou un laboratoire, sans preuve d’exploitation malveillante, n’est pas une vulnérabilité activement exploitée au sens de l’article 14. Elle peut faire l’objet d’un signalement volontaire au titre de l’article 15.
La preuve attendue n’est donc pas seulement celle de l’existence d’une faille. Elle doit relier cette faille à une exploitation malveillante réelle.
Un composant tiers ne transfère pas automatiquement l’analyse
Lorsqu’une vulnérabilité activement exploitée provient d’un composant intégré, le fabricant du produit qui l’intègre doit la signaler si elle est contenue et exploitable dans son produit. Le fabricant du composant doit également la signaler si ce composant a été mis sur le marché séparément.
À l’inverse, la Commission précise que si le fabricant sait qu’un composant contient une vulnérabilité mais établit qu’elle ne peut pas être exploitée dans son produit, cette vulnérabilité n’est pas activement exploitée dans ce produit et n’est pas soumise au signalement obligatoire pour celui-ci. La conclusion exige cependant une analyse documentée, pas une simple absence d’alerte dans un outil de composition logicielle.
Un incident doit franchir le seuil de gravité du CRA
Selon l’article 14, paragraphe 5, un incident ayant des répercussions sur la sécurité du produit est grave lorsqu’au moins une des conditions suivantes est remplie :
- il entache ou est susceptible d’entacher la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou de fonctions sensibles ou importantes ;
- il a conduit ou est susceptible de conduire à l’introduction ou à l’exécution d’un code malveillant dans le produit ou dans le réseau et les systèmes d’information d’un utilisateur du produit.
Le texte ne conditionne pas ce seuil à un nombre minimal d’utilisateurs, à une durée d’indisponibilité uniforme ou à un montant de perte. Une organisation qui ajoute ses propres seuils de tri doit donc veiller à ne pas neutraliser les deux critères juridiques.
24 heures, 72 heures, puis un rapport final
Les deux branches suivent la même première cadence, mais leur rapport final n’a ni la même échéance ni le même contenu. Tous les délais sont formulés « sans retard injustifié » avec une limite maximale. Le plafond de 24 ou 72 heures ne doit donc pas être interprété comme un délai d’attente automatique.
| Étape | Vulnérabilité activement exploitée | Incident grave |
|---|---|---|
| Alerte précoce | Au plus tard 24 heures après la prise de connaissance. Indiquer, le cas échéant, les États membres où le produit a été mis à disposition. | Au plus tard 24 heures après la prise de connaissance. Indiquer au minimum si des actes illicites ou malveillants sont suspectés et, le cas échéant, les États membres concernés. |
| Notification | Au plus tard 72 heures après la prise de connaissance. Donner les informations disponibles sur le produit, la nature générale de l’exploitation et de la vulnérabilité, ainsi que les mesures prises et celles accessibles aux utilisateurs. | Au plus tard 72 heures après la prise de connaissance. Donner la nature de l’incident, son évaluation initiale, les mesures prises et celles accessibles aux utilisateurs. |
| Rapport final | Au plus tard 14 jours après la mise à disposition d’une mesure corrective ou d’atténuation. Décrire la vulnérabilité, sa gravité, ses répercussions, l’acteur malveillant lorsqu’il est connu et la mesure disponible. | Dans un délai d’un mois à compter de la notification à 72 heures. Décrire l’incident, sa gravité, ses répercussions, la menace ou la cause profonde probable et les mesures d’atténuation. |
Le CSIRT désigné comme coordinateur peut demander un rapport intermédiaire de situation. L’article 14, paragraphe 8, impose aussi au fabricant d’informer les utilisateurs touchés et, lorsque cela est approprié, tous les utilisateurs de la vulnérabilité ou de l’incident ainsi que des mesures qu’ils peuvent prendre. Le texte ne fixe pas pour cette information un délai chiffré identique aux trois rapports, mais permet aux CSIRT d’informer les utilisateurs si le fabricant ne le fait pas en temps utile et si cette communication est proportionnée et nécessaire.
L’alerte de 24 heures n’est pas un rapport forensique complet
La FAQ SRP de l’ENISA, mise à jour le 17 juillet 2026, distingue les champs obligatoires, conditionnels et facultatifs à chaque étape. À 24 heures, le type de notification, le niveau, le nom du fabricant ou de l’intendant de logiciel ouvert, le produit et un titre sont notamment obligatoires. Un identifiant CVE ou EUVD est facultatif à ce stade.
À 72 heures, la nature générale de la vulnérabilité et de son exploitation, ou la nature et l’évaluation initiale de l’incident, deviennent obligatoires. Les mesures déjà prises et celles proposées aux utilisateurs doivent aussi être renseignées. Le détail complet de la vulnérabilité ou de l’incident est réservé au rapport final.
Cette progression confirme une règle opérationnelle : une information encore inconnue doit rester identifiée comme telle. Elle ne doit pas être remplacée par une estimation présentée comme un fait.
Où va le signalement ?
Le fabricant utilise la plateforme unique de signalement, ou SRP, établie et administrée par l’ENISA. Le signalement passe par le point final du CSIRT désigné comme coordinateur et est simultanément mis à la disposition de l’ENISA. Le CSIRT initial diffuse ensuite la notification aux CSIRT des États membres dans lesquels le fabricant a indiqué que le produit avait été mis à disposition.
Le règlement situe l’établissement principal dans l’État membre où sont principalement prises les décisions relatives à la cybersécurité des produits. Si cet État ne peut pas être déterminé, il retient l’établissement qui compte le plus grand nombre de salariés dans l’Union. Pour un fabricant qui n’est pas établi dans l’Union, l’article 14, paragraphe 7, prévoit notamment de considérer l’établissement du mandataire. Cette qualification doit être faite sur la personne morale qui porte le produit, pas seulement sur le lieu où se trouve l’équipe de sécurité.
Déclarer une information sensible ne donne pas un droit de veto
Le fabricant peut indiquer le degré de sensibilité attribué aux informations notifiées. Dans des circonstances exceptionnelles, le CSIRT initial peut décider de retarder leur diffusion pendant la durée strictement nécessaire.
Le règlement délégué (UE) 2026/881 encadre ce report. Il peut notamment intervenir lorsque les risques de cybersécurité liés à la diffusion l’emportent sur ses bénéfices et ne peuvent pas être suffisamment réduits par des protocoles comme TLP ou PAP. Le texte prévoit des cas liés à la disponibilité prochaine d’une mesure efficace, au risque de faciliter la création d’une technique d’exploitation, à la possibilité de ne partager temporairement que les informations nécessaires à l’atténuation ou à une divulgation coordonnée de vulnérabilité.
La décision appartient au CSIRT. Une classification de sensibilité émise par le fabricant constitue une information à examiner, pas une garantie que le rapport restera limité à son destinataire initial. Le règlement délégué précise en outre que l’accès de l’ENISA ne peut être restreint que dans des circonstances particulièrement exceptionnelles, pour l’une des trois conditions de l’article 16, paragraphe 2, et uniquement pour la notification à 72 heures d’une vulnérabilité activement exploitée. Même dans ce cas, un socle d’informations reste transmis simultanément à l’ENISA.
Le dossier de preuve à préparer avant septembre
La grille suivante est une proposition opérationnelle BLACKPROOF. Elle ne remplace ni le formulaire SRP, ni une analyse juridique. Elle vise à conserver les éléments qui permettent de comprendre et de réviser la décision de signaler.
| Bloc | Éléments à conserver | Question à laquelle ils répondent |
|---|---|---|
| Produit | Personne morale fabricante, nom du produit, versions, composants, traitement à distance, pays de mise à disposition | Quel produit et quel acteur relèvent du CRA ? |
| Prise de connaissance | Signal d’origine, contenu original, date et heure, destinataire interne, première qualification | À quel moment le délai a-t-il commencé ? |
| Exploitation | Indicateurs, télémétrie, rapport client, avis d’autorité ou recherche, lien entre la faille et l’exploitation | Existe-t-il une preuve fiable d’exploitation malveillante ? |
| Gravité | Données ou fonctions touchées, effets observés ou possibles, présence ou risque de code malveillant | L’incident franchit-il un des critères de l’article 14, paragraphe 5 ? |
| Décision | Faits établis, hypothèses, inconnues, responsable, heure, motif et niveau de confiance | Pourquoi signaler, ne pas signaler ou réexaminer ? |
| Notification | Copie de chaque version, identifiant, accusé de réception, auteur, heure, champs modifiés | Que contenait le signalement à chaque échéance ? |
| Utilisateurs | Population concernée, message, canal, date, mesures proposées et limites | Qui a été informé et sur quelle base ? |
| Correction | Correctif ou atténuation, date de disponibilité, versions visées, validation et restrictions | Quelle mesure ferme ou réduit le risque ? |
Cette structure rejoint la bibliothèque de preuves et les indicateurs de dette de preuve de BLACKPROOF. Un document isolé n’établit pas une conclusion s’il n’est pas relié au bon produit, à la bonne version, à une source et au moment où la décision a été prise.
Incertitudes au 20 juillet 2026
La base juridique du signalement est établie. Plusieurs modalités opérationnelles restent toutefois en cours de finalisation :
- l’ENISA indique que la SRP sera opérationnelle au 11 septembre 2026, mais l’adresse publique dédiée n’est pas encore publiée ;
- les représentants utiliseront un compte EU Login. La validation de leur capacité à agir pour un fabricant sera réalisée par le CSIRT après le premier accès, en parallèle du signalement, sans bloquer la possibilité de notifier ;
- l’ENISA indique qu’aucune API ne sera fournie à ce stade, même si une organisation peut automatiser son propre workflow interne ;
- la liste des CSIRT désignés comme coordinateurs doit encore être fournie sur la page de l’ENISA ;
- la FAQ de la Commission est un document de travail vivant et non une interprétation juridiquement contraignante. Les orientations finales prévues par l’article 26 sont encore annoncées comme à venir.
Ces inconnues ne bloquent pas la préparation. Elles imposent de séparer ce qui peut être construit dès maintenant de ce qui devra être vérifié à l’ouverture du service.
Huit contrôles à réaliser avant l’ouverture de la plateforme
- Recenser les produits et versions. Inclure les produits anciens encore concernés par l’article 14.
- Identifier la personne morale fabricante. Vérifier les cas de marque propre, d’importation et de modification substantielle.
- Désigner le décideur de qualification. Il doit pouvoir statuer de jour comme de nuit avec les équipes produit, sécurité et juridique.
- Conserver l’heure de prise de connaissance. Le premier ticket interne n’est pas toujours le premier signal reçu par l’organisation.
- Tester les deux critères. Exploitation malveillante fiable pour une vulnérabilité, critères de gravité de l’article 14 pour un incident.
- Préparer les champs de 24 et 72 heures. Ne pas attendre un incident pour découvrir les identifiants de produit, pays et responsables.
- Organiser l’information des utilisateurs. Définir les canaux, validations et moyens d’adresser les versions réellement touchées.
- Archiver chaque version. Conserver le contenu envoyé, l’heure, l’auteur, l’accusé de réception et les corrections ultérieures.
Le même événement peut aussi nécessiter une analyse au titre de NIS 2, de la protection des données, d’un contrat ou d’un régime sectoriel. Les critères et destinataires ne doivent pas être fusionnés par commodité. Notre analyse NIS 2 et notre méthode de qualification des fuites de données permettent de traiter séparément ces branches.
Limites de l’analyse
- « Toute CVE doit être signalée. » Le signalement obligatoire exige une vulnérabilité activement exploitée contenue dans le produit.
- « Toute zero-day doit être signalée. » Sans preuve fiable d’exploitation malveillante, la seule absence de correctif ne suffit pas.
- « Les produits vendus avant 2027 sont exclus. » L’article 14 s’applique aussi aux produits antérieurs qui relèvent du champ du CRA.
- « Une notification classée sensible restera chez un seul CSIRT. » Le report de diffusion est une décision encadrée du CSIRT, pas un choix unilatéral du fabricant.
- « Les petites entreprises sont dispensées. » Le règlement écarte les amendes administratives pour les microentreprises et petites entreprises en cas de non-respect de la seule échéance d’alerte à 24 heures. Il ne supprime ni l’obligation de signaler, ni les autres obligations applicables.
- « Le rapport de 24 heures doit contenir la cause profonde. » Il s’agit d’une alerte précoce. L’analyse est enrichie à 72 heures puis dans le rapport final.
- « Le formulaire établira la conformité. » Une plateforme transmet des informations. Elle ne qualifie pas à la place du fabricant son produit, les faits ou la fiabilité des preuves.
La bonne préparation ne consiste pas à fabriquer une certitude avant l’enquête. Elle consiste à rendre la décision suffisamment explicite pour être transmise dans les délais, vérifiée après coup et corrigée lorsque de nouveaux éléments apparaissent. La méthode BLACKPROOF peut structurer ce dossier, mais elle ne remplace ni l’interprétation du règlement par les autorités et les juridictions compétentes, ni un conseil juridique adapté au produit et à l’organisation.