DORA Article 26 TLPT: threat-led testing

What TLPT is

Threat-led penetration testing, as defined under DORA Article 26, is not a vulnerability scan with a red-team label attached. It is an intelligence-led red-team exercise: testers build a profile of the threat actors realistically capable of targeting the entity, then emulate their tactics, techniques, and procedures against the entity's live production environment — the systems the business actually runs on, not a staging copy or a scoped-down replica. The exercise is judged on whether it reproduces how a real adversary would attempt to compromise the entity's critical or important functions, not on how many findings it surfaces.

That live-production requirement is what separates TLPT from the rest of DORA's testing programme. A vulnerability assessment or a standard penetration test under Article 25 can run against a representative environment and still satisfy its purpose. TLPT can't — the objective is to establish, under real conditions, whether the ICT systems supporting critical functions would withstand the tactics a genuine threat actor would use, and a non-production target can't answer that question. Scope is drawn around those critical and important functions and the ICT systems that underpin them, not the entity's entire estate, so the exercise is deep on a defined attack surface rather than broad and shallow.

• ✅ Intelligence-led — built on a profile of realistic threat actors, not a generic checklist
• ✅ Run against live production systems, not a staging or scoped-down copy
• ✅ Scoped to critical and important functions and the ICT systems supporting them

Who must run it, and how it's triggered

TLPT is not a self-assessment. An entity does not decide for itself that it's in scope for Article 26, and there is no fixed list published on a calendar you can check against your own entity type. Identification is made by the entity's competent authority, based on impact and risk criteria — factors such as the entity's systemic relevance and its ICT risk profile — and it typically concentrates on larger or more critical firms rather than sweeping in every entity that DORA's general testing programme covers. If your competent authority hasn't identified you for TLPT, Article 26 doesn't apply to you directly, even though Articles 24 and 25's broader testing obligations still do.

Once an entity is identified, the cadence is set out in DORA as at least once every three years — a floor, not a fixed interval every entity follows identically. A competent authority may require a shorter interval based on the entity's specific risk profile, so the practical answer to “when is our next TLPT due” is a question for your competent authority and your own identification decision, not a universal date that applies across the market. Testers and threat-intelligence providers used in the engagement also have to meet requirements set out in DORA and its related regulatory technical standards — competence, independence, and insurance conditions among them — so the choice of who runs the exercise is itself part of what a supervisor will scrutinise.

The TIBER-EU relationship

DORA Article 26 TLPT is aligned with the TIBER-EU framework — the EU-wide methodology for threat intelligence-based ethical red-teaming that national authorities had already been running before DORA made threat-led testing a legal obligation for identified entities. TIBER-EU structures an engagement into distinct phases: a threat-intelligence phase that produces a targeted threat profile for the entity, followed by a red-team phase in which testers execute against that profile using the tactics a real adversary would plausibly use, with a controlled testing environment and closely managed engagement scope throughout.

It matters to say precisely what “aligned with TIBER-EU” means, because accreditation under TIBER-EU runs through national frameworks per engagement — it is not something a testing vendor holds in the abstract and applies across every client. A platform can be architected to support the threat-intelligence, red-team, and reporting phases TIBER-EU defines; accreditation and certification under the framework are not labels a testing platform can claim for itself, because that status attaches to the engagement and the national authority overseeing it, not to the tooling used within it.

Why hybrid delivery

A compliant TLPT is threat-led and human-driven by definition — the threat-intelligence phase requires analyst judgment about which actors and tactics are realistic for a given entity, and the red-team phase requires the accredited human oversight TIBER-EU and Article 26 assume throughout the engagement. Autonomous-agent tools alone cannot deliver a compliant TLPT: there is no version of the requirement that an unsupervised scanner can satisfy, however sophisticated its attack simulation, because the accountability and judgment the framework calls for sit with accredited people, not software.

breachr's model is built to work with that constraint, not around it: attack paths are designed by accredited red teamers, executed at speed and scale by agentic AI, and critical and high findings are validated by a CREST-credentialed tester before they're confirmed. That combination is architected to support TLPT-aligned engagements — pairing the coverage and repeatability agentic execution brings with the accredited human judgment a threat-led exercise on live production systems requires — rather than claiming that agentic AI alone satisfies an obligation that, by design, it cannot satisfy on its own.

• ✅ Attack paths designed by accredited red teamers, grounded in real threat intelligence
• ✅ Execution carried out by agentic AI, at a pace a human-only team can't match
• ✅ Critical and high findings validated by a CREST-credentialed tester before they're confirmed

Related guides