La mise à jour du cadre TIBER-EU par la Banque centrale européenne en février 2025 a marqué une étape importante pour les établissements financiers européens. Le cadre a été aligné avec les exigences de DORA relatives aux Threat-Led Penetration Tests (TLPT), afin de proposer une méthode commune pour conduire des tests réalistes, contrôlés et comparables au niveau européen. La BCE rappelle que TIBER-EU vise à organiser des cyberattaques contrôlées, fondées sur du renseignement de menace, avec l’implication coordonnée des entités testées, des autorités, des fournisseurs de threat intelligence et des red team testers.
Un changement de logique : tester la résilience réelle
Un TLPT ne doit pas être assimilé à un audit technique classique. L’objectif n’est pas seulement d’identifier des vulnérabilités, mais de vérifier si l’organisation est capable de détecter, contenir et gérer une attaque conduite comme le ferait un adversaire crédible.
Le cadre TIBER-EU 2025 précise qu’un test fondé sur le renseignement de menace doit reproduire les tactiques, techniques et procédures d’attaquants réels, à partir d’une threat intelligence spécifique à l’entité testée. Cette approche cible les personnes, les processus et les technologies, et non uniquement les systèmes exposés.
Ce que DORA change concrètement
DORA introduit une exigence de tests avancés pour certaines entités financières, notamment celles dont les fonctions sont critiques ou importantes. Les RTS relatifs aux TLPT précisent les critères d’identification des entités concernées, les exigences applicables aux testeurs internes, le cadrage, la méthodologie, les résultats, la clôture, la remédiation et la coopération entre autorités.
L’enjeu n’est donc pas de produire un exercice de conformité supplémentaire, mais de structurer un test capable d’apporter des résultats exploitables. Le cadre TIBER-EU sert ici de méthode opérationnelle pour réaliser un TLPT dans un environnement contrôlé, qualitatif et sécurisé.
Cadrer le périmètre : partir des fonctions critiques
La première difficulté consiste à définir un périmètre pertinent. Un TLPT efficace ne part pas d’une liste de serveurs ou d’applications, mais des fonctions critiques ou importantes : paiements, compensation, services clients essentiels, gestion des sinistres, opérations de marché, systèmes d’identité ou chaînes de validation.
À partir de ces fonctions, l’organisation doit identifier les systèmes sous-jacents, les prestataires impliqués, les dépendances cloud ou SaaS, les flux critiques et les équipes opérationnelles concernées. La documentation TIBER-EU prévoit notamment des éléments de cadrage permettant à la Control Team de formaliser les fonctions critiques, les systèmes associés et les objectifs du test.
Gouvernance : Control Team, White Team et responsabilités
La réussite d’un TLPT dépend fortement de sa gouvernance. Le dispositif doit limiter le nombre de personnes informées afin de préserver le réalisme, tout en garantissant une maîtrise du risque opérationnel.
Le cadre TIBER-EU prévoit une organisation structurée autour d’équipes dédiées, notamment la Control Team, chargée de piloter le test, d’encadrer les prestataires, de veiller au respect des règles d’engagement et de gérer les éventuels incidents durant l’exercice. La guidance BCE sur la Control Team complète les exigences minimales DORA par des recommandations opérationnelles issues de la pratique TIBER-EU.
Fournisseurs de threat intelligence et red team testers
La qualité du test dépend directement de la qualité des prestataires sélectionnés. Le fournisseur de threat intelligence doit produire une analyse spécifique à l’entité : adversaires plausibles, scénarios réalistes, techniques observées, actifs ciblables et hypothèses d’attaque.
Les red team testers traduisent ensuite cette analyse en opérations contrôlées. La BCE a publié une guidance spécifique sur l’achat de ces services, couvrant les exigences de sélection des fournisseurs de threat intelligence et des red team testers, afin que le test puisse être reconnu dans le cadre TIBER-EU.
Rules of engagement : éviter l’exercice incontrôlé
Un TLPT réaliste n’est pas un test sans limites. Les règles d’engagement doivent préciser les actions autorisées, les systèmes exclus, les horaires, les points d’arrêt, les procédures d’urgence, les modalités de communication et la gestion des incidents réels pouvant survenir pendant le test.
Ce cadrage protège l’entité testée, les clients, les prestataires et les infrastructures critiques. Il évite également qu’un exercice utile ne se transforme en perturbation opérationnelle ou en risque juridique.
Critères de succès : mesurer la détection et la réponse
Le succès d’un TLPT ne se limite pas au fait que la red team atteigne ou non un objectif. Les critères utiles portent sur la capacité de l’organisation à détecter les signaux faibles, à qualifier l’incident, à coordonner SOC, CSIRT, IT et métiers, puis à contenir l’attaque.
Les indicateurs à suivre peuvent inclure le délai de détection, la qualité des alertes, le niveau de corrélation, la rapidité d’escalade, la pertinence des décisions prises et la capacité à préserver les fonctions critiques.
Exploiter les résultats : le point souvent décisif
Un TLPT mal exploité produit un rapport de plus. Un TLPT bien exploité alimente une feuille de route de résilience.
Les résultats doivent être traduits en plan de remédiation priorisé : durcissement IAM, segmentation, amélioration des règles SOC, renforcement des playbooks, revue des dépendances fournisseurs, amélioration de la journalisation ou mise à jour des procédures de crise.
Les RTS DORA insistent sur les phases de résultats, clôture et remédiation. Le test doit donc aboutir à des décisions suivies, et non à une simple restitution technique.
Perspective Forum des Compétences
L’alignement TIBER-EU / DORA donne aux établissements financiers un cadre plus homogène pour conduire des tests réalistes. Mais la valeur du dispositif dépendra de son exécution.
Le risque principal est de transformer le TLPT en exercice documentaire : périmètre trop étroit, scénario générique, red team peu contextualisée, blue team partiellement informée, ou remédiations non suivies.
Pour les banques et assurances, l’enjeu est de conserver la logique initiale du TIBER : simuler une attaque crédible, mesurer les capacités réelles de détection et de réponse, puis exploiter les résultats pour prioriser les investissements de résilience.
Un test d’intrusion classique vise principalement à identifier des vulnérabilités techniques sur un périmètre défini (application, infrastructure, API, poste de travail, etc.).
Un Threat-Led Penetration Test (TLPT) cherche à reproduire une attaque réaliste basée sur des scénarios de menace crédibles et contextualisés.
Le TLPT évalue :
- la détection SOC ;
- les capacités de réponse ;
- les escalades internes ;
- la coordination de crise ;
- les dépendances tiers ;
- la résilience des fonctions critiques.
Le cadre TIBER-EU précise qu’un TLPT doit s’appuyer sur une phase préalable de threat intelligence spécifique à l’entité testée.
TIBER-EU fournit une méthodologie structurée pour conduire des exercices réalistes dans le secteur financier européen.
Le cadre définit notamment :
- les rôles (Control Team, White Team, Red Team) ;
- les règles d’engagement ;
- les phases du test ;
- les exigences de confidentialité ;
- les modalités de remédiation ;
- les interactions avec les autorités compétentes.
La mise à jour 2025 aligne le cadre avec les exigences DORA relatives aux TLPT.
Non.
DORA prévoit que certaines entités financières devront réaliser des tests avancés fondés sur la menace selon :
- leur taille ;
- leur criticité ;
- leur profil de risque ;
- leur importance systémique ;
- leurs fonctions critiques ou importantes.
La sélection peut être encadrée par les autorités compétentes nationales
Il s’agit des processus dont l’indisponibilité ou la compromission aurait un impact significatif sur :
- les clients ;
- les opérations financières ;
- la continuité d’activité ;
- la stabilité du marché ;
- les obligations réglementaires.
Exemples fréquents :
- paiements ;
- compensation ;
- opérations de marché ;
- authentification ;
- systèmes SWIFT ;
- gestion des sinistres ;
- services clients critiques.
Le périmètre du TLPT doit partir des fonctions critiques, et non uniquement des actifs techniques.

