The TIBER-EU framework, explained

What TIBER-EU is

TIBER-EU stands for Threat Intelligence-based Ethical Red-teaming. It's a framework published by the European Central Bank in 2018 to give the EU's financial sector a common, controlled way to run intelligence-led red-team tests against a firm's live production systems — not a sandbox, not a staging replica, but the environment the business actually runs on. The point of TIBER-EU isn't to generate a list of vulnerabilities; it's to establish, under realistic adversary conditions, whether an entity's critical functions would hold up against the tactics a genuine threat actor would use.

The ECB doesn't run TIBER-EU tests directly. It publishes the framework, and individual member-state authorities adopt and operate their own national implementation — TIBER-DE in Germany, TIBER-NL in the Netherlands, and equivalents across most other member states, each with a national TIBER Cyber Team that oversees engagements in that jurisdiction. That national layer is where the framework becomes operational: it's the national authority, not the ECB and not any testing vendor, that scopes an engagement, approves the threat-intelligence provider and red team involved, and signs off on the result. A firm engaging in a TIBER-EU-aligned test is working within its own national framework's rules, not a single EU-wide process run from Frankfurt.

• ✅ Published by the ECB in 2018 as a common EU methodology for threat-led testing
• ✅ Implemented and overseen by national authorities — TIBER-DE, TIBER-NL, and equivalents
• ✅ Run against live production systems, judged on realistic adversary resilience, not finding counts

The phases

TIBER-EU structures every engagement into three phases. Preparation is where the national authority, the entity, and the providers involved scope the test — agreeing which critical functions and systems are in play, confirming legal and risk-management sign-off, and appointing the threat-intelligence provider and red team who will run it. Nothing about the attack itself happens here; it's the governance layer that has to be in place before live testing can start.

Testing is the active phase, and it runs in two steps. A threat-intelligence provider first builds a targeted threat profile for the entity — who would realistically target this firm, and how — and hands that profile to a separate red team, who then execute against it, attempting to compromise the entity's critical functions using the tactics, techniques, and procedures a real adversary in that profile would plausibly use. Separating the intelligence provider from the red team is a deliberate control in the framework, not an incidental detail.

Closure is where the test converts into something the entity can act on. It typically includes a replay or purple-teaming exercise — the red team and the entity's blue team walking back through the attack together so the defenders understand what happened and why it worked — followed by remediation planning and a final report that the national authority uses to close out the engagement. For a buyer, closure is the phase that matters most day to day: it's where a red-team exercise turns into a remediation plan and an attestation you can put in front of a supervisor.

Relationship to DORA Article 26 TLPT

DORA Article 26 threat-led penetration testing is aligned with TIBER-EU. National authorities were already running TIBER-based programmes for years before DORA made threat-led testing a legal obligation for designated entities, so DORA didn't invent a new methodology — it built the TLPT requirement on the framework that already existed, and national implementations map their TIBER programmes to the DORA obligation for entities in scope.

That doesn't mean every entity subject to DORA has to run a TIBER-EU-aligned test. TLPT under Article 26 applies only to entities that their competent authority has specifically identified for it, based on impact and risk criteria — typically larger or more systemically relevant firms. DORA's broader testing obligations under Articles 24 and 25 apply more widely, but the threat-led, TIBER-aligned exercise is reserved for the entities designated for it. If you haven't been identified for TLPT, TIBER-EU's phases still describe useful practice, but the legal obligation to run one doesn't apply to you directly.

How breachr's methodology aligns

A TIBER-EU-aligned engagement is threat-led and human-accountable by design — the framework assumes an accredited red team executing against an intelligence-built profile, with a national authority overseeing the result. No autonomous tool can hold that accountability on its own, and it's worth being precise about what “aligned” means here: accreditation of red-team and threat-intelligence providers runs through the national TIBER frameworks, per engagement — it is not a status any testing vendor, breachr included, can claim for itself in the abstract.

Within that constraint, breachr's methodology is built to support threat-led practice rather than to substitute for it. Attack paths are drawn from accredited offensive tradecraft, then executed by agentic AI at a pace and scale a human-only red team can't match. Critical and high findings are validated by a human before they're confirmed, and every finding is cryptographically documented with its provenance so the entity and its national authority can trace exactly what was tested, when, and by what method. That combination — accredited tradecraft, agentic execution, human validation, tamper-evident evidence — is architected to support TIBER-EU-aligned engagements and the DORA TLPT requirement built on it, not to claim an accreditation that only a national framework can grant.

• ✅ Attack paths grounded in accredited offensive tradecraft, not generic scan signatures
• ✅ Execution carried out by agentic AI, at a pace a human-only team can't match
• ✅ Critical and high findings human-validated; every finding cryptographically documented with its provenance

Related guides