L'expression « exigences pentest MiCA » revient dans environ la moitié de nos appels de cadrage avec des exchanges crypto, des dépositaires et des émetteurs de stablecoins en préparation d'autorisation européenne. La synthèse honnête : MiCA n'écrit pas le playbook pentest. Il s'appuie sur le cadre ICT-risk plus large, ancré sur DORA, avec le régime PSAN en France qui ajoute des spécificités alignées ANSSI. Cet article détaille à quoi ça ressemble en pratique.
Où vit l'exigence
Il n'y a pas un article unique de MiCA qui dit « faites un pentest ». La barre de conformité se construit à partir de trois sources qui se recouvrent :
- Article 9 de MiCA et les mesures de Niveau 2 / Niveau 3 associées : les CASP doivent maintenir des systèmes ICT « robustes », des dispositifs de continuité d'activité et une réponse à incident testée. Le détail est délégué à DORA.
- Articles 24 à 27 de DORA : c'est là que le programme de tests est défini.
- Article 24 : programme de tests basé sur le risque, couvrant tous les systèmes et applications ICT pertinents.
- Article 25 : évaluations de vulnérabilités et pentests au moins annuellement sur les systèmes jugés pertinents pour le profil de risque de l'entreprise.
- Article 26 : threat-led penetration testing (TLPT) pour les entités classées significatives, tous les trois ans, selon une méthodologie alignée TIBER-EU.
- Article 27 : exigences sur les testeurs eux-mêmes (indépendance, certifications, documentation méthodologique).
- Régimes nationaux (PSAN en France, BaFin en Allemagne, autres) : ils ajoutent des attentes nationales par-dessus MiCA + DORA. En France en particulier, l'AMF s'aligne sur les guides techniques de l'ANSSI pour les sociétés agréées PSAN.
L'effet pratique : tout CASP sous MiCA a besoin d'une cadence pentest annuelle, avec méthodologie documentée et une attestation exploitable par son autorité nationale compétente. Les entités significatives doivent en plus faire du TLPT tous les trois ans.
Évaluation de vulnérabilités vs TLPT
Ce ne sont pas le même exercice, et ce ne sont pas interchangeables aux yeux des superviseurs.
Une évaluation de vulnérabilités sous DORA article 25 ressemble à ce que la plupart des équipes appellent déjà un pentest : périmètre cadré, time-boxé, à la recherche de faiblesses exploitables sur les systèmes du périmètre. La méthodologie est documentée ; les findings sont classés ; la remédiation est suivie.
Un threat-led penetration test (TLPT) sous l'article 26 est une bête différente. C'est intelligence-led, simulant les tactiques d'un acteur de menace spécifique sur un périmètre plus large de systèmes en production, souvent avec des composants red-team et purple-team. Plus cher (souvent 5 à 10× un pentest standard), plus long (mois, pas semaines), et suivant le cadre TIBER-EU si l'entreprise opère dans des juridictions qui l'ont adopté.
La plupart des CASP ne sont pas classés « significatifs » et n'auront besoin que des évaluations de vulnérabilités. Les CASP significatifs (les plus gros exchanges et émetteurs de stablecoins) ont besoin des deux.
Ce que votre superviseur veut voir
Le dossier de conformité ICT testing d'un CASP doit contenir :
- Un programme de tests documenté : périmètre, fréquence, méthodologie, ownership.
- Le rapport de la dernière évaluation de vulnérabilités / pentest : scope statement, méthodologie, findings classés par sévérité, statut de remédiation, résultats du re-test.
- Une lettre d'attestation du prestataire de tests : déclaration d'indépendance, qualifications du lead tester, dates, executive summary.
- Un plan de traitement du risque : quels findings ont été acceptés en risque résiduel, avec validation au bon niveau de gouvernance.
- Des preuves de remédiation : tickets clos, correctifs déployés, re-tests passés.
- Pour les entités sous TLPT : le brief de threat intelligence, le test plan validé avec le superviseur, le debrief post-test.
L'erreur que la plupart des équipes commettent, c'est de traiter le pentest comme le livrable et le dossier comme du ménage administratif. Du point de vue du superviseur, le dossier est le livrable. Un super pentest sans lettre d'attestation a l'air plus faible qu'un pentest moyen avec un dossier propre.
À quelle fréquence, et sur quel périmètre
MiCA + DORA attendent :
- Au moins annuellement pour les évaluations de vulnérabilités sur les systèmes pertinents. « Pertinent » veut dire tout ce qui est customer-facing, tout ce qui est dans le chemin d'exécution des trades, les systèmes de custody, l'infra de signature, les admin panels, et l'infra cloud / réseau supportant.
- Après chaque changement matériel : intégration d'une nouvelle chaîne, nouvelle architecture de custody, révision majeure d'API, acquisition. Le « matériel » est interprété par votre superviseur : en cas de doute, cadrez un re-test ciblé.
- Tous les trois ans pour le TLPT, pour les entités significatives.
En pratique, une cadence crédible pour un exchange typique agréé PSAN ressemble à :
- Pentest annuel full-scope de la plateforme + APIs + infra adjacente à la custody.
- Re-tests ciblés après chaque release majeure.
- Surveillance de wallets continue sur les adresses opérationnelles et de custody (pas strictement imposé par MiCA, mais le type de preuve que les superviseurs attendent de plus en plus).
- Un plan de réponse à incident documenté, avec des chemins d'escalade testés.
Combien ça coûte
Les pentests de conformité sont plus chers qu'un pentest standard sur la même surface. Le premium paie pour :
- Une méthodologie documentée alignée avec DORA articles 25 / 26.
- La lettre d'attestation et le package de preuves associé.
- Le support post-mission pendant la revue par le superviseur (réponses aux questions de suivi, re-run de tests spécifiques).
- L'indépendance vis-à-vis des fournisseurs de sécurité existants de l'entreprise.
Pour un exchange typique enregistré PSAN, prévoir 30 k$–80 k$ pour un pentest annuel de conformité, selon la complexité de la plateforme. Les entités significatives qui font du TLPT doivent budgéter 150 k$–500 k$+ par cycle.
Pourquoi ça compte au-delà de la conformité
Les équipes qu'on accompagne et qui traitent le pentest MiCA comme du box-ticking ont le pire des deux mondes : une dépense de sécurité significative qui n'améliore pas leur posture. Les équipes qui cadrent la mission comme un vrai pentest d'abord, avec la documentation conformité comme livrable secondaire, obtiennent à la fois des systèmes plus sûrs et un dossier défendable. Le coût marginal de bien faire est faible ; le coût de mal faire, c'est de le découvrir en même temps que votre régulateur.
Si vous cadrez un pentest pour la conformité MiCA, DORA ou PSAN, réservez un appel de cadrage et nous déroulons le dossier dont vous aurez besoin avant tout démarrage des tests.