Cyber Resilience Act : votre échéance de divulgation de septembre 2026

À partir du 11 septembre 2026, le Cyber Resilience Act de l’UE impose aux fabricants de produits comportant des éléments numériques de signaler les vulnérabilités activement exploitées à leur CSIRT national et à l’ENISA selon un calendrier en trois temps : une alerte précoce sous 24 heures, une notification complète sous 72 heures, puis un rapport final dans les 14 jours suivant la disponibilité d’un correctif. En parallèle, le règlement exige une politique de divulgation coordonnée des vulnérabilités (CVD) assortie d’un point de contact public, afin que les chercheurs puissent signaler les failles directement. En cas de manquement, les amendes atteignent 15 000 000 € ou 2,5 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu.

Si vous distribuez des logiciels dans l’UE, le mot « fabricant » vous concerne presque à coup sûr, l’échéance est plus proche que vous ne le pensez, et « nous n’avons pas encore de processus pour ça » n’est plus une réponse défendable. Voici ce que la loi exige réellement, les deux échéances que tout le monde confond, et la couche opérationnelle minimale dont une petite équipe a besoin pour être prête.

Le compte à rebours dont vous ignoriez le départ : le 11 septembre 2026

La date à retenir est le 11 septembre 2026, jour où l’obligation de signalement du CRA entre en application. À compter de cette date, les fabricants doivent signaler les vulnérabilités activement exploitées et les incidents graves via la plateforme unique de signalement de l’ENISA. C’est la première échéance substantielle du règlement (UE) 2024/2847, avant le reste du texte, et c’est celle qui risque le plus de prendre les petits éditeurs au dépourvu.

La plupart des analyses du CRA visent les fabricants de matériel d’entreprise et les grandes équipes de sécurité produit : SBOM, marquage CE, évaluation de la conformité. Ce cadrage a convaincu beaucoup de fondateurs que le CRA était le problème de quelqu’un d’autre. Ce n’est pas le cas. Le compte à rebours du signalement démarre le même jour pour toutes les entités concernées, et une entreprise SaaS de 20 personnes proposant un agent téléchargeable est tout aussi liée qu’un fabricant d’appareils.

La conséquence pratique est inconfortable. Si une vulnérabilité de votre produit est activement exploitée la semaine qui suit l’échéance, vous avez 24 heures pour déposer une alerte précoce. Si vous n’avez ni point d’entrée, ni triage, ni la moindre idée de qui, dans votre entreprise, est responsable de ce dépôt, vous le découvrirez sous la pire pression temporelle possible.

Êtes-vous « fabricant d’un produit comportant des éléments numériques » ?

Vous l’êtes probablement. Le CRA définit un produit comportant des éléments numériques comme, en substance, tout logiciel ou matériel qui se connecte à un appareil ou à un réseau, et il fait peser les obligations principales sur le fabricant, terme qui englobe explicitement les développeurs de logiciels qui commercialisent un produit.

Cela ratisse bien plus large que les gadgets connectés. Demandez-vous si l’une de ces descriptions vous correspond :

• Un produit SaaS doté d’une application de bureau téléchargeable, d’une extension de navigateur ou d’un agent local.
• Un appareil connecté ou tout matériel équipé d’un micrologiciel.
• Une bibliothèque logicielle commerciale, un SDK ou un produit auto-hébergé vendu ou concédé sous licence dans l’UE.
• Un fondateur ou mainteneur indépendant qui assure un support commercial sur un logiciel utilisé dans l’UE.

Les importateurs et distributeurs ont des obligations allégées, mais si vous concevez et vendez le produit, vous êtes le fabricant. La nuance liée à l’open source compte ici aussi : l’open source purement non commercial échappe généralement aux obligations du fabricant, mais dès l’instant où vous le monétisez (support payant, édition commerciale, version hébergée), vous entrez dans le champ d’application.

Le CRA n’est pas un terrain où l’on peut faire l’impasse sur le conseil juridique. Si vous n’êtes pas certain qu’un produit précis relève du champ d’application, c’est un sujet à aborder avec un avocat. Mais l’hypothèse par défaut pour une entreprise logicielle qui vend dans l’UE devrait être « concerné jusqu’à preuve du contraire », et non l’inverse.

Ce que le CRA exige réellement en matière de divulgation des vulnérabilités

Le Cyber Resilience Act de l’UE impose aux fabricants de mettre en place une politique de divulgation coordonnée des vulnérabilités assortie d’un point de contact public, et, à partir du 11 septembre 2026, de signaler les vulnérabilités activement exploitées à leur CSIRT et à l’ENISA sous 24 heures (alerte précoce), 72 heures (notification complète) et 14 jours (rapport final après la disponibilité d’un correctif). Deux obligations distinctes se cachent derrière ce résumé, et elles proviennent de deux articles différents.

La politique CVD et le point de contact (article 13). L’article 13, paragraphe 8, impose aux fabricants de « disposer de politiques et de procédures appropriées, y compris des politiques de divulgation coordonnée des vulnérabilités […] pour traiter et corriger les vulnérabilités potentielles […] signalées par des sources internes ou externes ». L’article 13, paragraphe 17, exige un point de contact unique, afin que quiconque, y compris les chercheurs en sécurité, puisse signaler une vulnérabilité directement. Point essentiel : il doit laisser le déclarant choisir son canal de communication ; vous ne pouvez pas contraindre tout le monde à passer par un unique outil automatisé.

L’obligation de signalement (article 14). C’est le compte à rebours 24 / 72 / 14 vers les régulateurs, et c’est là que se trouvent les échéances à heure fixe.

Un mythe mérite d’être déboulonné ici. Plusieurs blogs d’éditeurs affirment que le CRA impose un délai de 48 heures pour accuser réception du rapport d’un chercheur. C’est faux. Le texte de l’article 13 ne contient aucun délai d’accusé de réception fixé en heures. Les seuls comptes à rebours à heure fixe du règlement sont ceux du signalement aux régulateurs, au titre de l’article 14. Considérez un SLA d’accusé de réception comme une bonne pratique que votre politique devrait définir, et non comme un chiffre à attribuer à la loi.

La cadence de signalement 24 / 72 / 14, et ses éléments déclencheurs

Pour une vulnérabilité activement exploitée ou un incident grave, la cadence de signalement suit un compte à rebours en trois temps, tous mesurés à partir du moment où vous en prenez connaissance :

Vous ne déposez qu’une seule fois. La plateforme unique de signalement, créée, gérée et exploitée par l’ENISA, achemine votre notification simultanément vers le CSIRT désigné comme coordinateur dans l’État membre de votre établissement principal et vers l’ENISA. Ce CSIRT destinataire la diffuse ensuite sans délai aux autres CSIRT nationaux concernés. La plateforme accepte également les signalements volontaires de vulnérabilités, de menaces, d’incidents et de quasi-incidents, émanant de quiconque.

Le déclencheur est étroit, et le viser juste compte tout autant que les délais. Le compte à rebours de 24 heures ne démarre que pour une vulnérabilité activement exploitée, c’est-à-dire lorsqu’il existe des preuves fiables qu’un acteur malveillant l’a exploitée, ou pour un incident grave, c’est-à-dire un impact grave sur la disponibilité, l’authenticité, l’intégrité ou la confidentialité du produit. Toutes les failles signalées par un chercheur ne déclenchent pas le compte à rebours réglementaire. La plupart ne le feront pas. Mais vous ne pouvez faire la différence sans une étape de triage capable de classer rapidement ce qui vient d’atterrir dans votre boîte de réception, ce qui explique précisément pourquoi un pipeline opérationnel allant de la réception au triage est le cœur de la préparation au CRA.

Les deux échéances que les gens confondent : 2026 contre 2027

Une grande partie des analyses secondaires fond deux dates en une seule, et cette confusion crée un faux sentiment de sécurité. Gardez-les bien distinctes :

• 11 septembre 2026 — l’obligation de signalement (article 14) s’applique. Le compte à rebours 24 / 72 / 14 vers l’ENISA et votre CSIRT est en vigueur.
• 11 décembre 2027 — la date d’application principale du CRA, à laquelle les obligations permanentes du fabricant, y compris la politique CVD de l’article 13 et le point de contact unique, s’appliquent aux produits mis sur le marché.

Il est tentant de lire la date de 2027 et d’en conclure que vous disposez de dix-huit mois de répit. Ce n’est pas le cas. Le compte à rebours du signalement démarre en 2026, et vous ne pouvez pas tenir une obligation de signalement de 24 heures sans avoir déjà en place la réception, le triage et la répartition des responsabilités que décrit la politique CVD. L’obligation de 2027 formalise le processus ; l’obligation de 2026 présuppose que vous savez déjà le faire tourner. Concrètement, cela signifie que l’infrastructure de divulgation doit exister dès cette année.

Ce que doit contenir un flux CVD conforme

En croisant le texte du règlement avec les recommandations des praticiens, dont les conseils de HackerOne sur la préparation au CRA, un flux de divulgation coordonnée défendable comporte six éléments :

1. Une réception publique et documentée. Un point de contact unique, en pratique un fichier security.txt conforme à la RFC 9116 accompagné d’une page de politique publiée, afin qu’un chercheur qui découvre une faille sache exactement où l’envoyer.
2. Un périmètre déclaré. Quels produits et versions sont couverts, ce qui est explicitement hors périmètre, et quelles catégories de vulnérabilités vous n’acceptez pas.
3. Le triage et la validation. L’étape qui détermine si un rapport correspond à une vulnérabilité activement exploitée ou à un incident grave, le déclencheur du compte à rebours de 24 heures.
4. La coordination avec le déclarant. Un véritable canal de dialogue avec le chercheur avant toute divulgation publique.
5. La correction sans retard indu et un avis de sécurité public une fois le correctif déployé.
6. Des traces auditables. Une responsabilité traçable et une chronologie que vous pouvez remettre à une autorité de surveillance du marché sur demande.

Ce dernier point est celui que les équipes négligent et regrettent. « Nous avons coordonné de façon responsable » est une affirmation. Une chronologie horodatée montrant quand le rapport est arrivé, quand il a été trié, quand le déclarant a été tenu informé et quand le correctif a été déployé, c’est une preuve. Sous un règlement aux amendes indexées sur le chiffre d’affaires, la différence entre une affirmation et une preuve fait toute la partie.

Le prix de l’erreur

Le non-respect des exigences essentielles et des obligations des articles 13 et 14 est passible d’amendes administratives pouvant atteindre 15 000 000 € ou 2,5 % du chiffre d’affaires annuel mondial total de l’exercice précédent, le montant le plus élevé étant retenu. Deux paliers inférieurs s’ajoutent en dessous :

La formule « le montant le plus élevé étant retenu » est la partie que les fondateurs sous-estiment. Pour une petite entreprise, les montants absolus en euros ressemblent à des problèmes de grand groupe, mais les paliers en pourcentage diminuent en proportion de votre taille, et la structure du règlement fait que les défaillances de processus (absence de politique CVD, un signalement manqué, un dépôt trompeur) sont précisément celles qui coûtent peu à prévenir et cher à ignorer.

Construire un processus de divulgation coordonnée prêt pour le CRA avec Kit

Le CRA fait passer la divulgation coordonnée des vulnérabilités du statut de bonus de maturité à celui d’obligation légale assortie d’une date butoir et d’un risque indexé sur le chiffre d’affaires. Pour la plupart des fondateurs, l’écart est opérationnel, pas philosophique : il vous faut une réception, un processus de triage, un compte à rebours SLA, un canal de coordination et une piste d’audit, et il vous les faut avant septembre. Monter tout cela de zéro sous la pression de l’échéance, voilà le piège. La verticale CSIRT de Kit est précisément cette couche opérationnelle, et elle correspond presque point par point à ce que demande le règlement.

• Réception VDP publique. Un portail de sécurité en ligne, accompagné d’un fichier security.txt (RFC 9116) généré (avec les champs contact, politique, remerciements et chiffrement), vous fournit le point de contact unique de l’article 13, paragraphe 17, et la politique CVD publiée en une seule opération. C’est la même base que celle que nous avons abordée dans comment mettre en place un programme de divulgation des vulnérabilités, désormais avec une échéance légale à la clé.
• Validation du périmètre. Un périmètre configurable (cibles incluses, catégories exclues, types de vulnérabilités non acceptés), assorti d’une vérification automatique du périmètre à la réception, vous donne la politique documentée qu’exige le texte et la base nécessaire pour valider les rapports au fil de leur arrivée.
• Triage de la sévérité. La suggestion de sévérité intégrée, l’évaluation et la détection des doublons constituent l’étape de triage qui identifie une vulnérabilité activement exploitée ou un incident grave, le déclencheur précis du compte à rebours réglementaire.
• Suivi des SLA. Un minuteur en temps réel avec des objectifs fondés sur la sévérité et des indicateurs de conformité vous donne le compte à rebours et la preuve que vous l’avez respecté. Les SLA d’accusé de réception et de résolution par défaut de Kit reprennent délibérément la cadence des régulateurs, tout en restant des bonnes pratiques, et non des chiffres d’accusé de réception imposés par la loi.
• Coordination avec les chercheurs. La messagerie par fil de discussion conserve, en un seul endroit auditable, le dialogue coordonné et pré-public que le texte appelle de ses vœux.
• Chronologie de rapport auditable. Une chronologie exportable transforme le « nous avons coordonné de façon responsable » en la trace traçable qu’une autorité de surveillance du marché peut réclamer.

Le cadrage honnête est important. Kit rend opérationnelle la couche de divulgation, de coordination et de tenue des registres. Ce n’est pas un conseil juridique, il ne dépose pas à votre place sur la plateforme unique de signalement, et il ne couvre pas les obligations du CRA en matière de sécurité produit et de conformité, comme les SBOM et le marquage CE. Pour celles-ci, adressez-vous à un avocat. Ce que Kit vous apporte, c’est la colonne vertébrale CVD : le processus opérationnel qui fait que, lorsqu’un chercheur découvre une faille, ou qu’une vulnérabilité se révèle exploitée, vous pouvez la réceptionner, la trier, la coordonner et produire la chronologie, au lieu de découvrir le 11 septembre 2026 que vous n’avez aucun processus, le jour même où un compte à rebours réglementaire démarre.

La divulgation coordonnée a toujours été la bonne chose à faire envers les chercheurs qui découvrent vos failles. Le CRA en a simplement fait la chose défendable à faire pour votre entreprise. Le flux qui fait de vous un acteur vertueux vis-à-vis des chercheurs est le même que celui qui vous rend conforme, et le moment le moins coûteux pour le construire, c’est avant l’échéance, pas après la première faille exploitée. Démarrez votre essai gratuit et mettez en place un processus de divulgation prêt pour le CRA tant qu’il reste de la marge au compteur.