The DORA TLPT Bottleneck: Why Mandatory Hacking Needs More Than Hackers

DORA has created a new pressure point in European financial cybersecurity: selected financial entities now need regulated threat-led testing, but trusted delivery capacity is limited.

For selected financial entities, advanced offensive security is no longer only a maturity exercise, a board-level reassurance activity, or something done by the most security-conscious organisations. Under DORA, Threat-Led Penetration Testing becomes a regulated resilience-testing requirement for entities designated as in scope. DORA Article 26 sets the TLPT obligation for identified financial entities, including the three-year testing cycle and coverage of critical or important functions. DORA Regulation (EU) 2022/2554, Article 26.

For offensive-security providers, that looks like a market opportunity. It is also where the real constraint appears.

TLPT is not a bigger pentest

• A penetration test usually asks: what is vulnerable?
• A red-team exercise asks: can we achieve an attacker objective?
• A TLPT asks something heavier: can a realistic threat compromise critical functions, and can the organisation prove resilience improvement?

That difference matters.

TLPT is not just a pentest with a larger budget, a longer report, and more dramatic language. It is threat-led, scenario-based, production-facing, evidence-heavy, and subject to governance and supervisory expectations. The updated TIBER-EU framework, aligned with DORA, describes controlled cyberattacks involving authorities, entities, threat-intelligence providers, and red-team testers, with a focus on safe and controlled execution. (TIBER-EU Framework updated to align with DORA)

This changes the skill profile.

The hard part is not only exploitation. It is also threat intelligence, scope discipline, safe execution, Control Team coordination, evidence quality, replay, remediation, and the ability to operate under scrutiny.

In other words:

In practical terms, TLPT is where offensive security becomes a regulated production activity.

The bottleneck is trusted capability

The simplest version of the DORA TLPT story is: “Europe will need more hackers.”

That is incomplete.

The real shortage is not generic offensive talent. The shortage is trusted offensive capability: teams that can safely test critical financial functions on live production systems, or prepare organisations through production-like readiness exercises before formal TLPT, with evidence and governance strong enough to survive review.

On the demand side, TLPT can be mandated, but not every financial entity is automatically in scope. The final TLPT RTS defines how authorities identify entities required to perform TLPT, including criteria around systemic relevance, impact, ICT risk profile, criticality, interconnectedness, and group-level considerations. Source: Commission Delegated Regulation (EU) 2025/1190 on TLPT RTS.

On the supply side, capability is much harder to scale. You cannot instantly create senior adversary-simulation teams with financial-sector context, production-safety discipline, regulatory credibility, threat-intelligence capability, and insurance coverage.

That is the bottleneck: regulation can create demand faster than the market can create trust.

Provider selection is not “just procurement”

A financial entity cannot treat TLPT provider selection like buying a standard pentest.

DORA Article 27 requires suitable and reputable testers with technical and organisational capabilities, specific expertise in threat intelligence, penetration testing and red-team testing, and appropriate assurance, risk-management and insurance arrangements. Source: DORA Regulation (EU) 2022/2554, Article 27.

In practical terms, a credible provider selection filter needs to show:

• relevant TLPT / TIBER-style references
• named experienced threat-intelligence and red-team staff
• independence and conflict-of-interest control
• safe production-testing procedures
• evidence, replay, and reporting discipline
• insurance, confidentiality, and data-handling controls

The entity still selects and contracts the providers, but the choice must survive TLPT authority and supervisory scrutiny. This is one of the natural filters against fake TLPT.

You can buy a pentest vendor. You need to justify a TLPT provider.

The fake TLPT trap

Whenever a market has mandatory demand, scarce trusted capacity, and attractive commercial value, shortcuts will appear.

The obvious shortcut is language.

Take a normal pentest. Add phrases like “APT-like”, “threat-led”, “AI-powered”, “regulatory-ready”, and “executive cyber war game”. Package it nicely. Sell it as TLPT-flavoured work.

That may look convincing in a sales deck, but it misses the substance.

Fake TLPT usually lacks the things that make TLPT valuable:

• targeted threat intelligence
• safe production execution
• Control Team process
• evidence chain
• replay and purple-team learning
• remediation-quality reporting
• supervisory credibility

The shortcut is branding. The path is capability.

AI helps, but it does not solve the bottleneck

AI can reduce friction in TLPT-related work, but it does not remove governance ownership.

That distinction matters. Under DORA, TLPT is not just an analytical exercise. It is testing of critical or important functions, performed on live production systems supporting those functions, with the financial entity remaining responsible for the impact of the test. That makes accountability, safety and evidence part of the work, not administrative decoration. Source: DORA Regulation (EU) 2022/2554, Article 26.

AI can support reconnaissance, OSINT synthesis, scenario ideation, ATT&CK mapping, detection-query drafting, replay preparation, reporting structure and evidence organisation. Used well, it can make teams faster and more consistent.

But as with any serious AI integration, the important question is not only what can the model produce? It is also who owns the decision, the data, the validation and the consequence?

That framing is consistent with the direction of the EU AI Act. For general-purpose AI models, the Act introduces documentation and transparency obligations; for models with systemic risk, it adds requirements for model evaluation, adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting, and cybersecurity protection. Sources: Regulation (EU) 2024/1689 and harmonised rules on artificial intelligence, AI Act Chapter V: General-Purpose AI Models - Article 55: Obligations of providers of general-purpose AI models with systemic risk.

In TLPT, this becomes very concrete. AI does not own risk acceptance. It does not decide whether an exploit should run in production. It does not make weak evidence true. It does not absorb liability. It does not create regulator trust.

The useful model is not “autonomous TLPT”.

The useful model is governed AI-assisted testing:

• approved tooling
• data boundaries
• human approval gates
• prompt and output logging
• evidence validation
• no autonomous production exploitation

AI reduces friction | It does not absorb accountability

The realistic path for smaller providers

This topic became practical for us while building SPARK42 toward more mature offensive-security capability. I presented this thinking at BSides Bratislava 2026 in a talk titled “Mandatory Hacking Meets Reality: The DORA TLPT Bottleneck. The presentation used a game-map metaphor, but the core message was simple: TLPT-grade capability cannot be claimed into existence.

The wrong path is:

pentest
↓
rename to red team
↓
sell TLPT

The honest path is slower:

pentesting / assessments
↓
disciplined adversary simulation
↓
evidence and safety discipline
↓
readiness / replay / detection validation
↓
trusted partnerships
↓
TLPT-grade capability

That does not mean small providers have no role until they become formal TLPT providers.

There is valuable work around TLPT:

• TLPT-readiness assessment
• Control Team preparation
• TIBER-style non-formal exercises
• detection validation
• purple-team replay
• evidence and remediation validation

That work is useful now. It is also honest now.

It helps financial entities become testable, improves defensive learning, and builds the delivery discipline needed for more advanced work later.

What practitioners should take from this

For individual hackers, pentesters, defenders, and security engineers, the message is also practical. The future high-value offensive practitioner is not only the person who can get in.

It is the person who can:

• get in
• prove what happened
• explain the impact
• avoid unnecessary harm
• help defenders improve

That means combining offensive skill with campaign thinking, threat intelligence, OPSEC, evidence discipline, detection awareness, safe execution, and risk communication.

For defenders, TLPT is not only about watching an attacker succeed. The value appears in replay, telemetry analysis, detection improvement, incident timelines, and remediation validation.

A good attack path is useful. A replayable attack path is valuable.

The real bottleneck

DORA did not create a simple hacker shortage.

It exposed a trust-capacity shortage.

The market will need offensive-security teams that are not only technically sharp, but also threat-led, production-safe, evidence-driven, governed, accountable, and useful for defenders.

That is harder to build than a services page.

And that is the real TLPT bottleneck.

Exploits get attention. Evidence earns trust. Governance gets you invited back.