Depuis le 11 septembre 2026, une horloge tourne pour chaque éditeur de logiciel, chaque fabricant de matériel connecté et chaque société qui vend un portefeuille crypto en Europe. L’article 14 du Cyber Resilience Act, le règlement européen (UE) 2024/2847, impose désormais un signalement des vulnérabilités activement exploitées en 24 heures. Le texte touche directement les produits qui reposent sur des primitives cryptographiques comme TLS 1.3, RSA, AES-256, Argon2 ou HMAC, ainsi que les systèmes à preuve à divulgation nulle de connaissance utilisés dans certains portefeuilles numériques. Huit jours après l’entrée en application de cette obligation, les premiers cabinets d’avocats et organismes de cybersécurité publient leurs premières analyses, et l’industrie découvre ce que signifie vraiment l’expression sans délai injustifié.
Le compte à rebours qui a démarré le 11 septembre 2026
Le règlement (UE) 2024/2847, adopté fin 2024, prévoit une entrée en application échelonnée sur plusieurs années. La première échéance concernait la désignation des organismes d’évaluation de la conformité, entrée en vigueur le 11 juin 2026. La deuxième, plus lourde de conséquences pour les équipes techniques, touche l’article 14 : elle est arrivée le 11 septembre 2026 et couvre le signalement des vulnérabilités activement exploitées et des incidents graves affectant la sécurité des produits comportant des éléments numériques. La troisième et dernière échéance, celle des exigences de sécurité dites by design prévues à l’annexe I, n’entrera en application que le 11 décembre 2027.
Ce séquençage en trois temps explique pourquoi septembre 2026 marque un tournant sans que le texte soit encore pleinement opérationnel. Les fabricants doivent déjà signaler leurs incidents, mais ils ont encore quinze mois pour mettre leurs produits en conformité avec les exigences techniques de fond. Le texte complet est consultable sur EUR-Lex.
Ce que change concrètement l’article 14 du Cyber Resilience Act
L’article 14 crée une obligation à double détente. D’un côté, tout fabricant doit signaler une vulnérabilité activement exploitée dans son produit dès qu’il en prend connaissance. De l’autre, il doit signaler tout incident grave ayant un impact sur la sécurité du produit, qu’il s’agisse d’une compromission de portefeuille, d’une rupture de confidentialité TLS ou d’un défaut d’implémentation dans une bibliothèque de hachage. Le point de départ du chronomètre n’est pas fixé par un tiers. C’est le fabricant lui-même qui doit apprécier à quel moment il considère avoir pris connaissance du problème, une notion qui suscite déjà des débats chez les juristes spécialisés.
Le cabinet Crowell & Moring, dans une analyse publiée le jour même de l’entrée en application du texte, décrit ce mécanisme comme le cœur opérationnel du CRA pour les mois à venir. L’analyse complète est disponible sur le site du cabinet. Le cabinet HLC, dans une note similaire publiée le même jour, insiste sur le fait que l’obligation s’applique aussi bien aux nouveaux produits qu’aux produits déjà commercialisés avant le 11 septembre, ce qui élargit considérablement le périmètre concerné dès le premier jour.
Trois délais, une seule horloge : 24 heures, 72 heures, 14 jours
Le processus de signalement suit un rythme en trois étapes. Une alerte précoce sous 24 heures doit d’abord être transmise dès la prise de connaissance de la vulnérabilité activement exploitée ou de l’incident grave. Une notification détaillée sous 72 heures suit, avec une évaluation initiale de la gravité et de l’impact. Un rapport final clôt le processus, dans un délai de 14 jours après la mise à disposition d’une mesure corrective pour une vulnérabilité exploitée, ou d’un mois après la notification pour un incident grave.
Ce rythme rappelle volontairement celui de la directive NIS2, entrée en application en 2024 pour les entités essentielles et importantes. L’objectif affiché par la Commission européenne est d’harmoniser les obligations de cybersécurité qui pèsent sur les fabricants avec celles qui pèsent déjà sur les opérateurs de services essentiels. Un éditeur de logiciel de gestion de clés cryptographiques peut ainsi se retrouver soumis aux deux textes en même temps, avec deux horloges qui tournent en parallèle pour un même incident.
Quels produits cryptographiques tombent sous le coup du texte
Le CRA ne cible pas la cryptographie en tant que telle. Il cible les produits comportant des éléments numériques, une catégorie volontairement large qui couvre les logiciels, le matériel, les objets connectés et les services numériques commercialisés dans l’Union européenne. Dans les faits, cela signifie que toute implémentation défaillante de TLS 1.3, de RSA, d’AES-256, d’Argon2, de HMAC ou d’un système de preuve à divulgation nulle de connaissance intégré à un produit tombe sous le coup de l’obligation de signalement dès qu’elle est activement exploitée.
Les fabricants de matériel de sécurité, les éditeurs de VPN, les développeurs de bibliothèques cryptographiques open source distribuées commercialement et les fournisseurs de portefeuilles matériels ou logiciels entrent tous dans ce périmètre. La règle ne distingue pas selon la taille de l’entreprise ni selon son pays d’origine. Un fabricant établi hors de l’Union européenne mais qui vend son produit sur le marché européen reste soumis à la même obligation de signalement en 24 heures.
ENISA et sa plateforme unique de signalement
Techniquement, les signalements passent par une plateforme unique de signalement gérée par l’ENISA, l’Agence de l’Union européenne pour la cybersécurité. Cette plateforme centralise les alertes précoces, les notifications détaillées et les rapports finaux, puis les redistribue vers le CSIRT coordinateur compétent dans chaque État membre. Plus d’informations sur les missions de l’agence sont disponibles sur le site de l’ENISA.
Ce guichet unique évite en théorie qu’un fabricant doive contacter séparément chaque autorité nationale des pays où son produit est vendu. En pratique, les premières semaines de fonctionnement de la plateforme servent surtout de test de charge, et plusieurs cabinets d’avocats recommandent déjà à leurs clients de documenter précisément chaque étape de leur processus de qualification interne, pour pouvoir démontrer leur bonne foi en cas de contrôle a posteriori.
Le rôle du CERT-FR et de l’ANSSI pour les entreprises françaises
En France, le CSIRT coordinateur national désigné pour recevoir ces signalements est le CERT-FR, rattaché à l’Agence nationale de la sécurité des systèmes d’information. Les entreprises françaises soumises au CRA doivent donc articuler leurs procédures internes avec les canaux déjà connus du CERT-FR, disponibles sur cert.ssi.gouv.fr, tout en respectant en parallèle le circuit européen via la plateforme de l’ENISA. L’ANSSI, dont le site institutionnel est accessible sur cyber.gouv.fr, a déjà publié des recommandations pour accompagner cette double articulation.
Cette organisation à deux niveaux, européen et national, complique la tâche des équipes juridiques et techniques. Une entreprise qui commercialise un gestionnaire de mots de passe reposant sur Argon2, par exemple, doit désormais savoir en quelques heures si une faille découverte constitue une vulnérabilité activement exploitée au sens du CRA, tout en vérifiant si elle relève également d’une obligation de notification au titre du RGPD si des données personnelles sont concernées.
Les éditeurs de portefeuilles crypto en première ligne
Les médias spécialisés dans les crypto-actifs ont été parmi les premiers à alerter leur lectorat sur l’impact du texte pour les fabricants de portefeuilles numériques. Depuis le 11 septembre, tout éditeur de wallet doit signaler une faille activement exploitée dans le même délai de 24 heures que n’importe quel autre fabricant de produit numérique. Pour un secteur habitué à des divulgations parfois tardives après un piratage, souvent motivées par la volonté de limiter la panique des utilisateurs, cette contrainte réglementaire change la donne.
Un éditeur de portefeuille matériel qui découvre une faille dans son implémentation de la dérivation de clé ou dans son schéma de signature ne peut plus attendre d’avoir préparé un correctif complet avant de communiquer. Il doit avertir l’ENISA et le CSIRT compétent dans les 24 heures suivant la prise de connaissance, bien avant d’avoir une solution à proposer à ses utilisateurs. Ce changement de séquence, correctif d’abord ou signalement d’abord, redéfinit les procédures de gestion de crise de tout le secteur.
CRA, NIS2, RGPD : le trio réglementaire qui s’empile
Pour une entreprise européenne du numérique, trois horloges de notification coexistent désormais, avec des délais proches mais des champs d’application différents. Le tableau ci-dessous résume les grandes lignes de chaque texte pour une vulnérabilité ou un incident de sécurité.
| Texte | Alerte précoce | Notification détaillée | Rapport final | Champ d’application |
|---|---|---|---|---|
| Cyber Resilience Act, article 14 | 24 heures | 72 heures | 14 jours (faille) ou 1 mois (incident) | Produits comportant des éléments numériques |
| Directive NIS2 | 24 heures | 72 heures | 1 mois | Entités essentielles et importantes |
| RGPD, article 33 | Sans délai | 72 heures | Selon l’enquête | Violations de données personnelles |
La proximité des délais n’est pas un hasard. La Commission européenne a explicitement calqué le rythme du CRA sur celui de NIS2 pour limiter la charge cognitive des équipes de sécurité, déjà confrontées à un empilement de textes depuis l’entrée en application du RGPD en 2018. Reste que le périmètre diffère : le CRA vise le produit lui-même, NIS2 vise l’opérateur qui l’exploite, et le RGPD vise la donnée personnelle qui pourrait avoir fuité à l’occasion de l’incident.
Le calendrier complet du Cyber Resilience Act, de 2024 à 2027
Le règlement (UE) 2024/2847 égrène ses obligations sur plus de trois ans. Voici les jalons principaux, du texte adopté fin 2024 jusqu’à sa pleine application en 2027.
| Date | Obligation entrant en application |
|---|---|
| Décembre 2024 | Publication et entrée en vigueur du règlement (UE) 2024/2847 |
| 11 juin 2026 | Désignation des organismes notifiés et procédures d’évaluation de la conformité |
| 11 septembre 2026 | Article 14 : signalement des vulnérabilités activement exploitées et incidents graves |
| 11 décembre 2027 | Exigences de sécurité dites by design de l’annexe I pour tous les produits |
Cette lecture du calendrier montre que septembre 2026 n’est qu’une étape intermédiaire, mais elle a valeur de test grandeur nature. Les autorités et les entreprises rodent leurs procédures de signalement pendant quinze mois avant que les exigences techniques de fond ne s’appliquent à tous les produits déjà sur le marché.
De Heartbleed à la divulgation en 24 heures : ce qui a changé
Pour mesurer l’ampleur du changement, il faut se souvenir de la manière dont les failles cryptographiques majeures ont longtemps été traitées. La faille Heartbleed, découverte dans OpenSSL en 2014, a été gérée pendant plusieurs semaines en coordination discrète entre chercheurs et grands éditeurs avant toute annonce publique, le temps de préparer des correctifs à grande échelle. Ce modèle de divulgation coordonnée, hérité des pratiques de sécurité des années 2000 et 2010, reposait sur un arbitrage informel entre rapidité et prudence.
Le CRA renverse cet arbitrage pour les produits qui entrent dans son périmètre. La vitesse de signalement prime désormais sur la préparation d’une réponse complète. Un fabricant n’a plus le luxe d’attendre d’avoir un correctif prêt avant d’alerter les autorités, ce qui rapproche la gestion des vulnérabilités cryptographiques des pratiques déjà en vigueur pour les violations de données personnelles depuis le RGPD. La différence tient au fait que le CRA cible directement le produit et sa robustesse technique, pas seulement la donnée qu’il traite.
Ce que ça va coûter aux éditeurs de logiciels et de matériel
Aucune étude chiffrée publique ne permet à ce stade d’estimer précisément le coût de mise en conformité par entreprise, mais les cabinets de conseil en cybersécurité s’accordent sur les postes de dépense à prévoir. Il faut d’abord un processus interne de qualification capable de déterminer, en quelques heures, si une vulnérabilité découverte constitue une exploitation active au sens du CRA. Il faut ensuite une équipe ou un prestataire capable de rédiger et transmettre les trois rapports successifs dans les délais impartis, ce qui suppose une astreinte sécurité disponible en continu.
Pour les petites structures qui développent des bibliothèques cryptographiques open source distribuées à titre commercial, cette charge organisationnelle pèse proportionnellement plus lourd que pour un grand éditeur disposant déjà d’un centre opérationnel de sécurité. Plusieurs analyses juridiques évoquent un effet de concentration du marché à moyen terme, les plus petits acteurs pouvant être tentés de sous-traiter leur conformité CRA à des cabinets spécialisés ou de quitter le marché européen plutôt que de financer une astreinte permanente.
Amendes : jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires
Le barème des sanctions du CRA suit une structure à trois niveaux, comparable dans son architecture à celle du RGPD. Le manquement aux exigences essentielles de l’annexe I et aux obligations des articles 13 et 14, celui qui concerne directement le signalement des failles cryptographiques exploitées, expose à l’amende la plus lourde du texte.
| Niveau de manquement | Montant maximal | Alternative en % du CA mondial |
|---|---|---|
| Exigences essentielles (annexe I) et articles 13-14 | 15 000 000 € | 2,5 % |
| Autres obligations du règlement | 10 000 000 € | 2 % |
| Informations incorrectes ou trompeuses aux autorités | 5 000 000 € | 1 % |
Dans les trois cas, c’est le montant le plus élevé entre la somme fixe et le pourcentage du chiffre d’affaires mondial de l’exercice précédent qui s’applique. Pour un éditeur de taille moyenne, le plafond fixe de 15 millions d’euros dépasse largement son chiffre d’affaires annuel, ce qui rend cette sanction potentiellement existentielle en cas de manquement grave et répété à l’obligation de signalement en 24 heures.
Les premières réactions de l’industrie
ActiveState a été l’un des premiers éditeurs à communiquer publiquement le jour même de l’entrée en application du texte, rappelant que l’obligation touche aussi bien les nouveaux produits que ceux déjà commercialisés avant le 11 septembre. La Cloud Security Alliance a de son côté publié une note de recherche détaillant le fonctionnement du cycle de signalement en trois étapes, en insistant sur la nécessité pour les fabricants et prestataires de services concernés de disposer de processus capables de tenir les délais de 24 heures, 72 heures et 14 jours.
Du côté des cabinets d’avocats, le ton est à la prudence opérationnelle plutôt qu’à l’alarmisme. Les notes publiées par Crowell & Moring et par HLC le jour de l’entrée en application recommandent toutes deux de cartographier en amont les produits concernés, de désigner des responsables internes clairement identifiés pour chaque catégorie de produit, et de simuler des exercices de signalement avant qu’un incident réel ne survienne. Ce type de préparation rappelle les campagnes de mise en conformité qui avaient précédé l’entrée en application du RGPD en 2018.
Cinq prédictions pour la cryptographie réglementée d’ici 2027
Premièrement, le nombre de CVE publiquement documentées touchant des bibliothèques cryptographiques européennes devrait mécaniquement augmenter d’ici la fin de l’année, non pas parce que ces bibliothèques deviennent moins sûres, mais parce que l’obligation de signalement en 24 heures accélère la divulgation d’incidents qui restaient auparavant traités en coulisses.
Deuxièmement, les éditeurs de portefeuilles crypto vont probablement industrialiser des cellules de crise dédiées au CRA, sur le modèle des délégués à la protection des données imposés par le RGPD, avec un rôle spécifiquement chargé de la qualification des incidents cryptographiques.
Troisièmement, la plateforme unique de signalement de l’ENISA devrait connaître ses premiers signalements tests et ses premiers couacs opérationnels dans les semaines suivant son lancement, un scénario classique pour toute infrastructure numérique gouvernementale mise en service à grande échelle.
Quatrièmement, la convergence entre le calendrier du CRA et celui de la transition post-quantique imposée par l’ANSSI et d’autres autorités nationales devrait pousser certains éditeurs à traiter les deux chantiers de front plutôt que séquentiellement, faute de ressources pour les mener l’un après l’autre.
Cinquièmement, d’ici l’échéance du 11 décembre 2027 et l’entrée en application des exigences techniques de fond, plusieurs éditeurs de taille réduite pourraient se retirer du marché européen ou fusionner avec des acteurs plus importants déjà dotés d’une organisation de conformité mature, une dynamique de concentration déjà observée après l’entrée en application d’autres règlements européens du numérique.
Questions fréquentes
Qu’est-ce que l’article 14 du Cyber Resilience Act ?
C’est la disposition du règlement (UE) 2024/2847 qui impose aux fabricants de produits comportant des éléments numériques de signaler toute vulnérabilité activement exploitée et tout incident grave affectant la sécurité de leur produit, selon un cycle en trois étapes de 24 heures, 72 heures et 14 jours.
Depuis quand l’obligation de signalement en 24 heures s’applique-t-elle ?
Depuis le 11 septembre 2026. C’est la deuxième grande échéance du calendrier du Cyber Resilience Act, après la désignation des organismes de conformité en juin 2026 et avant l’entrée en application des exigences techniques de fond en décembre 2027.
Quels produits cryptographiques sont concernés par cette obligation ?
Tout produit intégrant des implémentations de TLS 1.3, RSA, AES-256, Argon2, HMAC ou de systèmes à preuve à divulgation nulle de connaissance entre dans le périmètre, dès lors qu’il est commercialisé dans l’Union européenne, y compris les portefeuilles crypto matériels et logiciels.
Qui reçoit les signalements de vulnérabilité en France ?
Les fabricants doivent transmettre leurs signalements via la plateforme unique de l’ENISA, qui les redistribue au CSIRT coordinateur national compétent. En France, ce rôle revient au CERT-FR, rattaché à l’ANSSI.
Que risque une entreprise qui ne respecte pas le délai de 24 heures ?
Le manquement aux obligations de l’article 14 expose à une amende pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial annuel de l’entreprise, selon le montant le plus élevé des deux.
Le CRA s’applique-t-il aux produits déjà commercialisés avant septembre 2026 ?
Oui. L’obligation de signalement de l’article 14 couvre les produits déjà présents sur le marché européen avant le 11 septembre 2026, pas uniquement les nouveaux produits mis en vente après cette date.
Quelle est la différence entre le CRA et la directive NIS2 sur les délais de notification ?
Les deux délais sont proches, mais leur champ d’application diffère. Le CRA vise le produit numérique et son fabricant, tandis que NIS2 vise les entités essentielles et importantes qui exploitent ou déploient ces produits.
