TIBER-EU : red team BCE, TIBER-FR et TLPT DORA, guide 2026

TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) est le cadre européen publié par la Banque centrale européenne en mai 2018 pour conduire des tests red team fondés sur le renseignement sur la menace, directement sur les systèmes de production des entités financières. Un test TIBER-EU reproduit les tactiques, techniques et procédures (TTP) d'attaquants réels contre les fonctions critiques d'une banque, d'un assureur ou d'une infrastructure de marché, sans prévenir les équipes de défense. Depuis l'entrée en application du règlement DORA le 17 janvier 2025, cette méthode sert de mode opératoire aux tests de pénétration fondés sur la menace (TLPT), imposés aux entités financières désignées au moins tous les trois ans. En France, le cadre se décline en TIBER-FR, porté par la Banque de France, l'ACPR et l'AMF. Pour situer ce dispositif parmi les autres formes d'évaluation offensive, consultez notre comparatif red team, pentest et bug bounty.

TIBER-EU : définition, origine et objectifs du cadre de la BCE

Le cadre TIBER-EU a été élaboré conjointement par la BCE et les banques centrales nationales de l'Union, puis approuvé par le Conseil des gouverneurs. Selon la page officielle TIBER-EU de la Banque centrale européenne, il a été publié en mai 2018 et adopté depuis par une vingtaine de juridictions européennes, dont la France, l'Allemagne, l'Italie, l'Espagne et les Pays-Bas.

Le cadre poursuit plusieurs objectifs complémentaires : renforcer la cyber-résilience des entités et du secteur financier, harmoniser la manière dont ces tests sont conduits en Europe, faciliter la reconnaissance mutuelle des résultats entre autorités et réduire ainsi la charge des groupes présents dans plusieurs pays. Il reste volontairement « agnostique » : une juridiction peut l'appliquer à d'autres secteurs critiques que la finance.

TIBER-EU vise d'abord les entités d'importance systémique, nationales ou européennes, dont la maturité informatique est suffisante pour supporter une attaque simulée de longue durée. La BCE précise que l'intervalle de référence entre deux tests est de trois ans, compte tenu des ressources mobilisées et du coût de chaque exercice pour l'entité testée comme pour l'autorité.

Un test sans « réussite » ni « échec »

Un test TIBER-EU ne délivre aucun verdict de réussite ou d'échec. Son but est de révéler les forces et les faiblesses du dispositif de cyber-résilience, avec un accent explicite sur l'effet d'apprentissage. L'entité testée en tire une vision de bout en bout de ses failles humaines, organisationnelles et techniques, ainsi qu'une évaluation de la menace qu'elle peut réutiliser dans sa veille.

Red team TIBER-EU ou pentest classique : deux questions différentes

Un test d'intrusion classique évalue en détail les vulnérabilités techniques et de configuration, souvent sur un système isolé. Il ne reproduit pas le scénario complet d'une attaque ciblée contre toute l'entité, ses personnes, ses processus et ses technologies. Les audits ponctuels décrits dans notre guide du pentest d'entreprise et du rapport de test d'intrusion restent utiles, mais ils ne répondent pas à la même question.

Un red team TIBER-EU s'appuie sur un renseignement sur la menace sur mesure : quels groupes ciblent réellement ce type d'établissement, avec quelles techniques et dans quel but. Les scénarios d'attaque sont construits à partir de ce renseignement, puis exécutés de manière furtive sur la production. La question posée devient : un adversaire compétent, motivé et doté de moyens peut-il atteindre nos fonctions critiques sans être détecté ?

Mise à jour TIBER-EU 2025 : ce qui a changé avec DORA

L'Eurosystème a annoncé le 11 février 2025 la mise à jour du cadre TIBER-EU afin de l'aligner sur les normes techniques de réglementation de DORA relatives aux TLPT. Le document de référence révisé, daté de janvier 2025, intègre désormais l'ensemble des livrables et étapes exigés pour un test réglementaire, ce qui en fait un véritable manuel opérationnel du TLPT.

Les principaux changements annoncés par la BCE portent sur la structure du processus, sur la terminologie et sur la documentation d'accompagnement mise à la disposition des autorités, des entités testées et des prestataires de renseignement et de red team :

• alignement des étapes du processus sur les livrables issus des normes techniques DORA, avec des délais stricts pour leur remise ;
• passage du purple teaming au rang d'exigence obligatoire, comme le prévoient ces normes techniques ;
• harmonisation du vocabulaire avec DORA : la « White Team » devient la Control Team, ou équipe de contrôle ;
• publication de guides complémentaires : achat des prestations, équipe de contrôle, purple teaming, rapport de renseignement ciblé ;
• possibilité pour une autorité nationale de publier un document d'implémentation court plutôt qu'un guide national complet.

Conséquence pratique : le document cadre de la BCE indique qu'une entité qui mène un test selon une implémentation nationale ou européenne de TIBER-EU satisfait aux exigences du TLPT de DORA, à condition de respecter les obligations formelles fixées par son autorité compétente. En 2026, les deux démarches ne sont donc plus parallèles, mais imbriquées.

TIBER-EU et TLPT de DORA : le « quoi » réglementaire et le « comment » méthodologique

Le règlement (UE) 2022/2554, dit DORA, consacre ses articles 26 et 27 aux tests avancés. L'article 26 impose aux entités financières désignées un test d'intrusion fondé sur la menace au moins tous les trois ans, l'autorité compétente pouvant réduire ou augmenter cette fréquence selon le profil de risque. L'article 27 fixe les exigences applicables aux testeurs.

Chaque TLPT couvre plusieurs, voire la totalité, des fonctions critiques ou importantes de l'entité et se déroule sur les systèmes de production qui les soutiennent. L'entité évalue elle-même quelles fonctions inclure ; le périmètre qui en résulte est validé par l'autorité. Lorsque des prestataires tiers de services TIC sont dans le périmètre, l'entité organise leur participation et reste entièrement responsable du respect du règlement.

DORA prévoit aussi le test groupé : lorsqu'une participation directe d'un prestataire TIC risquerait de dégrader ses services à d'autres clients, ce prestataire peut contracter lui-même avec un testeur externe, sous la direction d'une entité financière désignée. À l'issue du test, l'autorité délivre une attestation qui permet la reconnaissance mutuelle entre autorités compétentes.

Le règlement délégué (UE) 2025/1190, miroir réglementaire de TIBER-EU

Les normes techniques de réglementation (RTS) prévues par l'article 26, paragraphe 11, du règlement DORA sur la résilience opérationnelle numérique ont pris la forme du règlement délégué (UE) 2025/1190 publié sur EUR-Lex. Adopté par la Commission le 13 février 2025, il a été publié au Journal officiel le 18 juin 2025 et s'applique depuis le 8 juillet 2025, vingtième jour suivant sa publication.

Son premier considérant est explicite : le texte a été rédigé conformément à TIBER-EU et reprend la méthodologie, le processus et la structure du TLPT tels que décrits dans ce cadre. Les entités soumises au TLPT peuvent appliquer TIBER-EU ou l'une de ses implémentations nationales, dans la mesure où celles-ci restent cohérentes avec DORA et avec le règlement délégué.

Une répartition des rôles entre le droit et la méthode

Le guide national TIBER-FR résume bien cette articulation : DORA et son règlement délégué définissent ce qui doit être fait pour qu'un test soit conforme, tandis que TIBER-EU et sa déclinaison française décrivent comment l'entité et l'autorité opérationnalisent concrètement le test. Le tableau ci-dessous synthétise les différences entre un pentest classique, un test TIBER-EU volontaire et un TLPT réglementaire.

Quelles entités financières doivent réaliser un TLPT ?

DORA confie aux autorités compétentes le soin de désigner les entités tenues de réaliser un TLPT. Elles tiennent compte de l'incidence des services fournis sur le secteur financier, des enjeux de stabilité financière, du caractère systémique de l'entité et de son profil de risque lié aux technologies de l'information et de la communication (TIC). Les microentreprises et les entités relevant du cadre simplifié de l'article 16 sont exclues.

L'article 2 du règlement délégué (UE) 2025/1190 dresse une liste d'entités que l'autorité doit, par défaut, soumettre au TLPT, sauf si son analyse conclut que l'impact, les enjeux de stabilité ou le profil de risque ne le justifient pas :

• les établissements de crédit identifiés comme établissements d'importance systémique mondiale ou autres établissements d'importance systémique, ou qui en font partie ;
• les établissements de paiement ayant dépassé 150 milliards d'euros d'opérations de paiement au cours de chacune des deux années civiles précédentes ;
• les établissements de monnaie électronique au-delà de 150 milliards d'euros d'opérations de paiement ou de 40 milliards d'euros de monnaie électronique en circulation ;
• les dépositaires centraux de titres et les contreparties centrales ;
• certaines plates-formes de négociation électroniques, selon leur part de marché nationale ou européenne ;
• les entreprises d'assurance et de réassurance qui dépassent des seuils cumulés de primes brutes émises, de provisions techniques et d'actifs.

L'autorité peut aussi désigner d'autres catégories, au vu de leur profil de risque et de leur importance pour le secteur : le règlement délégué cite par exemple les prestataires de services sur crypto-actifs agréés au titre de MiCA. Pour replacer cette obligation dans l'ensemble des exigences du règlement, consultez notre analyse de l'impact de DORA sur le secteur financier français en 2026.

Les acteurs d'un test TIBER-EU : cinq équipes aux rôles cloisonnés

La BCE décrit cinq équipes. La Blue Team regroupe les personnes qui défendent l'entité et dont les capacités sont testées sans qu'elles soient prévenues. Le fournisseur de renseignement sur la menace étudie les menaces et effectue la reconnaissance. Les testeurs red team mènent l'attaque simulée. L'équipe de contrôle pilote le test au sein de l'entité, avec l'équipe cyber TIBER de l'autorité.

Équipe de contrôle et Blue Team

L'équipe de contrôle doit rester aussi réduite que possible pour préserver le secret. Son responsable, le Control Team Lead, gère le test au quotidien et dispose d'un mandat suffisant pour arbitrer, avec un accès à l'organe de direction. Le règlement délégué impose le besoin d'en connaître, des engagements de confidentialité et, lorsque c'est possible, l'usage d'un nom de code pour désigner l'exercice.

La Blue Team englobe le SOC, les équipes d'infrastructure, le support et la gestion d'incidents, y compris chez les prestataires concernés. Si elle détecte l'attaque, l'équipe de contrôle doit en être informée et contenir l'escalade de la réponse à incident. Aucun membre de la Blue Team ne peut être mis dans la confidence sans consultation préalable des test managers de l'autorité.

Équipe cyber, test managers et prestataires

Pour chaque test, l'autorité désigne au moins un test manager et un suppléant, issus de son équipe cyber, appelée TCT. Le document cadre TIBER-EU donne au test manager le pouvoir d'invalider un test conduit hors des exigences obligatoires ou dans un esprit contraire au cadre : aucune attestation n'est alors délivrée et le test n'est pas reconnu par les autres juridictions.

Le fournisseur de renseignement est toujours externe à l'entité. Les testeurs red team sont de préférence externes ; ils doivent maîtriser la reconnaissance, l'ingénierie sociale, l'intrusion physique, l'analyse de vulnérabilités et le développement d'exploits. Les compétences mobilisées dépassent largement celles d'un pentest de réseau interne mené en mode red team : la furtivité et la durée changent la nature de l'exercice.

Les trois phases d'un test TIBER-EU, du cadrage à l'attestation

Un test TIBER-EU, comme un TLPT, suit trois phases : préparation, test, puis clôture. La phase de test se divise elle-même en deux sous-phases, le renseignement ciblé puis le red team actif. Chaque étape produit des livrables standardisés, validés par l'équipe de contrôle et par les test managers, ce qui permet de délivrer l'attestation finale.

Le règlement délégué impose à l'autorité TLPT de participer à toutes les phases du test. Concrètement, ses test managers valident le périmètre, le choix des prestataires, le rapport de renseignement et le plan de test, suivent les points d'avancement hebdomadaires pendant le red team actif, puis prennent part aux ateliers de clôture. Cette présence continue fonde l'attestation délivrée à la fin.

Préparation d'un test TIBER-EU : périmètre, drapeaux et prestataires

Un test TIBER-EU mené comme TLPT, c'est-à-dire comme test de pénétration fondé sur la menace au sens de DORA, démarre par une notification de l'autorité compétente. L'entité constitue son équipe de contrôle, analyse les risques, définit le périmètre et les « drapeaux », ces objectifs clés que les testeurs chercheront à atteindre dans les systèmes soutenant les fonctions critiques. Le périmètre est approuvé par un dirigeant ou un membre du conseil, puis validé par l'équipe cyber. Le guide TIBER-FR limite cette phase à six mois.

La préparation inclut l'achat des prestations de renseignement et de red team. Les test managers sont consultés et peuvent s'opposer au choix d'un prestataire. Un même cabinet peut assurer les deux rôles, à condition que ses équipes de renseignement et de red team restent séparées, afin que les testeurs n'influencent pas l'analyse de la menace.

Phase de test TIBER-EU : renseignement ciblé puis red team actif

Le fournisseur de renseignement produit un rapport de renseignement ciblé sur la menace (Targeted Threat Intelligence, TTI), en s'appuyant le cas échéant sur un panorama générique de la menace fourni par l'autorité. Il identifie les surfaces d'attaque de l'entité et les acteurs de menace pertinents, puis propose des scénarios. D'après le règlement délégué, cette collecte dure en général environ quatre semaines.

Les testeurs traduisent ensuite ces scénarios en plan de test red team, puis passent à l'exécution. Le règlement délégué fixe la durée de la phase active à au moins 12 semaines, ajustée selon le nombre de parties, le périmètre et les ressources de l'entité. Les testeurs enchaînent reconnaissance, préparation, livraison, exploitation, déplacement latéral et actions sur objectif, dans les limites éthiques et légales convenues.

Lorsque les testeurs bloquent, l'équipe de contrôle peut leur fournir, avec l'accord de l'autorité, un coup de pouce appelé « leg-up » : une information ou un accès qui permet de poursuivre le scénario. En dernier recours, un purple teaming limité peut aussi être organisé pendant la phase active, par exemple en « catch-and-release » ou sous forme de preuve de concept collaborative.

Clôture d'un test TIBER-EU : replay, purple teaming et attestation

La phase de clôture transforme l'attaque simulée en apprentissage. La Blue Team, c'est-à-dire les équipes de défense jusque-là tenues à l'écart, est informée, les rapports sont partagés et toutes les parties rejouent les étapes clés. Le guide TIBER-FR précise que l'exercice de purple teaming de clôture, désormais obligatoire, doit se tenir dans les dix semaines suivant la fin du test actif. Les principaux livrables s'enchaînent dans cet ordre :

1. rapport de test red team, qui détaille l'approche, les chemins d'attaque et les constats ;
2. rapport de la Blue Team, qui confronte ses détections et réactions aux actions des testeurs ;
3. atelier de replay, puis exercice de purple teaming réunissant testeurs et défenseurs ;
4. rapport de synthèse du test et plan de remédiation, partagés avec l'autorité ;
5. retour d'expérience croisé entre toutes les parties, puis attestation délivrée par l'autorité.

Pour organiser ces ateliers sans brider l'apprentissage, inspirez-vous des pratiques décrites dans notre guide de la collaboration purple team entre SOC et red team. L'attestation, prévue par l'article 26, paragraphe 7, de DORA, est la pièce qui permet aux autres autorités de reconnaître le test.

TIBER-FR : la déclinaison française de TIBER-EU

La Banque de France et l'Autorité de contrôle prudentiel et de résolution (ACPR) ont décidé conjointement de mettre en œuvre TIBER-FR, version nationale du cadre TIBER-EU, au titre de leur mandat de stabilité financière. La page de la Banque de France consacrée à la surveillance du risque cyber présente TIBER-FR comme un complément opérationnel aux exigences TLPT fixées par les normes techniques de DORA.

Le guide national d'implémentation TIBER-FR, dans sa version 2025, intègre les spécificités du droit français au cadre européen. Sauf mention contraire, les principes de TIBER-EU s'appliquent sans modification. Le guide sert à la fois aux TLPT obligatoires de DORA et aux tests volontaires proposés à des entités non désignées.

Une équipe cyber commune : la TCT-FR

Pour garantir une approche cohérente et mutualiser les compétences, notamment pour les entités supervisées par plusieurs autorités, la Banque de France, l'ACPR et l'Autorité des marchés financiers (AMF) ont créé une équipe commune, la TCT-FR, sans remettre en cause la compétence propre de chaque autorité TLPT. Les entités sont désignées par l'une de ces trois autorités, puis reçoivent de la TCT-FR une lettre fixant la date de démarrage.

La TCT-FR fournit aussi un panorama générique de la menace pour le secteur financier français. Ce document décrit les acteurs de menace avancés et leurs techniques, et sert de base aux fournisseurs de renseignement pour rédiger les rapports ciblés propres à chaque entité. Un test TIBER-FR s'inscrit en principe dans un cycle de trois ans, que l'autorité peut raccourcir ou allonger.

Le cas des banques importantes supervisées par la BCE

Le guide TIBER-FR ne s'applique pas aux établissements de crédit classés « importants » par le mécanisme de surveillance unique. Pour eux, l'autorité TLPT est la BCE, qui a adopté TIBER-EU et publié un guide de mise en œuvre dédié, le TIBER-EU SSM Implementation Guide. DORA impose par ailleurs à ces établissements de recourir exclusivement à des testeurs externes.

TIBER-FR et droit français : SIIV, PASSI et activités interdites

Le guide TIBER-FR, déclinaison française du cadre européen publiée par la Banque de France, rappelle les obligations liées aux opérateurs d'importance vitale (OIV). Si l'équipe de contrôle place des drapeaux sur des systèmes d'information d'importance vitale (SIIV), les prestataires doivent figurer parmi les prestataires d'audit de la sécurité des systèmes d'information qualifiés par l'ANSSI au titre de la loi de programmation militaire (PASSI LPM), sans sous-traitance hors de ce cercle ou hors de l'Union.

Le rapport de test n'a pas à être transmis spontanément à l'ANSSI, mais doit pouvoir lui être communiqué sur demande. Pour un OIV qui ne place aucun drapeau sur un SIIV, le guide recommande simplement des prestataires qualifiés PASSI et établis dans l'Union. Le guide interdit enfin la destruction d'équipements, la modification incontrôlée de données, la mise en péril des services critiques, l'extorsion, les menaces ou la corruption d'employés et la divulgation des résultats.

Exigences TIBER-EU et DORA applicables aux prestataires et aux testeurs

L'article 27 de DORA réserve la conduite d'un TLPT à des testeurs qui réunissent cinq conditions cumulatives. Ces critères visent à confier un exercice risqué, mené en production, à des équipes dont la compétence et la solidité ont été démontrées :

• posséder l'aptitude et la réputation les plus élevées ;
• justifier de capacités techniques et organisationnelles et d'une expertise en renseignement sur la menace, en tests d'intrusion et en red team ;
• être certifiés par un organisme d'accréditation d'un État membre ou adhérer à des codes de conduite ou cadres éthiques formels ;
• fournir une assurance indépendante ou un rapport d'audit sur la bonne gestion des risques du test, dont la protection des informations confidentielles ;
• être couverts par une assurance de responsabilité civile professionnelle, y compris contre la mauvaise conduite et la négligence.

Le règlement délégué précise ces attentes. L'équipe de renseignement comprend au moins un responsable justifiant de cinq ans d'expérience et un second membre en justifiant deux ; le prestataire fournit au moins trois références. L'équipe red team externe réunit un responsable de cinq ans d'expérience et au moins deux testeurs de deux ans chacun, avec au moins cinq références.

Testeurs internes : une exception encadrée

DORA autorise les testeurs internes, mais l'entité doit alors faire appel à un testeur externe tous les trois tests. Le recours interne exige l'approbation de l'autorité, qui vérifie les ressources disponibles et l'absence de conflit d'intérêts, et le fournisseur de renseignement reste externe. Une équipe mixte, mêlant internes et externes, compte comme un test réalisé avec des testeurs internes.

Le document cadre TIBER-EU ajoute des garde-fous : pas deux tests consécutifs avec des testeurs internes, une équipe d'au moins trois personnes employées par l'entité ou son prestataire intragroupe depuis douze mois, et l'absence de tout rôle dans la réponse à incident. La BCE recommande d'adjoindre au moins un responsable de test externe expérimenté pour conserver un regard neuf.

Gestion des risques et confidentialité : tester la production sans la mettre en danger

Tester des fonctions critiques en production comporte des risques réels : déni de service, arrêt imprévu, dommages aux systèmes ou perte, modification et divulgation de données. L'article 5 du règlement délégué impose donc à l'équipe de contrôle une analyse des risques dès la préparation, revue tout au long du test, y compris les impacts possibles sur le secteur financier et sur la stabilité financière.

Cette analyse couvre au minimum l'accès des prestataires à des informations sensibles, le risque de non-conformité privant l'entité d'attestation, l'escalade de crise, les effets du red team et de la Blue Team sur les activités critiques et la restauration incomplète des systèmes. En pratique, ces risques se traduisent par des règles d'engagement précises, connues de tous les acteurs informés.

À la fin du test, les prestataires suppriment de manière sécurisée les mots de passe et clés compromis et signalent les comptes touchés. Les testeurs désactivent leurs infrastructures de commande et de contrôle et retirent les implants déposés. Pour aider vos équipes à repérer ce type de persistance, consultez notre analyse des portes dérobées sur Windows Server 2025.

Le guide TIBER-FR impose aux prestataires de restituer ou de détruire les informations confidentielles au plus tard trois jours après la fin de la mission, avec une attestation écrite. Pendant le test, le partage des identifiants et des secrets entre équipe de contrôle et testeurs doit lui aussi être maîtrisé ; les limites des liens à usage unique sont détaillées dans notre guide sur les attaques visant les services de secrets éphémères.

# Extrait de règles d'engagement d'un TLPT (gabarit de gouvernance, sans contenu offensif)
test:
  nom_de_code: "PROJET-ORION"          # aucun lien avec l'entité
  cadre: "TIBER-FR / DORA art. 26-27"
  autorite_tlpt: "TCT-FR"
  phase_active: { debut: "2027-03-01", duree_min_semaines: 12 }
perimetre:
  fonctions_critiques: ["paiements de détail", "tenue de compte"]
  drapeaux_valides_par: ["dirigeant sponsor", "test manager"]
  hors_perimetre: ["systèmes de clients tiers", "environnements de secours"]
garde_fous:
  interdits: ["destruction", "modification incontrôlée", "extorsion",
              "menace ou corruption d'employés", "divulgation des résultats"]
  arret_d_urgence: { declencheur: "impact production", delai_max_min: 15 }  # à fixer avec l'équipe de contrôle
  escalade: ["responsable équipe de contrôle", "suppléant", "test manager"]
fin_de_test:
  restitution_donnees_jours: 3
  actions: ["purge des secrets", "désactivation C2", "retrait des implants",
            "liste des comptes compromis remise à l'équipe de contrôle"]

Se préparer à un TLPT TIBER-EU : feuille de route défensive pour 2026

Le cadre TIBER-EU cible des entités suffisamment matures sur le plan informatique. Un test lancé alors que la journalisation est lacunaire ou que le SOC manque de visibilité produira surtout des constats déjà connus. En 2026, la préparation se joue donc autant sur les fondamentaux de détection que sur la gestion de projet du test lui-même.

1. Cartographier les fonctions critiques ou importantes, leurs systèmes, processus et prestataires TIC, en cohérence avec le registre d'information DORA.
2. Désigner le responsable de l'équipe de contrôle et son suppléant, définir le sponsor au niveau de la direction et formaliser le circuit d'escalade.
3. Vérifier la couverture de journalisation et de détection sur les systèmes candidats au périmètre, y compris chez les prestataires.
4. Structurer une fonction de veille sur la menace capable d'exploiter le rapport de renseignement ciblé après le test.
5. Préparer un processus de suivi des remédiations, avec des responsables, des échéances et un reporting vers la direction.

Les ateliers de replay et de purple teaming gagnent à être répétés à blanc. Un environnement isolé permet de vérifier que les journaux attendus remontent bien au SIEM et que les analystes savent reconstituer une chronologie, sans jamais toucher à la production ni anticiper les scénarios confidentiels du test réel.

Retour terrain : Cas typique rencontré en mission — l'équipe de contrôle, constituée trop largement, inclut des responsables proches du SOC et doit être resserrée pour préserver le secret. Le cadrage bute ensuite sur les prestataires TIC qui hébergent des fonctions critiques, dont l'accord tarde. À la clôture, les analystes, informés après coup, vivent parfois le replay comme un jugement : poser d'emblée un cadre d'apprentissage, sans recherche de coupable, transforme la qualité du purple teaming.

Retour terrain : Cas typique rencontré en mission — entre la notification et la validation du périmètre, plusieurs mois s'écoulent souvent, consommés par la cartographie des fonctions critiques et la sélection des prestataires de renseignement et de red team. Le démarrage de la phase active glisse ensuite au gré des disponibilités de l'équipe de contrôle. Côté remédiation, l'écart le plus fréquent touche les mesures structurelles, segmentation ou refonte des comptes à privilèges, reportées faute de budget. Je recommande d'associer à chacune un financement dédié et un jalon de re-test.

À lire aussi : la méthodologie OSSTMM ; l'émulation d'adversaire avec Atomic Red Team.

Questions fréquentes

Conclusion

TIBER-EU est passé en sept ans du statut de bonne pratique volontaire à celui de méthode de référence d'une obligation légale. Avec DORA et le règlement délégué (UE) 2025/1190, les entités financières désignées doivent organiser au moins tous les trois ans un red team fondé sur la menace, encadré par une autorité, mené en production et conclu par un purple teaming et un plan de remédiation suivi.

Les organisations qui en tirent le plus de valeur sont celles qui préparent la gouvernance, la détection et le suivi des remédiations avant même la notification. Pour situer ce test parmi les autres approches offensives, relisez notre comparatif entre red team, pentest et bug bounty, puis évaluez vos priorités de préparation.