TIBER-EU: What Europe's Threat-Led Red Team Framework Actually Tests
TIBER-EU turns red teaming from a vendor demo into a regulated, intelligence-driven exercise with mutual recognition across Europe. Here is how the mechanism works, who plays which role, and what it means under DORA.
Most red team reports end up in a drawer. TIBER-EU was built on the premise that they shouldn't — that a controlled attack against a financial institution should produce something an authority can recognise, another jurisdiction can trust, and the entity itself can act on. Understanding how the framework is constructed tells you a great deal about what a serious adversary simulation is supposed to look like.
What TIBER-EU actually is
TIBER-EU is a European framework for threat intelligence-based ethical red-teaming, developed jointly by the European Central Bank and the EU's national central banks, approved by the ECB Governing Council and first published in May 2018. It is not a tool, a certification or a scanner. It is a set of guidance, templates and role definitions that tell authorities, entities, threat intelligence providers and red teams how to work together to test and improve cyber resilience through controlled cyberattacks.
The defining characteristic is the word intelligence-based. A generic penetration test starts from an assumed attacker and a checklist. A TIBER-EU test starts from bespoke threat intelligence about who would realistically target this entity, how they operate, and what they would go after. The red team then mimics those specific tactics, techniques and procedures against the entity's critical functions — its people, its processes and its technology — rather than against whatever happens to be in scope on a spreadsheet.
Equally important is what the outcome is not. There is no pass or fail. The framework is explicit that the purpose is to reveal strengths and weaknesses and to create a learning effect that lifts the entity to a higher level of cyber maturity. That framing matters operationally: it removes the incentive to hide findings, which is precisely the incentive that ruins most internal security exercises.
The five teams and why the split matters
TIBER-EU distributes a test across five distinct groups, each with defined responsibilities. The separation is not bureaucratic theatre — it is what makes the exercise credible.
| Team | Role | Knows about the test? |
|---|---|---|
| Blue team | Entity staff whose prevention, detection and response are tested | No |
| Threat intelligence provider | Maps threats and performs reconnaissance on the entity | Yes |
| Red team | Executes the simulated attack on critical functions | Yes |
| Control team | Small group inside the entity that leads and manages the test | Yes |
| TIBER cyber team | Authority-side oversight, ensures framework compliance | Yes |
The blue team's lack of foreknowledge is the whole point. If the defenders know a test is running, you are measuring their ability to perform for an audience, not their ability to detect an intrusion at 3am on a Tuesday. The control team is the pressure valve: a deliberately small group inside the entity who do know, who manage risk during the exercise, and who work alongside the TIBER cyber team from the authority. That last relationship is what enables mutual recognition — the authority can attest to the test because it helped oversee it.
Note: The control team is intentionally tiny. Every additional person who knows converts a realistic detection test into a coordination exercise, and the framework's own control team guidance is worth reading before you assemble yours.
From initiation to attestation
A TIBER-EU test is an end-to-end process, and the framework supplies templates and guidance for each stage rather than leaving entities to improvise. The phases run through initiation, scoping, threat intelligence, red-team testing (itself split into planning and reporting), blue team report creation, and remediation plan creation. The output is formalised in a test summary report and an attestation.
That pipeline is where the framework earns its keep. Scoping forces the entity to define its critical functions — the things whose failure would actually hurt, not the systems that are easiest to reach. The threat intelligence phase produces a targeted threat profile that the red team then has to honour. The blue team report is a formal artefact in its own right: it captures what defenders saw, when, and what they did, which is often more revealing than the red team's narrative. The remediation plan closes the loop, and the attestation is what makes the whole thing portable across borders.
Why mutual recognition is the quiet innovation
A large financial group operating in several countries would otherwise face the prospect of repeated, near-identical red-team exercises demanded by different supervisors. Because TIBER-EU harmonises the approach and standardises the artefacts, a test conducted to the framework in one jurisdiction can be recognised by relevant authorities elsewhere. Entities active in multiple jurisdictions can even participate in joint tests with multiple TIBER-EU cyber teams. For a group with cross-border activities falling within several regulators' remits, this is a direct reduction in duplicated effort and cost.
The DORA connection
The framework was updated in 2024 to align fully with the Regulatory Technical Standards on threat-led penetration testing under the Digital Operational Resilience Act. This is the practical hook for most readers: DORA imposes TLPT obligations, and adopting TIBER-EU is a documented route to meeting them. The ECB has published material specifically on how adopting the framework helps fulfil those requirements.
If your organisation is scoping a DORA TLPT programme, TIBER-EU effectively hands you a ready-made operating model — roles, phases, templates, oversight and attestation — instead of a blank page. The alignment also means the vocabulary of your test will match what a supervisor expects to see.
Caution: Framework alignment does not mean a generic pentest report will satisfy a TLPT obligation. The intelligence phase, the blue team report and the attestation are structural requirements, not optional extras bolted on at the end.
Who it is for — and who it is not
TIBER-EU is designed for entities providing core financial infrastructure, including those whose cross-border activities sit within the remits of several authorities, and for national and supranational authorities themselves. But the framework is explicitly usable for entities in all critical sectors, not just financial services. The ECB also applies it directly, and ECB Banking Supervision has implemented it at European level.
Adoption is broad. The framework has been taken up in Austria, Belgium, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Iceland, Ireland, Italy, Liechtenstein, Luxembourg, Malta, the Netherlands, Norway, Portugal, Romania, Slovakia, Spain and Sweden, with other jurisdictions in the process of adopting it or expected to follow. National TIBER-EU cyber teams run tests with entities in their own jurisdictions.
The framework combines mandatory requirements with optional ones that jurisdictions can adapt to local specificities. That flexibility is deliberate: it lets a national authority shape the test to its market without breaking the harmonisation that makes mutual recognition possible.
Procurement is where tests fail early
One of the more underrated parts of the framework is the TIBER-EU Guidance for Service Provider Procurement. It exists because the quality of a threat-led test lives or dies on the two providers you hire: the threat intelligence provider and the red team. The entity being tested is expected to carry out due diligence to confirm its chosen providers meet the requirements set out in that guidance.
In practice, this is where we see the most avoidable problems. A provider that treats threat intelligence as a recycled sector report will produce a red team exercise indistinguishable from a standard internal penetration test. A red team that cannot demonstrate genuine adversary simulation — custom tooling, operational security discipline, realistic persistence and lateral movement — will produce findings that flatter the defenders. The procurement guidance exists precisely to give buyers a defensible basis for telling these apart.
Two companion documents are worth pulling into any scoping conversation: the TIBER-EU Control Team Guidance, on setting up the internal team that manages the test, and the TIBER-EU Purple-Teaming Guidance, on how purple teaming is managed during the testing or closure phase. Purple teaming is often where the real maturity gain happens — it turns a red team finding into a detection engineering change while the context is still fresh.
What to take away
TIBER-EU's contribution is not that it invented red teaming. It is that it made threat-led testing repeatable, overseen and mutually recognisable across a continent — and then tied it to a regulation that makes it compulsory for a large part of the financial sector. For an entity facing DORA TLPT obligations, the framework is the path of least resistance and the highest assurance.
For everyone else, the framework is a useful benchmark even if you never formally adopt it. Ask whether your red team exercise is driven by intelligence about who would actually attack you, whether your defenders genuinely did not know it was coming, whether a blue team report exists as a first-class artefact, and whether the remediation plan has an owner. If the answer to any of those is no, you are running a demonstration, not a test. TIBER-EU's real lesson is that the structure around the attack — the roles, the phases, the artefacts and the oversight — is what converts a clever intrusion into durable resilience. The TIBER-EU Knowledge Centre, hosted by the ECB, exists to keep that implementation consistent as more jurisdictions join; new adopters can reach the community at [email protected].