DORA TLPT is no longer a draft. Commission Delegated Regulation (EU) 2025/1190 entered into force on 8 July 2025, and the ECB's TIBER-EU framework was updated on 11 February 2025 to fully align with it. The procedural shell — phases, deliverables, attestations, mandatory purple teaming, the renamed Control Team — is now binding law across the Eurozone.
What is still missing is a standardized "what." The RTS specifies the choreography of testing without a stable taxonomy of the threats being simulated, and it measures success by qualitative detection rather than by the physics of attack speed.
The Top Level Cyber Threat Clusters (TLCTC) Framework V2.1 supplies that substance. Its ten clusters anchor scenario design; its domain, transit, and intra-system boundary operators make scope crossings explicit; Attack Velocity (Δt) turns detection from a yes/no into a comparable metric; and unresolved-step notation lets red teams report gaps honestly instead of hiding them in prose. Together, these turn TLPT outputs into something a regulator can aggregate.
1. DORA TLPT in 2026 — The Procedural Shell
The TLPT mandate sits in Articles 26 and 27 of DORA (Regulation (EU) 2022/2554). The implementing detail comes from the RTS adopted as Commission Delegated Regulation (EU) 2025/1190, applicable since 8 July 2025. The Eurosystem's TIBER-EU framework (revised 11 February 2025) supplies the operational guidance, and member-state authorities — BaFin/Bundesbank in Germany, DNB in the Netherlands, ACPR in France, BCL/CSSF in Luxembourg, the ECB for SSM-supervised banks — administer the tests through national TIBER implementations.
What the regulation now mandates with legal force:
- Scope: G-SIIs, O-SIIs, and certain payment institutions exceeding the EUR 120 bn annual transaction threshold; testing performed on live production systems covering critical or important functions (CIFs).
- Cycle: at least once every three years (Article 26(1)).
- Active red-team phase: minimum 12 weeks (DORA goes beyond TIBER-EU's prior 10–12 week guidance).
- Scenarios: at least three end-to-end threat scenarios covering the full CIA triad — one each for confidentiality, integrity, and availability impact (Article 9 RTS).
- Roles: TLPT Authority, TLPT Cyber Team (TCT), Control Team (formerly White Team), Threat Intelligence Provider (TIP — always external), Red Team Testers (RTT — internal allowed for two of three cycles, except for significant credit institutions).
- Closure: mandatory replay workshop and mandatory purple teaming — a hard departure from the optional purple-team activity in pre-DORA TIBER.
- Output: Red Team Test Report, Blue Team Test Report, summary report, remediation plan, and a formal attestation under Article 26(7) enabling cross-border mutual recognition.
This is genuine regulatory progress. For the first time, the EU has a binding, harmonized red-team mandate at the top of its financial sector. But two structural gaps remain.
The Two Substantive Gaps
Gap 1 — No common taxonomy. The regulation treats every threat scenario as a qualitatively unique narrative produced by the TIP. Bank A's "ransomware via spear-phishing" and Bank B's "ransomware via supplier compromise" are described in incompatible language, and no Eurozone aggregation is possible. There is no answer to the basic question: which generic vulnerability classes did the test exercise, and which did it miss?
Gap 2 — No physics of speed. The RTS measures success through the qualitative "effectiveness of detection and response" assessed in the Blue Team report and the purple-teaming replay. Whether the blue team detected the attacker before or after the attacker had already reached the flag — measured in time units — is not formally captured. An entity can pass a TLPT having detected lateral movement that, in real-world conditions, would have completed minutes earlier than any human-driven response could land.
There is also a third, less obvious tension worth naming. Article 9.2 of the RTS requires that the proposed scenarios "target each and every critical or important function in the scope of the TLPT." The threat-led approach pushes in the opposite direction: pick the scenarios the threat intelligence justifies, not the ones that paint the org chart. TIBER-EU 2025 papers over the gap with a longlist/shortlist construction. A taxonomy-driven approach resolves it cleanly: cover the cluster classes across the cycle, not the function map.
2. The Solution: TLCTC Framework V2.1
The TLCTC framework categorizes threats by the generic vulnerability they exploit (Axiom I), not by the actor running them, the asset hit, or the consequence produced. V2.1 is additive and backward-compatible to V2.0 — it adds operators for situations the binary V2.0 boundary couldn't express, plus semantic guardrails (SG-1 through SG-7) that keep the new operators from drifting into pseudo-classification.
A. The 10 Clusters (The Stable Taxonomy)
Instead of unbounded ad-hoc scenarios, TLCTC defines the threat landscape with ten immutable clusters. Each cluster names a distinct cause-side mechanism:
- #1 Abuse of Functions (Logic / Scope)
- #2 Exploiting Server (Server Code Flaws)
- #3 Exploiting Client (Client Code Flaws)
- #4 Identity Theft (Credential Use)
- #5 Man in the Middle (Path / Channel)
- #6 Flooding Attack (Capacity)
- #7 Malware (Execution Environment)
- #8 Physical Attack (Physical Access)
- #9 Social Engineering (Human Trust)
- #10 Supply Chain Attack (3rd Party Trust)
B. The Topology — Bridge vs. Internal Clusters
A critical distinction for TLPT scoping.
- Internal Clusters (#1–#7): operate within a single control regime — typically the financial entity's IT domain. They exploit technical vulnerabilities the entity is responsible for.
- Bridge Clusters (#8, #9, #10): cross domain boundaries. They exploit the handoff between responsibility spheres — Human → Cyber for #9, Vendor → Org for #10, Physical → Logical for #8. These are where most real-world breaches actually start.
A TLPT that exercises only Internal Clusters (e.g., unpatched servers, lateral movement) misses the most common real-world entry vectors. The Article 9.2 CIF-coverage rule is silent on this dimension; cluster-coverage closes it.
C. The V2.1 Operators — Where Things Actually Cross
V2.1 introduces three operators that make scope crossings explicit. None of them changes the cluster classification (Semantic Guardrail SG-2); they are observability metadata that enrich the path with topology information.
- Domain Boundary
||[context][@Source→@Target]||(V2.0): marks the crossing of a responsibility sphere — the where of trust handoff. Standard for #10 supply chain steps and #9 human bridges. - Transit Boundary
⇒(V2.1): marks an intermediary that relays the attack without being source or target — SMS providers, CDNs, ad networks, telco signalling. Per R-TRANSIT-3, vendor code running on the target device is the attack surface (#3), not transit. - Intra-System Boundary
|[type][@from→@to]|(V2.1): marks a boundary crossing within a single host — sandbox escape, privilege escalation, process injection, hypervisor escape. Thememorytype is reserved and MUST NOT be used (R-INTRA-9). Per R-INTRA-7, if the crossing exploits a separately evidenced vulnerability, it is a new cluster step — the annotation alone is insufficient.
This matters for TLPT because most real intrusion chains have all three layers: the attacker crosses an external sphere boundary (Domain), uses or rides on intermediaries (Transit), and once inside, escalates across internal host compartments (Intra-System). Pre-V2.1, all of this collapsed into prose.
D. The Metric — Attack Velocity (Δt) and DCS
Risk is a function of time. V2.1 keeps the velocity model from V2.0 unchanged.
- Attack Velocity (Δt): the time interval between successful steps in an attack path. Captured as transition annotations (e.g.,
[Δt=minutes]) or assigned to a velocity class VC-1 (strategic, days–months) through VC-4 (real-time, seconds–milliseconds). - Detection Coverage Score (DCS): MTTD ÷ Δt. If the attacker traverses #4 → #1 in 10 minutes and the blue team's mean time to detect that transition is 15 minutes, DCS = 1.5 — structurally insufficient regardless of whether the entity "passed" the test. DCS < 1.0 is the bar to clear.
E. Honest Reporting — Unresolved-Step Notation
Real red-team engagements produce gaps. The attacker reached the flag, but a step in the path is partially reconstructed; or the team can demonstrate the chain in principle but did not exercise the full sequence in production. V2.1 adds binary primitives for this:
?— exactly one unknown step.…— one or more unknown steps.
Per R-UNRES-9 there are no partial-confidence operators (no ?#4, no #{2|7}) — a step is either classified or unresolved. Per R-UNRES-8, every ? or … in a path requires a prose annotation. The point is to make analytical gaps visible in the same notation everyone else uses, not to bury them in narrative.
3. Comparative Analysis — Enhancing DORA TLPT with TLCTC V2.1
Integrating TLCTC V2.1 closes the substantive gaps the RTS leaves open.
| Area of Improvement | DORA TLPT (RTS 2025/1190) | With TLCTC V2.1 Integration |
|---|---|---|
| 1. Scoping Strategy | Scenarios target each CIF (Art. 9.2). At least three covering CIA triad. Threat actors and TTPs chosen ad hoc by the TIP. | Cluster-aware scoping: every three-year cycle exercises at least one scenario starting with a Bridge Cluster (#8, #9, or #10) and at least one Internal exploitation chain (#2, #3, #7). CIA coverage and cluster coverage are orthogonal — both are required. |
| 2. Supply Chain Testing | "Supply chain" is a broad scope item. Testing #10 chains relies on TIP narrative. | Explicit Domain Boundary: use #10 ||[dev][@Vendor→@Org]|| or ||[auth][@IdP→@SP]|| to mark the trust acceptance event. The boundary is auditable; the control surface is the inbound trust artefact. |
| 3. Transit Infrastructure [V2.1] | SMS gateways, CDNs, ad networks, signalling carriers usually disappear into prose ("phishing SMS sent to victim"). | Transit annotation ⇒: e.g. #9 ||[messaging][@Attacker⇒@SMSProvider→@Victim]||. Cluster classification is unchanged; the relay party is visible for forensic and supervisory purposes. |
| 4. Privilege & Sandbox Escalation [V2.1] | Lumped together as "lateral movement" or "post-exploitation" in the Red Team report. | Intra-System annotation |[type][@from→@to]|: |[privilege][@user→@root]|, |[sandbox][@app→@host]|. Each crossing is separately auditable. Where a distinct vulnerability is exploited, R-INTRA-7 mandates a new cluster step. |
| 5. Performance Metrics | "Effectiveness of detection and response" assessed qualitatively in the Blue Team report and replay workshop. | DCS = MTTD ÷ Δt: a numeric, transition-level metric. Did the blue team detect #4 → #1 before the attacker completed it? DCS < 1.0 is the bar. Velocity classes VC-1 to VC-4 standardize speed reporting. |
| 6. Comparability | Bank A's "pass" ≠ Bank B's "pass". Attestations are individual; aggregation across the sector is not possible. | Standardized notation: regulators can aggregate. "The Eurozone median Δt for detecting #4 Identity Theft is 4 hours." Sector-level systemic risk becomes measurable, not anecdotal. |
| 7. Honest Reporting [V2.1] | Gaps are buried in narrative or omitted entirely. "Leg-ups" granted to the red team are reported but not visually integrated into the path. | Unresolved-step notation: #9 → ? → #4 → #7, with prose annotation explaining the gap. Where the team needed a leg-up, the unresolved step makes the assumption visible to the regulator. |
| 8. Strategic Reporting | Technical findings are hard to translate to the Board. | Cyber Bow-Tie mapping: findings are placed on the cause (left) and consequence (right) of the System Compromise pivot, with DRE tags (+ [DRE: C], + [DRE: Ac]) showing how technical chains cascade to business impact. |
4. Applied Example — A Standardized DORA Threat Scenario
Instead of a narrative description, a TLPT mandate using TLCTC V2.1 defines the test scenario in standardized notation. Here is one of the three required scenarios — an availability-impact (CIA-A) scenario chained through a software supply chain.
Scenario: Software Supply Chain Compromise → Ransomware
#9 — Social Engineering: targeted phish against a developer at the TIP/vendor; domain boundary ||[human][@Attacker→@Vendor]||. Credentials are acquired here as data — Axiom X (credential dual nature).
#4 — Identity Theft: stolen credentials are used at the vendor. During application, credentials are system elements — always #4. The acquisition (#9) and application (#4) are distinct cluster steps per Axiom X.
#1 — Abuse of Functions: the CI/CD pipeline is used as designed but for an attacker's purpose — code is signed and pushed. No new vulnerability is exploited at this step; the function itself is the surface.
#10 — Supply Chain (Bridge): the trust acceptance event. The signed package crosses ||[dev][@Vendor→@Org]|| and becomes authoritative inside the bank's build/runtime. Per the transit-vs-#10 distinction, #10 is the trust artefact crossing — not a transit relay.
#1 — Abuse of Functions (at Org): the package manager's legitimate install-processing behaviour fetches and stages the payload. This is the canonical npm-style chain #10 → #1 → #7, not #10 → #7 — the install-processing step has its own control surface and its own velocity profile.
#7 — Malware: code executes in the bank's environment. Each fresh download-and-execute of foreign code from C2 would constitute a new #7 step (R-EXEC), with #1 steps between for legitimate function abuse used to fetch the next payload.
[DRE: Ac, C]: Disclosure / Removal / Exposure outcomes — asymmetric encryption (Ac, data present but unusable) plus exfiltration (C) for double extortion. Per the DRE rule, this is appended to the cluster step (+ [DRE: ...]) — never as a standalone path element.
The regulator reading this scenario sees, at a glance, that the TLPT exercises a Bridge Cluster entry (#10), a Domain Boundary crossing (Vendor → Org), and the canonical multi-step supply chain chain (not a collapsed shortcut). DCS metrics on each transition show where in the chain the blue team was fast enough to interrupt and where it was not.
5. Why V2.1 Specifically Helps the TLPT Mandate
The V2.1 additions map cleanly onto pain points the RTS leaves unaddressed.
- Transit accountability for Article 30 third parties. ICT third-party providers in scope under DORA Article 30 frequently include carriers and CDN-style intermediaries that a #9 or #3 chain rides on without the bank "trusting" them in the #10 sense. The transit operator
⇒annotates them visibly without misclassifying. - Intra-system precision for the Red Team Test Report. The RTS requires reporting "every TTP used." TLCTC V2.1's intra-system operator gives the report a vocabulary for sandbox escapes, privilege escalations, and process injections that distinguishes them from new cluster steps (per R-INTRA-4 vs. R-INTRA-7).
- Unresolved-step honesty for "leg-ups." Every TLPT involves leg-ups — assumed-compromise starting positions, granted credentials, simulated phishing success. V2.1's
?and…with mandatory prose annotation make the assumption visible in the path, not buried in a methodology footnote. - Semantic Guardrails for the regulator. SG-1 (cause first) through SG-7 (backward recoverability) ensure that the operators don't drift into pseudo-classification. A TLPT Authority can require V2.1 conformance and trust that stripping annotations leaves a valid cluster sequence (SG-7) — i.e., that aggregation across tests stays meaningful.
6. Conclusion
DORA TLPT under Commission Delegated Regulation (EU) 2025/1190 is the rules of the road. TLCTC V2.1 is the physics of the traffic.
By adopting TLCTC V2.1 alongside the RTS, DORA TLPT gains:
- Topological precision: Bridge vs. Internal scoping; Domain vs. Transit vs. Intra-System boundaries.
- Velocity reality: DCS = MTTD ÷ Δt as the binary detection-effectiveness criterion.
- Cross-EU comparability: standardized notation that aggregates without ambiguity.
- Reporting honesty: unresolved-step operators that surface gaps instead of hiding them.
Recommendation. TLPT Authorities should mandate, or at least strongly recommend, TLCTC V2.1 notation for two specific deliverables under the RTS: the Threat Intelligence (TI) report (Article 7) and the Red Team Test Report (Article 8). Doing so costs nothing in the test process itself and turns the most expensive cybersecurity exercise the EU has ever mandated into something whose results are statistically comparable, structurally aggregable, and strategically actionable at the sector level.