*Auteur : Eirik Salmi, Analyste Système chez **Passwork*** **Lorsqu'un acteur malveillant pénètre dans votre réseau en utilisant un nom d'utilisateur et un mot de passe légitimes, quel contrôle l'arrête ?** Pour la plupart des institutions financières, la réponse honnête est : rien ne le détecte immédiatement. L'attaquant ressemble à un utilisateur autorisé. Il se déplace latéralement, élève ses privilèges et cartographie les systèmes critiques pendant une moyenne de 186 jours avant que la violation ne soit même identifiée — et 55 jours supplémentaires pour la contenir — selon le [Rapport sur le coût des violations de données](https://www.ibm.com/reports/data-breach) d'**IBM** (2025). À ce moment-là, les dégâts opérationnels sont faits, et l'horloge réglementaire a déjà commencé à tourner. Le 17 janvier 2025, la [Directive sur la Résilience Opérationnelle Numérique (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) est entrée en application dans toute l'UE. L'article 9 du règlement fait de la sécurité des identifiants un contrôle des risques financiers contraignant, avec des conséquences de supervision pour les institutions qui ne respectent pas ces exigences. La question n'est plus de savoir si votre posture d'authentification répond aux meilleures pratiques. Il s'agit de savoir si elle respecte la loi — et si vous pouvez le prouver. Cet article retrace les exigences spécifiques de l'article 9 qui régissent la gestion des identifiants, explique pourquoi un mot de passe compromis constitue un échec de la résilience opérationnelle dans le cadre de **DORA**, et décrit les contrôles pratiques qui comblent le fossé. ## La menace que DORA a été conçue pour contrer Les identifiants volés sont le vecteur d'accès initial le plus important en 2025, représentant 22 % de toutes les violations de données, selon le [Rapport sur les enquêtes sur les violations de données](https://www.verizon.com/business/resources/reports/dbir/) de **Verizon**. Pour les institutions financières, le coût sectoriel de cette exposition s'élève en moyenne à 5,56 millions de dollars par incident, selon le Rapport sur le coût des violations de données d'**IBM** — en baisse par rapport à 6,08 millions de dollars en 2024, mais toujours le deuxième plus élevé de toutes les industries au niveau mondial. La partie offre du vol d'identifiants a été entièrement industrialisée. Les courtiers en accès initial vendent un accès vérifié aux réseaux d'entreprise pour une moyenne de 2 700 $, avec 71 % des offres incluant des identifiants à privilèges — un accès pré-emballé qui ne nécessite aucune compétence technique pour être exploité, selon les recherches de **Rapid7**. Les infostealers tels que **Lumma**, **RisePro**, **StealC**, **Vidar** et **RedLine** automatisent la récolte d'identifiants à grande échelle. Les données X-Force d'**IBM** montrent que leur livraison via le phishing a augmenté de 84 % d'une année sur l'autre en 2024, les données de 2025 indiquant une trajectoire encore plus abrupte. L'article 9 de **DORA** existe précisément pour interrompre cette chaîne. Le règlement reflète une menace documentée et continue pour la continuité opérationnelle des marchés financiers européens. ## Ce que l'article 9 de DORA exige réellement [L'article 9 de DORA](https://www.digital-operational-resilience-act.com/Article_9.html) — intitulé "Protection et Prévention" — s'inscrit dans le cadre de gestion des risques TIC imposé par l'article 6. Il énonce des obligations techniques et procédurales spécifiques que les entités financières doivent mettre en œuvre. Deux dispositions sont directement pertinentes pour la gestion des identifiants. * **L'article 9(4)(c)** exige des entités financières qu'elles "mettent en œuvre des politiques qui limitent l'accès physique ou logique aux actifs d'information et aux actifs TIC à ce qui est nécessaire pour les fonctions et activités légitimes et approuvées uniquement." C'est le principe du moindre privilège, énoncé comme une obligation légale. * **L'article 9(4)(d)** va plus loin, exigeant des entités qu'elles "mettent en œuvre des politiques et des protocoles pour des mécanismes d'authentification forte, basés sur des normes pertinentes et des systèmes de contrôle dédiés, et des mesures de protection des clés cryptographiques où les données sont chiffrées sur la base des résultats de processus approuvés de classification des données et d'évaluation des risques TIC." En décortiquant ce langage en termes opérationnels : la MFA est obligatoire. La référence aux "normes pertinentes" pointe directement vers FIDO2/WebAuthn — la norme d'authentification la plus largement déployée actuellement, résistante aux kits de phishing Adversary-in-the-Middle (AiTM), qui peuvent contourner la MFA par SMS et TOTP en temps réel. La gestion des clés cryptographiques est une exigence réglementaire. Les outils de gestion des accès à privilèges (PAM) ne sont pas explicitement nommés dans le règlement — mais les contrôles qu'ils fournissent correspondent directement aux exigences de l'article 9. L'enregistrement des sessions, le provisionnement d'accès juste-à-temps (JIT) et la gestion des identifiants à privilèges sont précisément les "systèmes de contrôle dédiés" décrits par le règlement. Les institutions qui n'ont pas déployé ces contrôles font face à un écart de conformité sur lequel les superviseurs peuvent agir. L'Autorité bancaire européenne (**ABE**) et les Normes techniques de réglementation (**ESMA**) de **DORA** fournissent des précisions supplémentaires sur les exigences de gestion des risques TIC, renforçant la base de l'article 9 avec des orientations de mise en œuvre spécifiques au secteur. ## Compromission d'identifiants comme échec de la résilience opérationnelle L'objectif déclaré de **DORA** est de garantir que les entités financières puissent résister, répondre et se remettre des perturbations TIC. Une compromission d'identifiants apparaît complètement différemment sous cet angle qu'elle ne le fait sous un angle d'incident de sécurité. Avec un temps de résidence moyen de 186 jours, un identifiant compromis ne produit pas un événement de sécurité discret. Il produit une menace soutenue et invisible pour la continuité opérationnelle — un attaquant se déplaçant latéralement, élevant ses privilèges et cartographiant les systèmes critiques tout en se faisant passer pour un utilisateur légitime. C'est une menace directe pour la continuité opérationnelle que **DORA** est conçue pour protéger. La violation du [registre national des banques françaises](https://www.bleepingcomputer.com/news/security/data-breach-at-french-bank-registry-impacts-12-million-accounts/) en janvier 2026 a concrétisé les mécanismes. Un acteur malveillant a obtenu les identifiants d'un seul fonctionnaire ayant accès à Ficoba — la base de données interministérielle contenant les enregistrements de tous les comptes bancaires ouverts en France. En utilisant uniquement ce compte, l'attaquant a accédé et extrait des données sur 1,2 million de comptes bancaires, y compris les IBAN, les noms et adresses des titulaires de compte, et les numéros d'identification fiscale. Le système affecté a été mis hors ligne, les opérations au registre ont été perturbées, et l'incident a été signalé à l'autorité française de protection des données, la **CNIL**. L'attaque n'a nécessité aucune sophistication technique. Dans le cadre de **DORA**, un incident de cette ampleur dans une entité financière déclencherait des obligations de notification obligatoire en vertu de l'article 19 — une notification initiale dans les 4 heures suivant la classification (et au plus tard 24 heures après la détection), un rapport intermédiaire dans les 72 heures, et un rapport final dans un délai d'un mois. ## La dimension tierce : les identifiants des fournisseurs sont vos identifiants Le chapitre V de **DORA** impose des obligations explicites aux entités financières concernant le risque lié aux tiers TIC. Le périmètre de conformité ne s'arrête pas aux systèmes de l'institution elle-même. La violation de [Santander](https://www.bleepingcomputer.com/news/security/snowflake-account-hacks-linked-to-santander-ticketmaster-breaches/) en mai 2024 est le point de référence européen. Des attaquants ont utilisé des identifiants volés à des employés de **Snowflake** pour accéder à une base de données contenant des données clients et employés en Espagne, au Chili et en Uruguay. Les identifiants avaient été récoltés des mois plus tôt par un malware infostealer infectant les postes de travail des sous-traitants. Aucun des comptes **Snowflake** compromis n'avait l'authentification multifacteur activée. Le point d'entrée n'était pas à l'intérieur de **Santander**. C'était la posture d'authentification faible d'un fournisseur — et elle a exposé des données appartenant à l'une des plus grandes banques européennes sans qu'un seul exploit ne soit écrit. Dans le cadre de **DORA**, une institution financière dont le fournisseur TIC critique subit une violation basée sur des identifiants s'expose à une exposition réglementaire directe. Les institutions doivent exiger contractuellement des normes d'authentification équivalentes de leurs fournisseurs et auditer la conformité par rapport à ces exigences. Un écart dans la politique de mots de passe d'un fournisseur n'est pas seulement le problème du fournisseur — c'est la responsabilité réglementaire de l'entité financière. ## Construire une gestion des identifiants conforme à DORA Le respect des exigences de l'article 9 exige un programme structuré dans quatre domaines. * **Déployez d'abord la MFA résistante au phishing.** Authentification basée sur FIDO2/WebAuthn — clés de sécurité matérielles, passkeys, authentificateurs de plateforme. Les mots de passe à usage unique par SMS et TOTP ne sont pas suffisants contre les techniques d'attaque actuelles. Imposer la MFA résistante au phishing à tous les utilisateurs, avec une rigueur particulière sur les comptes à privilèges et les chemins d'accès à distance. * **Appliquez le principe du moindre privilège.** Le provisionnement JIT — accorder un accès élevé uniquement pour la durée d'une tâche spécifique — élimine les privilèges permanents qui rendent le vol d'identifiants si dommageable. Désactivez immédiatement les comptes lors du départ d'un employé. Les comptes dormants sont parmi les vecteurs d'attaque les plus courants et les plus évitables. * **Stockez tous les identifiants.** Les mots de passe des comptes de service, les clés API et les identifiants à privilèges doivent être stockés dans un coffre-fort d'identifiants crypté et contrôlé en accès. La gestion manuelle des identifiants à grande échelle est opérationnellement irréalisable et ne produit aucune piste d'audit. Un gestionnaire de mots de passe d'entreprise