Clés privées : en 2026, voler la seed ne suffit plus

L’année 2026 restera comme l’une des pires de l’histoire crypto en matière de vols, et pourtant la cryptographie n’a presque rien à voir avec ce naufrage. Le Bitcoin s’échange autour de 66 500 euros (près de 77 000 dollars), les courbes elliptiques qui protègent les portefeuilles n’ont pas cédé, et aucun superordinateur n’a cassé une clé privée par force brute. Ce qui a cédé, c’est tout ce qui entoure la clé.

Le basculement est net. Pour la première fois dans l’histoire mesurée du secteur, la compromission de clés a dépassé les failles de smart contracts comme premier vecteur de pertes, avec environ 1,3 milliard de dollars envolés sur les huit premiers mois de 2026. Mais la vérité est plus dérangeante encore : la clé que l’on vole n’est presque plus jamais une phrase de douze ou vingt-quatre mots. C’est une clé d’administration, un jeton de session, un nœud RPC, une pré-signature de gouvernance.

HOGE Wire a déjà décortiqué la signature à l’aveugle, le facteur humain et le phishing dopé à l’intelligence artificielle. Cet article prend l’autre bout du problème : l’architecture. MPC, multisig, HSM, et cette idée têtue que découper une clé ne fait, le plus souvent, que déplacer la cible d’un cran plus haut.

Ce qu’on appelle « clé » a changé de nature

Le slogan « pas vos clés, pas vos cryptos » repose sur une image simple : une clé privée, un propriétaire, un secret à protéger. Cette image ne décrit plus la réalité d’un protocole ou d’une plateforme en 2026. Un service moderne ne détient pas une clé, il gère une hiérarchie de secrets privilégiés : des clés de signature qui déplacent les fonds, des clés d’administration qui modifient les paramètres, des clés de mise à niveau qui remplacent le code, des clés d’oracle qui fixent les prix, des jetons de session qui ouvrent les consoles, des clés d’API qui pilotent les robots de trading, des rôles IAM qui gouvernent le cloud, et des accès aux nœuds RPC qui relient tout cela à la blockchain.

Chacun de ces secrets est un levier, et tous n’ont pas la même protection. Une seed phrase peut dormir dans un coffre, gravée sur une plaque d’acier, hors ligne. Un jeton de session, lui, vit dans la mémoire d’un ordinateur portable de développeur, transite par un VPN et expire au bout de quelques heures, sauf quand il n’expire pas. Le travail de l’attaquant n’est plus de casser la meilleure clé, mais de trouver celle qui combine le plus de privilèges et le moins de surveillance. En 2026, cette clé est rarement celle que le grand public imagine.

2026, l’année où les clés ont battu le code

Les chiffres racontent une bascule structurelle. Selon le décompte de CertiK repris par Forbes, le premier semestre 2026 a vu disparaître environ 1,32 milliard de dollars, la compromission de portefeuilles s’imposant comme la catégorie la plus coûteuse avec 444 millions de dollars (environ 385 millions d’euros) sur 33 incidents, soit plus de 13 millions de dollars détournés en moyenne par événement.

La cause de fond n’a rien de mystérieux. Le code a été audité, formellement vérifié, soumis à des primes de bug et durci pendant des années ; l’infrastructure humaine et opérationnelle qui entoure les clés, elle, a très peu bougé. Il est devenu plus rentable de piéger un développeur, de détourner une session ou de corrompre un serveur que de dénicher une faille exploitable dans un contrat déjà passé au crible. Ronghui Gu, cofondateur de CertiK, le résume à Forbes d’une phrase qui pourrait servir d’épitaphe à l’année : un protocole peut réussir un audit de code impeccable et perdre malgré tout des millions à cause d’une clé d’administration compromise. L’audit valide la logique, pas la personne qui détient les droits.

Le contexte de plus long terme confirme la tendance. En 2025, plus de 3,4 milliards de dollars ont été dérobés au secteur, dont 2,02 milliards attribués à la Corée du Nord, qui a signé un record en concentrant les trois quarts des compromissions de services. Autrement dit, ce n’est pas la finance décentralisée qui est devenue plus fragile, ce sont ses gardiens de clés qui sont devenus la cible la plus rentable de la planète.

Drift : voler une clé d’administration sans toucher à une seed

Le 1er avril 2026, le protocole de dérivés Drift, sur Solana, a perdu 285 millions de dollars (environ 245 millions d’euros), ce qui en a fait le plus gros vol crypto de l’année à ce moment-là et le deuxième plus important de l’histoire de Solana, derrière le pont Wormhole en 2022. Aucune seed phrase n’a fuité. Aucune faille de contrat n’a été exploitée au sens classique. Ce qui a été détourné, c’est l’autorité d’administration elle-même.

Le déroulé, reconstitué par Chainalysis, ressemble à une opération de renseignement. Les attaquants se sont fait passer pendant des mois pour une société de trading quantitatif afin de gagner la confiance de contributeurs de Drift. Ils ont ensuite exploité les « durable nonces » de Solana, une fonctionnalité qui permet de signer une transaction pour une exécution ultérieure, afin de faire pré-signer à l’aveugle, par les membres du conseil de sécurité, des transactions dormantes en apparence anodines. Une fois déclenchées, ces transactions ont silencieusement transféré le contrôle administratif aux pirates, qui ont enchaîné 31 retraits rapides. Pour amorcer la manipulation d’oracle, ils avaient au préalable créé un faux jeton, gonflé son prix par du wash trading dans un pool de liquidité alimenté par à peine 500 dollars.

Le résultat fut brutal : la valeur totale bloquée dans le protocole a chuté de plus de moitié. La leçon centrale est ailleurs que dans le montant : c’est un cousin de la signature à l’aveugle, mais transposé à l’étage de la gouvernance. Les signataires ont approuvé exactement ce qu’on leur montrait ; le piège était dans ce qu’ils ne voyaient pas.

Ce mode opératoire mérite qu’on s’y arrête, car il se généralise. Faire pré-signer une action de gouvernance, c’est obtenir une signature valide aujourd’hui pour une transaction qui ne se déclenchera que demain, quand plus personne ne regardera. Les conseils de sécurité, les DAO et les équipes multisig approuvent régulièrement des lots d’opérations à l’avance, par simple commodité opérationnelle. Chaque pré-signature dormante est pourtant une bombe à retardement si son contenu réel diffère de ce que le signataire croyait valider. La parade est connue mais rarement appliquée : décoder et simuler chaque transaction avant de la signer, limiter la durée de validité des pré-signatures, et imposer un délai incompressible entre l’approbation d’un changement d’administration et son entrée en vigueur.

KelpDAO : la faille était dans le RPC, pas dans le code

Dix-sept jours plus tard, le 18 avril 2026, un attaquant a frappé encore plus fort en frappant encore plus haut dans la chaîne d’infrastructure. Il a fabriqué de toutes pièces 116 500 rsETH non adossés, environ 18 % de l’offre du jeton de restaking liquide de KelpDAO, pour une valeur d’à peu près 292 millions de dollars (environ 250 millions d’euros). Là encore, pas de seed volée, pas de bug dans le contrat.

L’analyse d’OpenZeppelin porte un titre qui vaut manifeste : « Zéro bug trouvé ». Tout s’est joué dans l’infrastructure. Le 6 mars, un développeur de LayerZero Labs a été piégé pour cloner un dépôt GitHub malveillant, qui a déposé un logiciel espion sur son Mac. À partir de cet accès, l’attaquant a récolté des clés de session et s’est installé pendant six semaines dans l’infrastructure RPC de LayerZero, via des VPN commerciaux. Il a ensuite corrompu la mémoire de nœuds RPC pour qu’ils renvoient des réponses véridiques aux outils de surveillance, tout en servant des données falsifiées au vérificateur du pont. Ce vérificateur, réduit à un seul signataire après un passage de deux-sur-deux à un-sur-un, a alors attesté qu’un dépôt de rsETH avait eu lieu alors qu’aucune transaction de la sorte n’existait. L’attaquant a émis ses jetons fantômes, puis emprunté environ 236 millions de dollars de WETH sur Aave.

Le renseignement privé, de Mandiant à CrowdStrike, attribue l’opération au groupe TraderTraitor, alias UNC4899, une émanation de Lazarus. Le point technique à retenir tient en une image : la surveillance regardait les bons chiffres pendant que la clé de vérification signait les mauvais. Quand un attaquant contrôle à la fois ce qui décide et ce qui surveille, la répartition des rôles ne protège plus rien.

MPC contre multisig : deux façons de découper une clé

La réponse historique du secteur au risque de la clé unique tient en un principe : ne jamais laisser une clé exister seule. Deux écoles se partagent ce terrain, souvent confondues à tort.

Le multisig répartit plusieurs clés entières et indépendantes ; un contrat intelligent, comme ceux de Safe, fait appliquer le quorum directement sur la chaîne. Chaque signataire détient une vraie clé, l’exécution est transparente et auditable on-chain, mais le dispositif est propre à chaque blockchain et laisse une empreinte visible. À l’inverse, la MPC, ou calcul multipartite avec signature à seuil, découpe une clé unique en parts qui ne sont jamais réunies : aucun participant ne détient ni ne reconstitue jamais la clé entière, la coordination se fait hors chaîne, et le protocole produit une signature unique. Comme l’explique Silence Laboratories, une transaction signée en MPC ressemble sur la chaîne à une transaction à clé unique, ce qui rend la méthode agnostique et compatible avec n’importe quel réseau, au prix d’une auditabilité on-chain plus faible.

Chez Fireblocks, qui revendique plus de 2 400 clients institutionnels, les parts de clé ne sont jamais générées ni rassemblées au même endroit, ni à la création, ni à la rotation, ni à la signature ; elles vivent dans des enclaves matérielles de type Intel SGX, illisibles même pour un administrateur véreux ayant pris le contrôle du système d’exploitation. À cela s’ajoute le HSM classique, ce module matériel inviolable et certifié où la clé ne sort jamais, brique de base du stockage à froid des plateformes. Le tableau ci-dessous résume où chaque approche place son point faible.

En production, les dépositaires sérieux ne choisissent pas, ils combinent : la MPC pour la couche d’exécution, rapide et automatisée, et le multisig pour la gouvernance on-chain, transparente et opposable. Le point commun de tout ce paysage, c’est que la clé cesse d’être un objet unique à voler. Ce qui déplace, mécaniquement, le champ de bataille.

Générer la clé : la faille d’amont que l’on oublie

Toute cette discussion suppose que la clé, ou ses parts, ont été créées correctement. C’est loin d’être acquis. Une clé n’est jamais plus solide que le hasard qui l’a engendrée, et l’histoire du secteur est jalonnée de générateurs défaillants. Des adresses de vanité produites avec une entropie insuffisante ont livré des fonds à quiconque savait rejouer le calcul ; des générateurs de phrases mnémoniques mal conçus ont produit des seeds devinables en quelques heures. Dans ces cas, ni signature à l’aveugle ni RPC corrompu : la clé était compromise dès sa naissance, et aucune répartition ultérieure n’y pouvait rien.

C’est précisément là que les architectures institutionnelles prennent tout leur sens. En MPC, les parts sont générées de façon distribuée, sans qu’aucune machine ne voie jamais la clé complète, pas même à l’instant de la création. Un HSM fabrique la clé dans son enclave scellée, à partir d’une source d’entropie certifiée, et refuse ensuite de la laisser sortir. Les dépositaires sérieux entourent cette étape d’une cérémonie des clés : plusieurs participants, un environnement hors ligne, des procédures filmées et auditées, parce que le moment de la génération est un point de compromission unique et irréversible. Se tromper à la naissance de la clé, c’est bâtir tout l’édifice de sécurité sur du sable, et aucun des contrôles décrits plus haut ne rattrape ce défaut d’origine.

Découper la clé ne suffit pas : la leçon Bybit

Le contre-exemple le plus cher de l’histoire est aussi le plus instructif. En février 2025, Bybit a perdu environ 1,5 milliard de dollars (près de 1,3 milliard d’euros), le plus gros vol crypto jamais enregistré. Or Bybit utilisait précisément un multisig, la référence en matière de répartition des clés. Le dispositif n’a pas cédé parce que des clés auraient fuité ; il a cédé parce que le code JavaScript de l’interface de Safe, hébergé dans un bucket cloud, avait été altéré. Les signataires voyaient un transfert anodin et signaient, en réalité, une modification de la logique de contrôle du portefeuille froid.

Ben Zhou, cofondateur et directeur général de Bybit, a insisté sur ce point après la revue forensique : les systèmes internes de la plateforme n’avaient pas été infiltrés, la compromission venait de l’infrastructure de signature de Safe. Les deux entreprises se sont d’ailleurs renvoyé la responsabilité, un avant-goût des batailles juridiques que MiCA promet d’arbitrer en Europe. Le même schéma s’était déjà joué en 2024 avec la plateforme indienne WazirX, dont le multisig Gnosis Safe, opéré via un prestataire, avait vu sa transaction altérée au moment de la signature.

La conclusion est contre-intuitive mais essentielle : répartir les clés ne réduit pas le risque, il le remonte d’un étage. Le quorum ne vaut que ce que voit chaque signataire et ce qui gouverne le collectif. Un multisig trois-sur-cinq dont les cinq membres regardent la même interface piégée n’est pas cinq fois plus sûr, il est piégeable en une seule fois. On retrouve la même vérité opérationnelle dans notre post-mortem du hack de Liquid : du code par ailleurs solide ne protège pas d’une défaillance qui se joue ailleurs que dans le code.

La nouvelle surface d’attaque : l’infrastructure autour de la clé

Si l’on additionne Drift, KelpDAO et Bybit, un périmètre se dessine, et ce n’est plus la seed phrase. C’est l’ensemble du plan opérationnel qui fabrique, transporte et déclenche les signatures. Dès le premier trimestre 2026, les analystes constataient que les attaquants délaissaient les contrats intelligents au profit des clés privées et de l’infrastructure cloud. Les points d’entrée forment désormais une liste précise.

• Les rôles et accès cloud, comme le bucket de stockage qui hébergeait le code piégé de Bybit.
• Les nœuds RPC, corrompus en mémoire chez KelpDAO pour mentir au seul vérificateur.
• Les jetons et cookies de session, récoltés sur l’ordinateur d’un développeur, qui contournent les mots de passe et l’authentification.
• Les postes de travail des équipes techniques, infectés via un dépôt GitHub malveillant ou une fausse offre d’emploi.
• Les secrets d’intégration continue et les clés d’API, qui donnent des droits d’exécution sans passer par un humain.
• Les angles morts de la surveillance, quand l’outil de monitoring reçoit des données véridiques pendant que le système de décision reçoit des données falsifiées.

Le fil rouge est toujours le même : l’ingénierie sociale ouvre la porte, puis l’attaquant se déplace latéralement jusqu’à la ressource qui signe. C’est pourquoi la frontière de la sécurité en 2026 n’est plus le portefeuille, mais le développeur, le serveur et le pipeline. La cryptographie tient ; c’est la chaîne d’approvisionnement des signatures qui fuit.

Anatomie comparée des grandes compromissions

Aligner les quatre cas emblématiques fait ressortir ce qu’aucun communiqué ne dit isolément : dans aucun d’eux l’attaquant n’a volé une phrase de récupération. Chacun a subverti un accès privilégié ou le chemin de signature, à un étage différent de la pile.

Lu ainsi, le tableau invalide l’imaginaire dominant de la sécurité crypto, celui du hardware wallet posé dans un coffre. La plaque d’acier gravée protège admirablement contre l’extraction d’une seed, mais elle est hors sujet face à une pré-signature de gouvernance ou à un nœud RPC corrompu. Défendre la seed alors que l’attaque vise l’infrastructure, c’est verrouiller la porte du garage pendant que le cambrioleur passe par la salle des serveurs.

La Corée du Nord a industrialisé le vol de clés

Cette bascule vers l’infrastructure n’est pas le fruit du hasard, c’est une stratégie d’État. À eux seuls, Drift et KelpDAO totalisent environ 575 millions de dollars, soit près de 44 % des pertes de l’année, et tous deux sont attribués à l’appareil cyber nord-coréen. Sur l’ensemble de 2025, la Corée du Nord avait déjà signé les trois quarts des compromissions de services recensées.

La méthode explique le rendement. Andrew Fierman, responsable du renseignement de sécurité nationale chez Chainalysis, relie ces vols à la campagne parallèle de travailleurs informatiques infiltrés, où des agents se font embaucher au sein d’entreprises technologiques occidentales. L’infiltration de plusieurs mois observée chez Drift n’est pas une prouesse ponctuelle, c’est un procédé reproductible : construire une identité, gagner un accès, attendre la fenêtre, siphonner. L’intelligence artificielle vient huiler la mécanique, en fabriquant des personas crédibles et en accélérant le blanchiment après coup. Face à un adversaire qui traite la compromission de clés comme une chaîne de production, protéger un secret ne suffit plus ; il faut sécuriser tout le processus qui y donne accès.

Signature claire et simulation : réparer le geste de signer

Si le point faible est ce que le signataire ne voit pas, la première parade est de le lui montrer. C’est tout l’objet de la signature claire, standardisée sous le nom d’ERC-7730. Née comme projet interne chez Ledger en 2021, formalisée en 2024, elle a vu sa gouvernance transférée à l’Ethereum Foundation, qui a officialisé le standard le 12 mai 2026 avec le soutien de Trezor, MetaMask, WalletConnect et Fireblocks. Le principe : remplacer les données hexadécimales illisibles que l’on approuve aujourd’hui par une description en langage humain de ce que la transaction fait réellement. Un Bybit ou un Drift devient beaucoup plus difficile quand l’appareil affiche « vous transférez le contrôle du portefeuille » au lieu d’une bouillie de caractères.

La signature claire n’agit toutefois pas seule. Elle s’accompagne d’un arsenal qui s’attaque au geste de signer plutôt qu’au stockage de la clé.

• La simulation de transaction, qui rejoue l’opération et montre le solde après coup avant toute approbation.
• Les listes d’autorisation d’adresses, qui bloquent tout transfert vers une destination non validée au préalable.
• Les moteurs de politique, qui imposent des plafonds, des délais et des règles métier à chaque signature.
• Les timelocks sur les actions d’administration, qui laissent le temps de repérer et d’annuler une pré-signature piégée du type de celle de Drift.
• La rotation proactive des parts de clé en MPC, qui rend inutiles des parts volées mais périmées.

Aucune de ces mesures n’est magique, mais ensemble elles transforment une signature aveugle en décision informée. Or c’est précisément à l’instant de la signature que les plus gros vols de la décennie se sont joués.

Défendre l’infrastructure, pas seulement la clé

La signature claire soigne le symptôme visible ; l’autre moitié du travail se déroule loin des yeux du signataire, dans l’infrastructure. Les cas de 2026 dessinent une feuille de route défensive assez précise pour être appliquée sans attendre une nouvelle catastrophe.

• Le moindre privilège pour les clés d’administration, avec séparation stricte entre proposer et exécuter une action sensible.
• Des jetons de session courts, à portée limitée, révoqués agressivement, pour que six semaines d’accès continu comme chez KelpDAO deviennent impossibles.
• Une authentification résistante au phishing, de type FIDO2 ou passkey, pour les développeurs et les opérateurs.
• Le durcissement des postes de travail, car le vol de KelpDAO a commencé par un logiciel espion sur un Mac.
• L’intégrité et l’attestation des nœuds RPC, afin qu’un serveur corrompu ne puisse pas mentir en silence.
• La fin des vérificateurs uniques : passer d’un-sur-un à n-sur-m sur tout composant qui atteste ou décide.
• Une surveillance qui ne peut pas être trompée par ce qu’elle surveille, leçon directe du monitoring dupé de KelpDAO.

Ces exigences ne sont pas seulement de bonnes pratiques : en Europe, elles rejoignent la lettre du règlement DORA sur la résilience opérationnelle, qui traite précisément du risque lié aux tiers informatiques, aux infrastructures et à leur supervision. La sécurité des clés est en train de devenir une discipline d’ingénierie des systèmes, pas de conservation d’un secret.

Le particulier n’échappe pas à la même logique

Un investisseur individuel n’exploite ni conseil de sécurité ni cluster de nœuds RPC, mais la logique se transpose à son échelle. Son infrastructure autour de la clé, c’est l’interface de son portefeuille, son presse-papiers, son extension de navigateur, sa sauvegarde de seed, son compte sur une plateforme. Le principe reste identique : protéger le chemin de signature et l’environnement, pas seulement la phrase de récupération.

Concrètement, cela signifie un portefeuille matériel doublé de signature claire, la vérification systématique des adresses de destination, le refus des approbations à l’aveugle, la révocation régulière des autorisations de dépense accordées à d’anciens contrats, la séparation entre un portefeuille chaud de dépense et un stockage froid, et la discrétion sur ses avoirs. Ceux qui délèguent la garde à un tiers n’échappent pas au débat, ils l’héritent : confier ses actifs à une plateforme, c’est adopter son architecture de clés et ses modes de défaillance. La question « qui contrôle réellement les clés » se pose autant pour un jeton de staking liquide que pour un solde d’exchange, et la baleine crypto de 2026 est d’ailleurs souvent un dépositaire plutôt qu’un particulier. L’auto-conservation fait de vous votre propre équipe de sécurité ; la délégation vous fait dépendre de celle du dépositaire.

AMF, MiCA, DORA : qui répond quand la clé tombe

Quand la clé tombe, la question suivante est juridique : qui paie ? En France, la conservation de clés privées pour le compte de tiers est depuis longtemps un service réglementé sous le régime PSAN, et ce régime transitoire a définitivement laissé place au cadre européen MiCA. L’AMF a rappelé aux prestataires non conformes qu’ils devaient organiser une extinction ordonnée de leurs activités, l’exercice sans agrément exposant à des sanctions pénales.

MiCA cadre la garde avec des mots qui résonnent avec tout cet article : conserver, c’est contrôler les moyens d’accès aux crypto-actifs, au premier rang desquels les clés cryptographiques privées. Le prestataire doit ségréguer les avoirs de ses clients et, surtout, il supporte la charge de la preuve en cas de perte, sauf à démontrer une cause qui lui échappe. Ajoutez le règlement DORA, qui impose une résilience opérationnelle sur toute la chaîne informatique, et l’on obtient un cadre où le débat Bybit contre Safe, chacun accusant l’autre, se réglerait en Europe en faveur du client : c’est au prestataire agréé de prouver qu’il a sécurisé non seulement les clés, mais aussi l’interface, le cloud et les tiers qui les entourent. La réglementation a compris, avant beaucoup d’acteurs, que la clé n’est jamais toute seule.

Reste que le droit court derrière la technique. Tant que les attaquants viseront l’infrastructure plutôt que la cryptographie, la meilleure protection restera architecturale : concevoir la signature pour qu’aucune compromission isolée, ni d’une clé, ni d’un serveur, ni d’un signataire, ne soit fatale. En 2026, voler la seed ne suffit plus, et c’est précisément pour cela que défendre la seed ne suffit plus non plus.

Frequently Asked Questions

Qu’est-ce que la compromission d’une clé privée en crypto ?

C’est la prise de contrôle, par un attaquant, d’un secret qui autorise le déplacement de fonds ou la modification d’un protocole. En 2026, ce secret est rarement une phrase de récupération de vingt-quatre mots : c’est souvent une clé d’administration, un jeton de session, une clé d’API ou l’accès à un nœud RPC. L’attaquant n’a pas besoin de casser la cryptographie, il lui suffit de trouver et de détourner la bonne autorisation.

Pourquoi les clés volées ont-elles dépassé les bugs de smart contract en 2026 ?

Parce que le code a été audité, durci et testé pendant des années, tandis que l’infrastructure humaine et opérationnelle autour des clés a peu progressé. Il est devenu plus simple de piéger un développeur, de détourner une session ou de corrompre un serveur que de trouver une faille exploitable dans un contrat vérifié. Sur les huit premiers mois de 2026, la compromission de clés est devenue le premier vecteur de pertes pour la première fois.

MPC ou multisig : quelle architecture est la plus sûre ?

Aucune des deux n’est intrinsèquement supérieure, elles déplacent le risque à des endroits différents. Le multisig répartit plusieurs clés entières et fait appliquer le quorum par un contrat on-chain, ce qui est transparent mais propre à chaque chaîne. La MPC découpe une seule clé en parts qui ne sont jamais réunies et signe hors chaîne, ce qui est flexible et multi-chaînes mais moins auditable. En pratique, les dépositaires sérieux combinent les deux et protègent surtout la couche de signature et de politique.

Un portefeuille matériel protège-t-il d’une compromission de clé ?

Il protège très bien contre l’extraction de la clé, qui ne quitte jamais l’appareil, mais pas contre la signature à l’aveugle. Si l’interface vous montre une transaction anodine alors que vous signez en réalité un transfert de contrôle, le matériel signera sans broncher. La parade est la signature claire, qui affiche en langage lisible ce que vous approuvez, associée à la vérification des adresses et à la révocation des autorisations inutiles.

Que disent l’AMF et MiCA sur la garde des clés privées ?

En France, la conservation de clés privées pour le compte de tiers est un service réglementé, et le régime transitoire PSAN a laissé place au cadre MiCA le 1er juillet 2026. MiCA définit la conservation comme le fait de contrôler les moyens d’accès aux crypto-actifs, dont les clés privées, impose la ségrégation des avoirs des clients et fait peser sur le prestataire la charge de la preuve en cas de perte. Le règlement DORA y ajoute des exigences de résilience opérationnelle sur l’infrastructure informatique.

Par Anneke de Vries, rédactrice en chef sécurité chez HOGE Wire.