TIBER-EU Explained: 2025 Framework & DORA TLPT

Source basis last verified 13 July 2026: ECB TIBER-EU Framework (January 2025), Regulation (EU) 2022/2554 and Commission Delegated Regulation (EU) 2025/1190.

TIBER-EU is the European Central Bank's framework for controlled, intelligence-led red-team testing of Critical or Important Functions and the live production systems supporting them. It is not EU law. The January 2025 framework is aligned with threat-led penetration testing under DORA, but for a mandatory test, DORA and Commission Delegated Regulation (EU) 2025/1190 define the binding requirements and take precedence. TIBER-EU provides the detailed operating model for conducting the exercise safely and consistently.

Key takeaways

TIBER-EU stands for Threat Intelligence-Based Ethical Red Teaming.
It is designed for realistic testing of important business functions across people, processes and technology not merely a list of technical assets.
TIBER-EU is a non-legally binding framework. DORA TLPT is a legal obligation only for financial entities identified under the applicable DORA process.
The lifecycle has three official phases: Preparation, Testing and Closure. Threat intelligence and red-team testing are distinct parts of Testing.
Testing is performed against live production systems, which makes secrecy, risk assessment, deconfliction, escalation and stop controls essential.
The exercise continues after active testing through reporting, replay, mandatory purple teaming, root-cause analysis, remediation and attestation.
Provider eligibility, authority expectations and national implementation details must be checked for the relevant entity and jurisdiction.

What is TIBER-EU?

TIBER-EU means Threat Intelligence-Based Ethical Red Teaming. The ECB describes it as a common European framework for authorities, tested entities, Threat Intelligence Providers and Red Team Testers to conduct controlled, intelligence-led attacks and improve cyber resilience.

Target intelligence examines the entity's reachable environment; threat intelligence evaluates plausible actors and objectives. Together they shape bespoke scenarios. The January 2025 TIBER-EU Framework centres those scenarios on Critical or Important Functions (CIFs) and their supporting people, processes and technologies not on a generic catalogue of techniques or assets.

This is why TIBER-EU is more than:

a vulnerability scan, which identifies potential weaknesses at scale;
a conventional pentest, which validates weaknesses in a technical scope;
a tabletop, which discusses response without covert live testing; or
an ordinary red-team engagement without the TIBER governance, evidence, closure and attestation model.

The ECB is explicit that a TIBER-EU outcome is not simply pass or fail. Its value is the evidence it creates about protection, detection and response, followed by the learning and remediation that evidence drives.

What changed in the January 2025 framework?

The current baseline is the January 2025 TIBER-EU Framework. The ECB's February 2025 update notice identifies the main changes:

Process steps and deliverables were aligned with the DORA regulatory technical standards for TLPT.
DORA-aligned timing and deadlines were incorporated into the framework.
Purple teaming became a mandatory part of TIBER-EU.
“Control Team” replaced the historical “White Team” term.
The supporting guidance set was expanded, including more detailed provider-procurement considerations.
Authorities can adopt the central documentation and publish a shorter local implementation document instead of recreating a full national guide.

These are not cosmetic changes. An older 2018 summary may omit required closure work, use obsolete role names or present timing that no longer matches the current process. Procurement documents and rules of engagement should therefore cite the current edition and the applicable national or European implementation.

Who is TIBER-EU for and is it mandatory?

TIBER-EU was designed around core financial infrastructure, financial entities and authority-led programmes. The ECB also states that the framework can be used in other critical sectors. An organisation may therefore undertake a TIBER-style exercise voluntarily, through an authority programme or to operationalise a separate regulatory obligation.

TIBER-EU itself is not an EU regulation, directive or certification. The ECB Banking Supervision guide describes it as detailed, non-legally binding operational guidance: the “how” of a threat-led test.

DORA is different. Regulation (EU) 2022/2554, particularly Articles 26 and 27, establishes binding TLPT duties for financial entities identified by their competent authorities. Commission Delegated Regulation (EU) 2025/1190 supplies the regulatory technical standards on identification, scope, methodology, testers, closure, remediation and cooperation.

That produces a simple legal hierarchy:

DORA and the RTS define the binding requirements; TIBER-EU provides detailed operational guidance for conducting the test.

Not every DORA-regulated firm is automatically required to perform TLPT, and not every TIBER-EU test is a DORA TLPT. Applicability and implementation must be confirmed with the relevant competent or TIBER authority. For detailed legal-applicability intent, see DeepStrike's separate guide to DORA TLPT requirements.

This article is an educational framework guide, not legal advice or an official interpretation for a particular entity.

Which testing route applies?

Start with the source of the obligation. The same technical ambition can require a different governance model, evidence set and authority relationship.

Authority-identified DORA TLPT: follow DORA, the RTS, authority instructions and the applicable TIBER implementation; binding requirements take precedence.
Voluntary or authority-led TIBER-EU exercise: agree the oversight model, implementation document, providers, scope and attestation route before testing.
Focused technical assurance: use a conventional penetration test or broader red-team engagement when the objective is an agreed asset or attack path without the TIBER authority model.

TIBER-EU vs DORA TLPT vs conventional penetration testing

The three concepts overlap, but they are not interchangeable. A TIBER-EU test can provide the operating model for a DORA-mandated TLPT. A conventional penetration test can support wider resilience and vulnerability-management programmes, but does not become TIBER-EU or DORA TLPT merely because it is manual, difficult or performed on production.

Comparison point	TIBER-EU framework	DORA TLPT	Conventional penetration test
Nature and legal status	Non-legally binding ECB framework with mandatory and optional framework requirements	Binding for financial entities identified under DORA and the RTS	Contracted assurance activity; legal or standard-driven only where another obligation requires it
Primary purpose	Consistent, safe, intelligence-led testing and defensive learning	Advanced digital operational resilience testing under EU law	Find and validate exploitable technical weaknesses in an agreed scope
Trigger or governance	Voluntary or authority-led; may operationalise a regulatory test	Competent/TLPT authority identifies the entity and governs legal requirements	Organisation, customer, auditor, standard, risk event or release programme
Typical target and scope	CIFs and supporting people, processes, technology and relevant providers	Several or all CIFs selected and validated under the governing process	Named applications, APIs, networks, cloud environments, devices or other assets
Threat intelligence	Bespoke target and threat intelligence is central	Required under the DORA TLPT model	Optional
Live production	Central to realism, with active risk management	Binding TLPT scope includes live production systems supporting in-scope CIFs	Possible where authorised, but not inherent
People, process and technology	Covered through function-led scenarios	Covered where they support the in-scope functions and scenarios	Often technology-led unless explicitly broadened
Authority involvement	TIBER Authority, TIBER Cyber Team and Test Manager	Competent/TLPT authority and its TLPT Cyber Team/Test Manager	Usually none
Provider requirements	External TIP is mandatory; external RTT is strongly encouraged; local rules may add criteria	DORA Article 27, the RTS and authority rules govern tester eligibility and internal/external use	Buyer-defined competence, independence and contractual controls
Main outputs	SSD, TTIR, RTTP, team reports, replay, purple teaming, remediation plan, TSR, feedback and attestation	Prescribed DORA/RTS evidence, remediation and authority attestation	Technical report, evidence, risk ratings, recommendations and often retest results
Attestation or recognition	Authority attestation can support recognition under agreed conditions	Attestation supports the legal TLPT process and potential cross-authority recognition	No TIBER/DORA attestation
Frequency or cadence	Three-year intervals are the framework norm, but not a universal binding cycle	Identified entities: at least every three years, subject to the competent authority's risk-based power to adjust	Risk-, release-, contract- or standard-based
What completion does not prove	Full DORA compliance, complete security or automatic recognition everywhere	Compliance with every DORA duty, absence of vulnerabilities or future resilience	Whole-function resilience, regulatory TLPT completion or protection from breach

For general stages and standards outside this framework, use the dedicated penetration testing methodology guide.

Comparison of TIBER-EU, DORA threat-led penetration testing, and conventional penetration testing by legal status, scope, oversight, outputs and cadence.

TIBER-EU explains how to run a high-quality threat-led test; DORA and its RTS determine binding TLPT obligations for designated financial entities. Source: Regulation (EU) 2022/2554, Commission Delegated Regulation (EU) 2025/1190 and ECB TIBER-EU Framework, January 2025.

The TIBER-EU lifecycle at a glance

The framework organises the test into three official phases: Preparation, Testing and Closure. Testing is divided operationally into threat intelligence and scenarios, followed by red-team planning and active testing. Closure then converts the covert exercise into evidence, shared understanding and owned remediation.

Preparation

The process starts with written notification or agreed voluntary initiation. The entity establishes the Control Team, secure communications and initiation documents. It begins a documented risk assessment that continues throughout the test. The Scope Specification Document (SSD) identifies CIFs, dependencies and safe, verifiable “flags” or objectives. Management approves the scope; the Test Manager and authority validate it through their applicable roles. The entity also procures and onboards the TIP and RTT.

Testing: threat intelligence and scenarios

The TIP collects target and threat intelligence, creates plausible high-level scenarios and works with the RTT and Control Team to refine the selected scenarios. The final Targeted Threat Intelligence Report (TTIR), after the required review and approval, becomes the basis for the Red Team Test Plan.

Testing: red team

The RTT turns the scenarios into a controlled plan covering objectives, boundaries, escalation, evidence, risk and restoration. After approval, active testing proceeds on live production systems. Status meetings allow the Control Team and Test Manager to monitor risk without unnecessarily disclosing the exercise. Any leg-up controlled assistance to progress the test must be agreed and documented.

Closure

After active testing, the RTT and Blue Team report, reconstruct the exercise in replay and examine further learning in purple teaming. The entity completes root-cause analysis, a remediation plan, the Test Summary Report (TSR) and 360-degree feedback. Authority attestation concludes the test.

Phase	Key activities	Main participants	Core outputs	Official timing label	Key risk or decision
Preparation	Notify, initiate, form CT, assess risk, scope CIFs, procure providers	Entity, management body, CT/CTL, TM/TCT; TIP/RTT when onboarded	Initiation documents, SSD, risk assessment, contracts	Maximum: no longer than six months from written notification; initiation documents due within three months	Correct function-led scope, secrecy, provider eligibility and production safety
Testing: threat intelligence	Target/threat intelligence, scenario creation and selection	TIP, CT/CTL, TM, RTT	Scenario shortlist and final TTIR	Indicative: four to six weeks	Plausibility, current intelligence and coverage of in-scope CIFs
Testing: red team	RTTP, active testing, governance, logging and risk decisions	RTT, CT/CTL, TM, TIP as needed	Approved RTTP, action logs, flags and evidence	Indicative: RTTP creation two to three weeks. Minimum: active testing 12 weeks	Safe progression, deviations, leg-ups, detection and stop decisions
Closure	Team reports, replay, purple teaming, feedback, remediation, TSR and attestation	CT/CTL, RTT, BT, TIP, TM/TCT, management body, authority	RTTR, BTTR, replay/PT outputs, remediation plan, TSR, feedback, attestation	Deadlines: RTTR within four weeks; BTTR, replay and PT within ten weeks after active testing; TSR and remediation plan within eight weeks after TM assessment notification. TM assessment time means closure may exceed 18 weeks.	Sensitive evidence handling, root causes, action ownership and attestation eligibility

These values have different meanings maximum, minimum, indicative and deadline-based. They should not be added into a single promised duration. Entity readiness, provider procurement, authority review, cross-border coordination and the Test Manager's assessment can materially affect the calendar. See the January 2025 framework for the authoritative labels and sequence.

TIBER-EU lifecycle showing preparation, threat intelligence, red-team planning and testing, closure, remediation and attestation with official timing labels.

TIBER-EU links function-led scoping and threat intelligence to controlled testing, defensive learning, remediation and authority attestation. Source: ECB TIBER-EU Framework, January 2025, and its supporting guidance.

Who does what in a TIBER-EU test?

The role model separates accountability, oversight, intelligence, active testing and defence. That separation preserves test integrity and makes risk decisions traceable.

Stakeholder	Primary responsibility	Key decisions or inputs	Information boundary	Main outputs or approvals
Tested entity and management body	Own the end-to-end test, risk and remediation	Resources, approved scope, risk acceptance and remediation ownership	Management receives what is needed without widening covert knowledge unnecessarily	Scope approval, remediation ownership and governance evidence
Control Team (CT)	Manage the test inside the entity	Scope, risk controls, providers, escalation, deconfliction and evidence flow	Small need-to-know group; monitors Blue Team and third-party detections	Initiation documents, SSD, risk records, TSR and remediation plan
Control Team Lead (CTL)	Lead the CT and coordinate the exercise	Finalise scope and scenarios; coordinate TIP, RTT, TM and authority	Primary operational contact with access to senior escalation	Coordinated approvals, meetings and risk decisions
Blue Team (BT)	Protect, detect and respond in normal operations	Defensive decisions during the covert test; later maps detections and response	Normally unaware until detection, controlled disclosure or closure	Blue Team Test Report, replay and purple-team input
TIBER/TLPT Authority	Adopt or apply the framework and provide formal authority oversight	Attestation eligibility, required evidence and national/European conditions	Receives material specified by the framework, law and implementation	Approval where required and signed attestation
TIBER/TLPT Cyber Team (TCT)	Operate the authority's testing programme	Quality, consistency, cooperation and authority coordination	Holds only the sensitive information needed for its function	Programme oversight and assigned Test Manager
Test Manager (TM) and alternate	Guide and review the individual test	Validate or review scope, risk, providers, scenarios, plans, reports and deviations	Direct, secure contact with CTL and providers when required	Validations, approvals, assessment and recommendation for attestation
Threat Intelligence Provider (TIP)	Produce target and threat intelligence	Relevant actors, objectives, exposed surfaces and scenario updates	Separate from Blue Team; works closely but independently with RTT	TTIR, scenario input and intelligence updates
Red Team Testers (RTT)	Plan and execute the controlled scenarios	RTTP, paths, flags, deviations, leg-ups, restoration and evidence	Covert from BT; accountable to CTL/TM governance	RTTP, logs, Red Team Test Report, replay and purple-team input
Relevant ICT or critical third party	Support or participate where its services underpin scope	Permissions, risk controls, deconfliction and service-owner constraints	Access and knowledge limited by contract, law and operational need	Agreed test support, evidence and remediation input

External providers do not transfer accountability away from the entity. The framework states that the tested entity remains responsible for end-to-end conduct and the risks created by the exercise.

TIBER-EU stakeholder map showing authority oversight, the tested entity and Control Team, Threat Intelligence Provider, Red Team Testers, Blue Team and relevant third parties.

A TIBER-EU test separates governance, threat intelligence, active testing and defence while maintaining controlled communication through the Control Team and Test Manager. Source: ECB TIBER-EU Framework and Control Team guidance, 2025.

How scope is defined

A weak scope is a list of IP addresses and applications. A TIBER-EU scope starts with the function whose disruption, defective performance or failure would materially affect the entity's financial performance, service continuity or legal obligations. The entity then maps what enables that function.

The SSD records:

in-scope CIFs and the rationale for inclusion or exclusion;
the systems and services underpinning each function;
relevant people, processes, applications, infrastructure, data and facilities;
outsourced or intragroup dependencies;
cross-border and multi-authority considerations; and
flags or objectives for the relevant systems.

The management body approves the scope and the TIBER/TLPT authority validates it through the applicable process. The threat-intelligence phase may revalidate assumptions as plausible actors and scenarios become clearer.

Hypothetical example: payment processing

Suppose a financial entity selects real-time payment processing as a CIF. Its dependency map might include customer and workforce identity, privileged administration, payment APIs, fraud decisioning, message queues, cloud platforms, network paths, cryptographic services, employee processes, monitoring and an external communications provider.

The approved flags might focus on whether a simulated actor could achieve a defined, safely observable effect against the payment function. The test could use a wider system as an entry or pivot point, but the objective remains tied to the function. This is only an example; each entity's business-impact analysis, architecture, threat profile and authority instructions determine its actual scope.

Third-party infrastructure cannot be assumed testable. It requires owner consent, contract rights, legal and privacy review, safe boundaries, coordination and restoration arrangements. Multi-party or pooled testing may suit a shared service, but does not remove each entity's risk responsibilities.

Threat intelligence and scenario design

TIBER-EU uses several related intelligence products:

Generic Threat Landscape (GTL): where available, a sector-level view of relevant actors, motives, techniques and common exposures. It can inform early scoping but is not a substitute for entity-specific work.
Target intelligence: information about the entity's potential attack surface, people, technology and exposures.
Threat intelligence: analysis of actors that plausibly threaten the entity, including their intent, capability and operating patterns.
Targeted Threat Intelligence Report (TTIR): the entity-specific synthesis that defines the selected scenarios and informs red-team planning.

The TIP creates a broad scenario set, then works with the CT, TM and RTT through selection and refinement. The RTT translates approved scenarios into the Red Team Test Plan, including objectives, paths, controls and evidence expectations.

A credible scenario connects actor, objective and function. It should not be chosen because a technique is fashionable or because a provider wants to demonstrate a particular tool. It should explain why that actor would pursue that objective, how the route relates to the entity's environment and what defensive capability the exercise is intended to evaluate.

Testing live production systems safely

Production realism is central because security controls, identity relationships, monitoring, employee behaviour and service dependencies often differ from a laboratory. Testing the real environment provides stronger evidence about how the entity protects, detects and responds.

It also creates real risk. The ECB framework identifies potential outage, system damage, data loss, modification or disclosure. A covert test can also collide with genuine incident response or a third party's protective action.

Core safeguards therefore include:

written authorisation, approved scope and rules of engagement;
initial and continuously updated risk assessment;
clear exclusions, limits and restoration procedures;
secure, need-to-know communications and evidence handling;
tested escalation paths and senior decision-makers;
deconfliction with genuine incidents and other sensitive work;
documented stop, pause and recovery conditions;
legal, privacy, regulatory and business-continuity review;
asset-owner and third-party permission; and
reliable backups and restoration capability where relevant.

The Control Team watches business risk and can obtain information about detections without coaching the Blue Team. The Test Manager must be involved when material deviations or attestation risks emerge. Safety controls reduce risk; they do not make live-production testing risk-free.

Reporting, replay, purple teaming and remediation

Active testing is the evidence-generating middle of the exercise, not its endpoint.

The Red Team Test Report (RTTR) records the scenarios, paths attempted, flags reached or missed, deviations, leg-ups, findings, root causes and remediation recommendations. The Blue Team Test Report (BTTR) maps defensive observations, detections and response actions against the red-team timeline and identifies lessons and topics for purple teaming.

During replay, both teams reconstruct what happened step by step. This reconciles timestamps and evidence, shows where actions were visible or missed, and gives defenders the context behind the red-team record.

During purple teaming, the RTT and BT explore remaining or additional learning objectives together. They may validate how alternative defensive or testing actions would have changed the outcome, within approved safety boundaries. The January 2025 update makes purple teaming mandatory under TIBER-EU.

The remediation plan must go beyond a list of patches. It should connect each shortcoming to its root cause, priority, action, accountable owner, expected completion and the risk of delay. Findings may reveal weaknesses in governance, identity design, monitoring, response, operational processes or third-party dependencies not only software defects.

The Test Summary Report consolidates the validated scope, participants, scenarios, paths, flags, detection outcomes, risk measures, findings, root causes and high-level remediation. The 360-degree feedback process examines how the entity, TM, TIP, RTT and BT worked together so that the next exercise can be better governed and executed.

Attestation and mutual recognition

Once the TIBER Authority has approved the TSR and remediation plan, it issues and signs the attestation. For a TIBER test conducted to meet DORA, the relevant TLPT Authority is treated as the TIBER Authority for that exercise.

The attestation confirms that the test was conducted in accordance with the relevant core framework requirements and applicable implementation. It records items such as dates, in-scope CIFs, untested in-scope functions, participating entities or providers, tester arrangements, active-testing duration and the documents examined.

It does not certify that:

the entity is secure;
every vulnerability was found;
every remediation item is complete;
every DORA obligation is satisfied;
the exercise was an audit; or
another authority must accept the result.

The framework is designed to facilitate recognition and reduce duplicated testing. Recognition still depends on compliance with the required framework and legal conditions, the involvement or agreement of relevant authorities, the applicable national or European implementation and permitted sharing. Depending on those conditions, the entity or authority may share the TSR, remediation plan and attestation. Detailed technical reports remain highly sensitive and are not automatically distributed.

Selecting TIP and RTT providers

Provider selection should begin with the governing authority and legal entity, not a marketing badge. The ECB's Guidance for Service Provider Procurement supplies baseline criteria, while DORA, the RTS and national or European implementations may add binding requirements.

Procurement teams should verify:

Jurisdiction and eligibility: applicable authority rules, external-tester conditions and the contracting entity's eligibility.
Assigned team: roles, availability, references, qualifications and replacement capacity for the people proposed not only corporate experience.
Threat intelligence: targeted methods, required sector context, lawful source handling and scenario development.
Red-team capability: controlled live-production testing, risk decisions, restoration, evidence, reporting, replay and purple teaming.
Independence: conflicting current or prior services, TIP/RTT separation where one group supplies both, and no Blue Team duties.
Risk and confidentiality: governance, need-to-know access, secure transfer, retention, privacy, incident handling and relevant indemnity insurance.
Collaboration: ability to work with the CTL, TM, authority, providers and third parties.
Contracting chain: legal entity, locations, subcontractors, data flows and accountability.
Deliverables: evidence of quality across TTIR, RTTP, RTTR, replay, remediation and executive reporting.
Credentials: only accreditation, certification or conduct requirements that actually apply to the jurisdiction and test.

The procurement guidance asks buyers to evaluate appropriate recognised certifications and, where relevant, accreditation. It does not make one named scheme universally mandatory for every TIBER-EU or DORA TLPT engagement. Obtain the Test Manager's input before contracting where the framework or authority requires it.

TIBER-EU readiness checklist

This checklist is a preparation aid, not a substitute for the current framework, the RTS, authority instructions, legal advice or a formal project plan.

1. Authority and applicability

Confirm whether the exercise is voluntary, authority-led or mandatory DORA TLPT.
Identify every competent, TIBER or TLPT authority that may need to participate.
Record the governing legal text, framework edition and national/European implementation.

2. Governance and Control Team readiness

Name a CTL, backup and small cross-functional CT with sufficient decision authority.
Establish senior escalation and rapid stop/pause decision routes.
Budget for providers, internal effort, closure and remediation not only active testing.

3. Function-led scope and dependency mapping

Validate the CIF inventory and business-impact rationale.
Map people, processes, applications, infrastructure, data, facilities and providers.
Draft measurable, safe flags tied to the selected functions.

4. Procurement and provider due diligence

Check the exact provider criteria with the Test Manager before contracting.
Assess the assigned TIP and RTT teams, conflicts, separation, references and capacity.
Confirm legal entity, subcontractors, insurance, secure handling and replacement resources.

5. Legal, privacy, confidentiality and third-party permissions

Complete legal and privacy review for every planned activity and jurisdiction.
Confirm asset-owner and service-provider permissions and contract rights.
Define classification, access, transfer, retention, sharing and destruction for evidence.

6. Production risk and escalation

Document the initial risk assessment and triggers for re-evaluation.
Verify deconfliction, genuine-incident handling, backup, restoration and stop conditions.
Ensure the CT can monitor operational risk without briefing the BT.

7. Threat intelligence and scenario governance

Give the TIP enough business and scope context without weakening secrecy.
Select scenarios against actor plausibility, function impact and learning objectives.
Define how new intelligence or material scope changes will be reviewed and approved.

8. Reporting, learning and evidence ownership

Reserve BT, CT, RTT, TIP and TM time for reports, replay, purple teaming and feedback.
Agree report ownership, sensitivity, recipients and authority submission routes.
Establish remediation owners, milestones, progress evidence and management oversight.

Common mistakes and misconceptions

Treating TIBER-EU as a universal EU legal mandate.
Treating TIBER-EU, DORA TLPT, red teaming and conventional pentesting as interchangeable.
Using “White Team” as the current term without explaining that the 2025 framework uses Control Team.
Scoping only technology rather than CIFs and their supporting dependencies.
Ignoring outsourced or intragroup ICT services that underpin the selected functions.
Treating threat intelligence as generic news aggregation.
Selecting fashionable techniques before agreeing plausible actors and objectives.
Measuring success only by access gained rather than defensive evidence and learning.
Under-resourcing the CTL and Control Team.
Using secrecy as a reason to omit governance, legal review or safety controls.
Stopping after the Red Team report.
Treating replay, purple teaming or remediation as optional in a DORA-aligned process.
Presenting attestation as a security certificate or proof of full DORA compliance.
Assuming CREST, STAR-FS, CBEST or another named credential is universally required.
Quoting a fixed total duration by adding minimum, maximum, indicative and deadline values.
Claiming that completion guarantees automatic mutual recognition.

FAQs

What does TIBER-EU stand for?

TIBER-EU stands for Threat Intelligence-Based Ethical Red Teaming. It is the ECB's European framework for controlled, bespoke, intelligence-led red-team testing.

Is TIBER-EU mandatory?

Not universally. TIBER-EU is a non-legally binding framework that may be used voluntarily or through an authority programme. DORA TLPT is mandatory only for financial entities identified under the applicable DORA and RTS process.

What is the difference between TIBER-EU and DORA TLPT?

DORA and the RTS are binding EU law for designated entities and state what the TLPT must achieve. TIBER-EU provides detailed operational guidance for how authorities, entities, TIPs and RTTs can conduct that test safely and consistently.

How often must a TIBER-EU or DORA TLPT test be performed?

TIBER-EU notes three-year intervals as the norm, but this is not a universal binding cycle. Under DORA, identified entities perform TLPT at least every three years, while the competent authority may adjust frequency based on risk profile and operational circumstances. Confirm the current direction for the entity.

Does testing happen on live production systems?

Yes. Live production is central to TIBER-EU realism and is required for the relevant DORA TLPT scope. Testing must be authorised and supported by active risk management, secure communications, escalation, deconfliction, restoration and stop controls.

How long does a TIBER-EU test take?

There is no safe fixed total. The framework uses different labels: Preparation lasts no longer than six months; threat intelligence is indicated at four to six weeks; RTTP creation at two to three weeks; active testing has a 12-week minimum; and Closure contains several separate deadlines plus an open-ended Test Manager assessment period.

What are the three TIBER-EU phases?

Preparation, Testing and Closure. Testing includes threat intelligence/scenario work and red-team testing. Closure includes reports, replay, purple teaming, remediation, the TSR, feedback and attestation.

What does a TIBER-EU attestation prove?

It confirms that the authority considers the test to have been conducted according to the relevant TIBER core requirements and implementation. It is not a security certificate, audit opinion, guarantee of mutual recognition or proof of full DORA compliance.

Can TIBER-EU be used outside the financial sector?

Yes. Although designed around core financial infrastructure and authority-led financial programmes, the ECB states that it can be used in other critical sectors. Governance and authority arrangements still need to fit the sector and jurisdiction.

Conclusion

TIBER-EU is a controlled, authority-aware operating framework for intelligence-led testing of important functions in live environments. Its strength is not simply a long red-team campaign. It is the connection between function-led scope, current threat intelligence, production risk management, covert defensive evidence, replay, purple teaming, root-cause remediation and formal authority oversight.

For designated financial entities, DORA and Commission Delegated Regulation (EU) 2025/1190 determine the binding TLPT requirements. TIBER-EU helps operationalise them, but cannot replace the governing law, the relevant authority's instructions or jurisdiction-specific provider checks.

Organisations exploring broader authorised adversary simulation can review DeepStrike's authorised red teaming services. Readers seeking formal TIBER-EU or DORA TLPT delivery should independently verify the provider's current eligibility and the relevant authority's requirements for their entity and jurisdiction.

About the author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike. He writes about penetration testing, red teaming and operational resilience. This guide was developed from primary ECB and EU sources and does not replace legal advice or instructions from the relevant authority.

TIBER-EU Explained: Framework, Phases, Roles, and DORA TLPT Alignment