Depuis le 11 septembre 2026, un fabricant qui prend connaissance d’une vulnérabilité activement exploitée dans un produit qu’il a mis sur le marché de l’UE doit adresser une alerte précoce dans les 24 heures. Or le Cyber Resilience Act, le règlement (UE) 2024/2847, ne mentionne jamais les portefeuilles crypto.
Le chronomètre de l’article 14 démarre à la prise de connaissance par le fabricant. À partir du 11 décembre 2027, les fabricants doivent aussi soumettre régulièrement leur produit à des tests et examens de sécurité efficaces (annexe I, partie II, point 3) ; pour un produit mis sur le marché avant cette date, cette obligation ne s’applique que si le produit fait l’objet d’une modification substantielle à compter de cette date (article 69, paragraphe 2). Selon notre lecture, cette obligation a une incidence sur la question de savoir si la prise de connaissance vient de vos propres tests ou de l’exploit de quelqu’un d’autre. Voir Les machines lisent le code.
Cette note s’adresse aux fabricants de portefeuilles matériels, de logiciels de portefeuille, de logiciels de conservation et de dispositifs de paiement. Elle expose le critère qui détermine le champ d’application, ce que présupposent les 24 heures, ce qu’ajoute décembre 2027 et la place d’une revue adversariale indépendante. Elle ne constitue pas un conseil juridique et ne détermine pas si votre produit entre dans le champ d’application.
Un portefeuille entre-t-il dans le champ d’application ?
Le point de départ est la définition que le règlement donne d’un produit comportant des éléments numériques : « 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 » (article 3, point 1).
La question suivante est de savoir si ce produit est mis à disposition sur le marché. La définition en est « la fourniture d’un produit comportant des éléments numériques destiné à être distribué ou utilisé sur le marché de l’Union dans le cadre d’une activité commerciale, à titre onéreux ou gratuit » (article 3, point 22). L’article 2, paragraphe 1, ajoute une condition : le règlement s’applique à ces produits « dont l’utilisation prévue ou raisonnablement prévisible comprend une connexion directe ou indirecte, logique ou physique, à un dispositif ou à un réseau ». Selon notre lecture, un portefeuille matériel qui se connecte à un téléphone ou à un ordinateur, et un logiciel de portefeuille qui accède à un réseau, y satisferont généralement. Un appareil isolé (air-gapped) qui n’échange des données que par code QR ou carte mémoire peut néanmoins y satisfaire : l’article 3, point 9, définit la connexion physique comme une connexion établie par des moyens physiques, « y compris par des interfaces électriques, optiques ou mécaniques », et l’article 3, point 10, couvre une connexion indirecte établie « dans le cadre d’un système plus vaste qui peut être directement connecté à ce dispositif ou à ce réseau ». Savoir si un appareil donné y satisfait est une question à soumettre à un conseil juridique.
Pour les fabricants de portefeuilles, ces définitions soulèvent plusieurs questions. L’analyse qui suit donne notre lecture ; son application à un produit particulier requiert un conseil juridique.
Portefeuilles matériels
Un portefeuille matériel vendu dans l’UE correspondra souvent à la description d’un produit matériel contenant du logiciel, fourni dans le cadre d’une activité commerciale. Il reste à établir si votre appareil satisfait au critère juridique.
Son firmware fait généralement partie du produit. Une application compagnon soulève une autre question : fait-elle partie du même produit, ou constitue-t-elle un produit à part entière ?
Logiciels de portefeuille et activité commerciale
Pour un logiciel de portefeuille, la question dépend de savoir s’il est mis à disposition dans le cadre d’une activité commerciale (article 3, point 22). Le considérant 18 dit que la fourniture de produits comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts qui ne sont pas monétisés par leur fabricant ne devrait pas être considérée comme une activité commerciale.
Identifier le fabricant est une étape distincte. L’article 3, point 13, désigne la personne qui développe ou fabrique le produit, ou fait réaliser ce travail, et le commercialise sous son propre nom ou sa propre marque, « à titre onéreux, monétisé ou gratuit ».
Selon le considérant 15, la fourniture dans le cadre d’une activité commerciale peut être caractérisée non seulement par le prix facturé pour le produit lui-même, mais également par :
- le prix facturé pour des services d’assistance technique lorsqu’il ne sert pas uniquement à récupérer les coûts réels ;
- « une intention de monétisation, par exemple par la fourniture d’une plate-forme logicielle par l’intermédiaire de laquelle le fabricant monétise d’autres services » ;
- le fait de subordonner l’utilisation du produit au traitement de données à caractère personnel pour des raisons autres qu’aux seules fins d’améliorer la sécurité, la compatibilité ou l’interopérabilité du logiciel ;
- l’acceptation de dons supérieurs aux coûts associés à la conception, au développement et à la fourniture du produit.
Il précise également : « Le fait d’accepter des dons sans intention lucrative ne devrait pas être considéré comme constitutif d’une activité commerciale. »
Selon notre lecture, un portefeuille qui tire des revenus de frais, d’échanges (swaps) ou d’une formule payante se situe près de ces exemples et peut être considéré comme « monétisé » au sens du considérant 18. Le règlement ne définit pas ce mot, et nous ne déterminons pas son application à un produit particulier.
Portefeuilles libres et ouverts
Le considérant 18 décrit une exclusion : « la fourniture de produits comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts qui ne sont pas monétisés par leur fabricant ne devrait pas être considérée comme une activité commerciale ». Une entreprise qui monétise son portefeuille open source ne bénéficie pas de cette exclusion du seul fait qu’elle en publie le code source.
Le considérant traite aussi des organisations à but non lucratif. Le développement par ces organisations de produits comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts ne devrait pas être considéré comme une activité commerciale, pour autant que l’organisation soit constituée de telle façon que tous les bénéfices sont utilisés pour atteindre des objectifs non lucratifs.
Il précise en outre que le règlement ne s’applique pas aux personnes physiques ou morales qui contribuent, sous forme de code source, à des produits libres et ouverts ne relevant pas de leur responsabilité.
Back-ends de conservation
Un back-end de conservation peut relever de différentes catégories. Si le back-end est lui-même fourni sur le marché de l’Union en tant que produit, il peut constituer à part entière un produit comportant des éléments numériques (article 3, point 1).
S’il traite des données à distance pour un autre produit, l’article 3, point 2, ne le compte comme traitement de données à distance que si les deux conditions sont réunies : le logiciel est conçu et développé par le fabricant de ce produit ou sous sa responsabilité, et le produit ne pourrait pas exécuter l’une de ses fonctions sans lui.
Le considérant 12 dit que la directive (UE) 2022/2555 s’applique aux services d’informatique en nuage et aux modèles de services en nuage. Savoir quelle description convient à un système de conservation donné est une question à soumettre à un conseil juridique.
Produits importants et produits critiques
Le règlement distingue aussi les produits critiques et les produits importants. Ces classifications influent sur l’évaluation de la conformité ; la distinction compte donc indépendamment de la question du champ d’application.
L’annexe IV énumère trois catégories de produits critiques : les « Dispositifs matériels avec boîtier de sécurité » ; les passerelles pour compteur intelligent « et autres dispositifs à des fins de sécurité avancées, y compris pour un traitement cryptographique sécurisé » ; et les « Cartes à puce ou dispositifs similaires, y compris éléments sécurisés ». Le fait d’y figurer influe sur les procédures d’évaluation de la conformité qu’un produit peut utiliser (articles 8 et 32).
L’annexe III énumère les produits importants en deux classes, avec dix-neuf entrées en classe I et quatre en classe II. La classe I comprend les « Gestionnaires de mots de passe », les « Microprocesseurs dotés de fonctionnalités liées à la sécurité » et les « Microcontrôleurs dotés de fonctionnalités liées à la sécurité ». La classe II comprend les « Microprocesseurs résistants aux manipulations » et les « Microcontrôleurs résistants aux manipulations ».
Un produit dont la fonctionnalité de base est celle d’une catégorie de l’annexe III est un produit important. Les procédures d’évaluation de la conformité correspondantes figurent à l’article 32, paragraphe 2, pour la classe I et à l’article 32, paragraphe 3, pour la classe II. Intégrer un tel produit dans un autre ne soumet pas en soi le produit qui le contient à ces procédures (article 7, paragraphe 1).
L’article 32, paragraphe 5, prévoit une voie pour les produits qui répondent aux critères de logiciels libres et ouverts et relèvent d’une catégorie de l’annexe III. Leurs fabricants ont la faculté de démontrer la conformité au moyen de l’une des procédures visées à l’article 32, paragraphe 1, à condition que la documentation technique visée à l’article 31 soit rendue publique au moment de la mise sur le marché du produit.
Savoir si une entrée de l’annexe III ou de l’annexe IV décrit un appareil ou une application en particulier requiert une qualification juridique. Nous ne procédons pas à cette détermination.
Ce que présupposent les 24 heures
L’article 14 fixe trois étapes de notification pour une vulnérabilité activement exploitée. Chaque notification est adressée au CSIRT désigné comme coordinateur et à l’ENISA, par l’intermédiaire de la plateforme unique de signalement :
- Alerte précoce : « sans retard injustifié et, en tout état de cause, au plus tard 24 heures après en avoir eu connaissance ».
- Notification de vulnérabilité : sans retard injustifié et, en tout état de cause, au plus tard 72 heures après avoir eu connaissance de la vulnérabilité activement exploitée.
- Rapport final : « au plus tard 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation ».
Le CSIRT compétent dépend de l’établissement principal du fabricant dans l’Union. À défaut d’un tel établissement, l’article 14, paragraphe 7, fixe l’ordre des critères permettant de déterminer ce CSIRT.
Il existe aussi une obligation distincte d’informer les utilisateurs. Après la prise de connaissance, le fabricant doit informer les utilisateurs touchés (et, s’il y a lieu, tous les utilisateurs) de la vulnérabilité ou de l’incident. Si nécessaire, il doit aussi leur indiquer les mesures qu’ils peuvent prendre (article 14, paragraphe 8). Cette obligation est distincte de l’alerte précoce à 24 heures.
Le chronomètre démarre au moment où le fabricant en prend connaissance. Selon notre lecture, pour la plupart des produits, la prise de connaissance passe par le signalement d’un utilisateur ou d’un chercheur ; pour un portefeuille, le premier signe d’une faille exploitée est souvent l’exploit lui-même : des fonds qui bougent sans que leur propriétaire les ait déplacés.
Ce que contient chaque notification
L’étape des 24 heures est une alerte précoce, non une description de la faille. L’article 14, paragraphe 2, point a), précise que, le cas échéant, elle doit indiquer les États membres sur le territoire desquels le fabricant a connaissance que le produit a été mis à disposition.
La notification à 72 heures doit fournir les informations générales disponibles. Celles-ci portent notamment sur la nature générale de l’exploitation et de la vulnérabilité, sur toute mesure corrective ou d’atténuation prise, et sur les mesures correctives ou d’atténuation que les utilisateurs peuvent prendre.
Le rapport final doit décrire la vulnérabilité, y compris sa gravité et ses répercussions. Il doit aussi donner des précisions sur la mise à jour de sécurité ou les autres mesures correctives mises à disposition pour y remédier. Il doit aussi comporter des informations, si elles sont disponibles, sur tout acteur malveillant ayant exploité ou exploitant la vulnérabilité.
Selon notre lecture, les autres obligations du règlement portent sur la période qui précède le démarrage de ce chronomètre de notification.
Les incidents graves suivent une voie distincte
Les incidents graves suivent une voie de notification parallèle, avec les deux mêmes premières échéances. Aux termes de l’article 14, paragraphe 5, un incident est grave s’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 fonctions sensibles ou importantes. Un incident est également grave s’il a conduit, ou est susceptible de conduire, à l’introduction ou à l’exécution d’un code malveillant.
Le rapport final sur un incident grave est dû dans un délai d’un mois à compter de la notification d’incident (article 14, paragraphe 4, point c)). L’échéance de 14 jours après la mise à disposition d’une mesure de correction ou d’atténuation relève de la voie des vulnérabilités. Notre note La gestion des vulnérabilités sous le Cyber Resilience Act : où se situe la revue adversariale explique les deux voies de notification.
Ce qu’ajoute décembre 2027
Le règlement s’applique intégralement à partir du 11 décembre 2027, date à laquelle les exigences essentielles de cybersécurité de l’annexe I prennent effet. Les portefeuilles mis sur le marché avant cette date ne sont soumis aux exigences du règlement « que si, à compter de cette date, ces produits font l’objet d’une modification substantielle » (article 69, paragraphe 2) ; les obligations de notification de l’article 14 leur sont applicables indépendamment de cette modification, dès lors qu’ils relèvent du champ d’application du règlement (article 69, paragraphe 3). Notre note Les normes peuvent glisser. La date de notification, non. explique le calendrier.
Note de traduction : à l’article 69, paragraphe 3, la version française officielle vise les produits « mis sur le marché le 11 décembre 2027 », alors que les versions anglaise, allemande, espagnole et italienne visent les produits mis sur le marché avant cette date ; cette page suit ces dernières.
Trois obligations pèsent directement sur la question de savoir si un cas relevant de l’article 14 est rare ou courant. Deux viennent de l’annexe I et une de l’article 13.
Livrer sans faille exploitable connue. Sur la base de l’évaluation des risques et le cas échéant, un produit doit « être mis à disposition sur le marché sans vulnérabilité exploitable connue » (annexe I, partie I, point 2 a)).
Tester et examiner la sécurité du produit. Les fabricants « soumettent régulièrement les produits comportant des éléments numériques à des tests et examens de sécurité efficaces » (annexe I, partie II, point 3). La documentation technique doit contenir « les rapports des essais effectués pour vérifier la conformité du produit comportant des éléments numériques et des processus de gestion des vulnérabilités aux exigences essentielles de cybersécurité applicables » (annexe VII, point 6). Voir rapport d’essais CRA.
Faire preuve de diligence raisonnable sur ce que vous n’avez pas écrit. Les fabricants « font preuve de diligence raisonnable lorsqu’ils intègrent dans des produits comportant des éléments numériques des composants obtenus auprès de tiers, de sorte que ces composants ne compromettent pas la cybersécurité du produit comportant des éléments numériques » (article 13, paragraphe 5). Cela inclut les composants de logiciels libres et ouverts. Pour un portefeuille, cela vise les bibliothèques cryptographiques, le code de dérivation et le constructeur de transactions dont il dépend.
Ce ne sont là qu’une partie des exigences. L’annexe I couvre aussi, entre autres, la confidentialité et l’intégrité des données et des commandes, le recensement des vulnérabilités et des composants, y compris une nomenclature des logiciels (SBOM), une politique de divulgation coordonnée des vulnérabilités et des mises à jour de sécurité en temps utile.
Le non-respect des exigences essentielles de cybersécurité de l’annexe I et des obligations des articles 13 et 14 est passible d’amendes administratives pouvant aller jusqu’à 15 000 000 EUR. Si l’auteur de l’infraction est une entreprise, le plafond est ce montant ou 2,5 % de son chiffre d’affaires annuel mondial total réalisé au cours de l’exercice précédent, le montant le plus élevé étant retenu (article 64, paragraphe 2).
Aucune de ces obligations ne dépend du fait que le code a été écrit par une personne ou par un modèle. Si un modèle a écrit une partie de votre chemin de signature, l’obligation de l’avoir testé et examiné vous incombe toujours. Voir Le vibe coding est-il sûr ? Ce qu’a trouvé un banc d’essai de 186 tâches réelles. Notre page Revue de code adversariale : ce que le terme laisse de côté explique pourquoi un second modèle n’est pas automatiquement un second témoin.
Là où le code des portefeuilles cède
Une revue doit bien commencer quelque part. Dans le code d’un portefeuille, les endroits où un défaut peut coûter de l’argent sont bien connus. Nous commençons par :
- la génération des clés et l’entropie qui la sous-tend ;
- la sauvegarde et la restauration de la graine, ainsi que la dérivation des clés et des adresses ;
- la signature, y compris la manière dont les nonces sont produits et la possibilité que l’un d’eux se répète ;
- la construction des transactions, y compris la question de savoir si ce que l’appareil affiche est bien ce qu’il signe ;
- le chemin de mise à jour du firmware et des applications : le règlement demande « des mécanismes de distribution sécurisée des mises à jour » (annexe I, partie II, point 7) ;
- les composants tiers dont tous ces éléments dépendent (article 13, paragraphe 5).
Ce sont des sources de défaillance des portefeuilles en général. Les énumérer ne revient pas à affirmer qu’un produit particulier contient une faille.
Ce que nous proposons à un fabricant de portefeuilles
Une première mission couvre un seul composant : celui où une faille coûterait le plus à vos utilisateurs. Il s’agit généralement de la signature, de la dérivation des clés ou du chemin de mise à jour. Nous examinons de manière adversariale une révision précise et figée du code et livrons un dossier de constats signé.
Chaque constat confirmé est étiqueté selon la manière dont il a été établi : reproduit par un test exécuté contre le code non modifié, ou lu dans ce code sans l’exécuter. Le dossier ne présente jamais un constat comme plus établi que ne le permet sa preuve. Il identifie aussi chaque surface examinée sans constat et la méthode employée pour l’examiner.
Les relecteurs sont indépendants de l’auteur de votre code, et une personne nommée répond du dossier. Un constat est clos lorsque le relecteur qui l’a soulevé le retire ou lorsqu’il est démontré sur le code. Voir Un constat n’est pas un verdict et What settles a finding.
Le dossier documente le test et l’examen du composant qui en a fait l’objet. Il fournit des éléments de preuve au titre de l’obligation, prévue à l’annexe I, partie II, point 3, de soumettre régulièrement le produit à des tests et examens de sécurité efficaces. Cette obligation couvre l’ensemble du produit et exige un travail récurrent ; une seule mission ne peut donc pas l’acquitter. Le dossier ne constitue pas non plus, à lui seul, les rapports d’essais que l’annexe VII, point 6, impose de faire figurer dans la documentation technique. La même méthode de revue peut ensuite être appliquée au reste du produit.
Une revue de composant ne rend pas votre produit conforme et ne détermine pas s’il entre dans le champ d’application, ni s’il est important ou critique. Elle ne met pas en place vos notifications au titre de l’article 14 et ne remplace pas un organisme notifié là où il en faut un.
Nos cinq refus fixent d’autres limites à ce que nous affirmons. Parmi eux : l’accord entre modèles d’IA n’est pas une preuve, et une revue qui ne trouve rien n’établit pas qu’il n’y a rien.
Les dispositions du Cyber Resilience Act citées renvoient au règlement (UE) 2024/2847 et ont été vérifiées contre la version linguistique française officielle, dont les passages entre guillemets reprennent le texte. Cette page est une traduction de l’original anglais ; en cas de divergence, l’original prévaut. Si quelque chose est faux ici, nous le corrigerons par écrit sur cette page.