Threat-Led Penetration Testing for Crypto Firms
DORA Threat-Led Penetration Testing (TLPT) for crypto firms mapped provision by provision: the Article 26(8) designation gate that decides which CASPs owe TLPT at all, how it differs from ordinary Article 25 testing, the ECB TIBER-EU phases behind it, tester requirements under Article 27 and the evidence a regulator expects afterward.
14 min read
22 views
Key takeaways: DORA TLPT for crypto firms 5
What Article 26 actually requires, who it applies to and what a security or engineering lead should have ready before a designation arrives.
- TLPT scope is by designation, not automatic for every CASP Article 26(8) lets a competent authority designate which entities must run TLPT based on impact, systemic character and ICT risk profile, with microenterprises excluded and proportionality applied. A CASP not designated still owes ordinary Article 25 testing, not Article 26 TLPT.
- TLPT runs on live production, at least every 3 years Article 26 tests cover several or all critical or important functions and are performed on live production systems, not staging environments, at a floor cadence of at least every 3 years, adjustable by the competent authority.
- The methodology is ECB TIBER-EU, aligned to the DORA RTS Preparation and scoping, threat intelligence, red team testing and closure are the TIBER-EU stages the DORA RTS on TLPT was built to align with, run by a Control Team, an unwitting Blue Team, an external Red Team and an external threat intelligence provider.
- Testers must be certified and independent, threat intelligence always external Article 27 requires testers with certified or code-of-conduct-backed expertise and professional indemnity insurance. Internal red teams need authority approval and conflict-of-interest controls, but the threat intelligence provider must always sit outside the financial entity.
- The TLPT RTS has been in force since 8 July 2025 Commission Delegated Regulation (EU) 2025/1190 supplements DORA on TLPT, published in the Official Journal on 18 June 2025 and applicable from 8 July 2025, and it is a separate instrument from the Article 28 Register of Information that feeds TLPT scoping.
Threat-led penetration testing sits at the top of a testing hierarchy DORA builds in two layers, not one. Article 25 sets a universal testing program, vulnerability assessments, scans, gap analyses and ordinary penetration testing, that applies to essentially every financial entity within DORA's scope, MiCA-authorized CASPs included. Article 26 sits above that baseline as an advanced, adversarial tier, and it does not apply automatically. It applies only to the financial entities a competent authority designates under Article 26(8), based on the entity's impact on the financial sector, its systemic character and its ICT risk profile, with proportionality applied and microenterprises excluded outright. A CASP that has never been designated still owes Article 25 testing. It does not owe Article 26 TLPT until a competent authority puts it in scope. This article works through what TLPT actually requires, how the designation question gets decided, the TIBER-EU mechanics behind the test itself and what a security or engineering lead should have ready if their firm is asked to run one.
In short: DORA's Threat-Led Penetration Testing (TLPT) under Article 26 is mandatory only for financial entities a competent authority designates under Article 26(8), not for every MiCA-authorized CASP by default. Designated entities run TLPT at least every 3 years, on live production systems, covering several or all critical or important functions. The methodology follows the ECB's TIBER-EU framework, which the joint RTS, Commission Delegated Regulation (EU) 2025/1190, was built to align with: preparation and scoping, threat intelligence, red team testing and closure. Article 27 sets tester requirements, certified or code-of-conduct-backed expertise, professional indemnity insurance and, where an internal red team is used, mandatory authority approval plus an external threat intelligence provider regardless. The RTS took effect 8 July 2025, and it is a separate instrument from the Article 28 Register of Information, which supplies the critical-function and ICT-provider inventory that TLPT scoping draws on.
What DORA Threat-Led Penetration Testing requires
Article 26(1) is precise about who it binds: financial entities "other than entities referred to in Article 16(1)" and "other than microenterprises", which are "identified in accordance with paragraph 8". That wording rules out reading Article 26 as a blanket obligation. It names a designated subset, and it names an excluded floor, microenterprises, explicitly. Designated entities must carry out advanced testing by means of TLPT at least every 3 years, and a competent authority may request a reduced or increased frequency based on the entity's own risk profile.
Each test has to cover several or all of the entity's critical or important functions, and it has to be performed on live production systems supporting those functions, not a staging environment or a tabletop exercise. That live-system requirement is what separates TLPT from a conventional assessment: the adversary simulation runs against the systems clients actually use, under rules of engagement negotiated in advance with the authority overseeing the test.
The table below separates what is statutory in DORA itself from what sits in the RTS and the TIBER-EU guidance layer underneath it, since the three carry different binding weight and get blended together in vendor summaries more often than not.
| Provision | What it requires | Binding |
|---|---|---|
| Art 25 | Universal ICT testing program (vulnerability assessments, scans, gap analyses, ordinary penetration testing) for essentially all in-scope financial entities | Yes |
| Art 26(1) | TLPT at least every 3 years for entities designated under paragraph 8, excluding microenterprises | Yes |
| Art 26(8) | Competent authority identifies which entities must run TLPT, based on impact, systemic character and ICT risk profile, applying proportionality | Yes |
| Art 26(11) | Mandates the ESAs, with the ECB, to develop RTS on TLPT in accordance with TIBER-EU | Yes |
| Art 27(1) | Tester suitability, reputability and certified or code-of-conduct-backed expertise | Yes |
| Art 27(2) | Internal testers conditionally allowed with authority approval; threat intelligence provider always external | Yes |
| Commission Delegated Regulation (EU) 2025/1190 | RTS instrument itself, in force since 8 July 2025, setting identification criteria, scope, methodology and supervisory cooperation rules | Yes |
| ECB TIBER-EU framework | Threat intelligence-based ethical red-teaming methodology the RTS was built to align with | No, methodology guidance |
Is your CASP in mandatory TLPT scope
The scope question is a designation question, not a license-class question. Article 26(8) hands the identification decision to the competent authority, and it lists the factors that decision has to weigh: how much the entity's services and activities impact the financial sector, whether financial stability concerns arise, including the entity's systemic character, and the entity's specific ICT risk profile, level of ICT maturity or technology features. The RTS further specifies these identification criteria, and the authority is required to apply proportionality across the exercise.
In practice that means a small or non-systemic CASP will typically sit outside mandatory TLPT, while a large exchange or custodian with material market share, deep interconnection to the wider financial system or a complex ICT footprint is a plausible designation candidate. Neither position is guaranteed by size alone. The designation is the authority's call, made against the Article 26(8) criteria, not a self-assessment a CASP can settle by reading its own license.
What every CASP owes regardless of designation is Article 25's ordinary testing program. Treating TLPT readiness as optional until a designation letter arrives is the wrong posture. A security or engineering lead should know where the firm sits against the impact and systemic-character criteria well before a competent authority raises the question, because building TLPT-ready processes, an accurate function inventory, clean rules-of-engagement documentation, a defensible testing history, takes considerably longer than a single test cycle.
TLPT versus ordinary Article 25 testing
The two testing tiers differ on every dimension that matters operationally. Article 25 testing is universal, applies to essentially all in-scope entities regardless of size, and covers a broad toolkit: vulnerability assessments, open source analysis, network security assessments, gap analyses and standard penetration testing. It is scenario-agnostic in the sense that it does not simulate a specific adversary's tradecraft against a specific business function; it checks for known classes of weakness across the estate.
Article 26 TLPT is narrower in population and deeper in method. It applies only to designated entities, it is intelligence-led rather than checklist-driven, meaning an external threat intelligence provider builds a targeted scenario based on realistic adversary behavior before the red team ever touches a system, and it runs against live production infrastructure supporting critical or important functions rather than a representative sample of the estate. Confusing the two tiers, describing an annual vulnerability scan as "our TLPT" or assuming TLPT readiness satisfies the Article 25 baseline, is the single most common category error in how firms talk about DORA testing obligations.
Inside the TIBER-EU testing cycle
DORA's TLPT methodology is not a bespoke invention. Article 26(11) directs the RTS to be built "in accordance with the TIBER-EU framework", the ECB's existing framework for threat intelligence-based ethical red-teaming, and the Eurosystem updated TIBER-EU itself to align with the DORA RTS once it was adopted. A CASP preparing for TLPT is, in effect, preparing to run a TIBER-EU engagement under a DORA legal wrapper.
TIBER-EU structures a test into three named stages, Preparation, Testing and Closure, and the Testing stage splits further into a threat intelligence phase and a red-team phase. The table below sets out what happens at each stage and who leads it. Specific week-by-week durations circulate in vendor marketing. The RTS does set a floor for the active red team testing phase, at least 12 weeks under Article 11 of Commission Delegated Regulation (EU) 2025/1190, but it does not fix durations for the preparation or threat-intelligence phases, so treat other week-by-week figures as TIBER-EU practice rather than DORA law.
| Phase | What happens | Who leads |
|---|---|---|
| Preparation and scoping | Defines scope over critical or important functions, agrees rules of engagement, submits scope to the TLPT authority for validation | Control Team (White Team), authority validates |
| Threat intelligence | Builds a Targeted Threat Intelligence report from realistic adversary scenarios and reconnaissance, driving the attack plan | External threat intelligence provider |
| Red team testing | Adversarial simulation against live production critical functions, following the intelligence-driven scenarios | External Red Team, Control Team manages rules of engagement |
| Closure and purple teaming | Red Team and Blue Team replay the attack together, capture detection gaps and agree remediation | Red Team and Blue Team jointly, Control Team coordinates |
| Reporting and remediation | Test report, blue-team report, remediation plan and attestation delivered to the authority | Entity prepares, authority attests |
Preparation and scoping
The Control Team, sometimes called the White Team, is a small internal group that commissions and manages the test. In most engagements it is the only staff inside the firm who know a live test is underway; that secrecy is deliberate, because the point of the exercise is to see how the firm's actual defenders respond to an attack they do not know is a drill. Scoping fixes which critical or important functions the test will target and gets validated by the authority before testing begins.
Threat intelligence
An external threat intelligence provider researches realistic adversary tradecraft against the scoped functions and produces the scenario the red team will execute. This phase happens before any system is touched, and DORA requires the provider running it to sit outside the financial entity in every case, even where the red team itself is internal.
Red team testing
The red team executes the intelligence-driven scenario against live production systems supporting the scoped critical or important functions, under rules of engagement the Control Team manages. This is where "live production" stops being a compliance phrase and becomes an operational constraint: the test has to be designed so it can be safely aborted without disrupting client-facing service if something goes wrong.
Closure and purple teaming
Once the red-team phase ends, the Red Team and Blue Team come together to replay the attack step by step, so the Blue Team can see exactly what it missed and why. That joint replay, purple teaming, is an activity that happens during Closure, not a separately hired role, and it feeds directly into the remediation plan and the reports the entity submits to the authority.
Who is allowed to run the test
Article 27(1) sets a high bar for testers: the highest suitability and reputability, technical and organizational capabilities and demonstrated specific expertise in threat intelligence, penetration testing and red team testing. Testers have to be certified by a Member State accreditation body or adhere to formal codes of conduct or ethical frameworks, provide independent assurance or an audit report on sound risk management of the risks involved, and carry professional indemnity insurance covering misconduct and negligence.
Internal testers are not banned outright, but the conditions are narrow. Article 27(2) permits their use only where the competent authority, or the single public authority a Member State has designated for TLPT, approves the arrangement, verifies that the entity has sufficient dedicated resources and confirms conflicts of interest are avoided across the design and execution of the test. Even where all of that is satisfied, the threat intelligence provider building the attack scenario must be external to the financial entity in every case. An in-house red team can execute a test; it cannot also supply the intelligence that shapes what it attacks. The RTS, Commission Delegated Regulation (EU) 2025/1190, also requires that at least every third TLPT use a fully external red team.
Mapping a CASP's critical functions into scope
DORA defines a critical or important function by its disruption impact: a function whose failure would materially impair the entity's financial performance, the soundness or continuity of its services, or its compliance with applicable law. It does not publish a crypto-specific list of which systems that covers, so any function inventory a CASP builds is a reasoned mapping from that definition, not a citation to a regulatory enumeration.
Applying the definition to a typical CASP's architecture, the functions that would plausibly land in TLPT scope include custody key-management and transaction-signing infrastructure, hot-wallet and withdrawal systems, the exchange matching or order engine, on-chain settlement and reconciliation and customer-facing trading access. Present that list to an auditor as engineering judgment applied to the Article 26 definition, never as a statutory checklist DORA hands down by name.
Building that function inventory does not start from a blank page for most CASPs. The Register of Information a financial entity maintains under Article 28 already identifies which ICT third-party providers support each critical or important function, and that inventory is exactly what feeds TLPT scoping when a designation arrives. Our companion article on the DORA Register of Information for crypto firms covers the data model behind that inventory in full.
What regulators expect as evidence
A completed TLPT engagement produces a defined evidence trail, not a single pass or fail verdict. The red team delivers a test report describing what it attempted and achieved. The Blue Team's own report captures what it detected, what it missed and why. Those two feed a remediation plan addressing the gaps the test surfaced, and the entity submits an attestation to the authority overseeing the exercise confirming the test ran to the agreed scope and rules of engagement.
The RTS behind this evidence chain, Commission Delegated Regulation (EU) 2025/1190, is the instrument that fixes the shared methodology testers, entities and authorities all follow, and it took effect 20 days after publication in the Official Journal on 18 June 2025, applicable from 8 July 2025. An entity that can produce all four artifacts on request, test report, blue-team report, remediation plan and attestation, is demonstrating the process worked as designed, not merely that a red team was hired once.
Common TLPT mistakes
The most frequent error is assuming every MiCA-authorized CASP owes Article 26 TLPT simply because it holds a license. Designation under Article 26(8) is the gate, and microenterprises are excluded outright, so a firm's actual obligation until it is designated is the universal Article 25 testing program, not the advanced tier.
A second common error folds an ordinary vulnerability scan or penetration test into the TLPT label. The two sit on different legal footing, apply to different populations and follow different methodologies, and a supervisor reviewing a firm's testing history will not accept an Article 25 activity described as satisfying Article 26.
A third error states TLPT frequency or phase durations more precisely than the law does. "At least every 3 years" is a floor an authority can tighten, not a fixed interval. The RTS does fix a minimum for the active red team testing phase, at least 12 weeks under Article 11, so that floor is a citable DORA requirement. It does not fix statutory durations for the preparation or threat-intelligence phases, so treat those numbers as TIBER-EU guidance.
A fourth error assumes an internal red team is freely permitted once a firm decides it is capable. Article 27 requires authority approval and conflict-of-interest controls for internal testers, and the threat intelligence provider must be external in every case, including when the red team itself sits inside the firm.
A fifth error treats the crypto-specific critical-function list, custody signing infrastructure, hot wallets and the rest, as something DORA names directly. It is a mapping exercise from the disruption-impact definition, and presenting it to a regulator as a cited statutory list rather than reasoned scoping overstates what the text actually says.
How Pharos Production helps
We build the engineering side of TLPT readiness for CASPs: a defensible critical-function inventory mapped from the Article 26 disruption-impact definition rather than guesswork, rules-of-engagement documentation and safe-abort mechanisms for testing against live production custody and trading infrastructure, and the evidence trail, test reports, blue-team findings, remediation tracking and attestation records, structured so it holds up whether a designation arrives next quarter or several years out. If your platform needs to know where it stands against Article 26(8) or wants its critical functions and testing evidence in shape before that question comes up, we can walk through what that looks like for your architecture.
See our MiCA compliance software development services.
Sources: Regulation (EU) 2022/2554 (DORA), Articles 25, 26 and 27, full text via EUR-Lex and the digital-operational-resilience-act.com mirror. Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal 18 June 2025, applicable 8 July 2025 (EUR-Lex; A&O Shearman FinReg; Katten QuickReads). ESAs Final Report JC 2024-29 on the draft RTS for TLPT. ECB TIBER-EU framework pages, including the Eurosystem's alignment update to the DORA TLPT RTS.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
No. TLPT under Article 26 is mandatory only for financial entities a competent authority designates under Article 26(8), based on impact on the financial sector, systemic character and ICT risk profile, with proportionality applied and microenterprises excluded. Every CASP still carries the universal duty under Article 25 to run ordinary ICT testing, TLPT is an additional, designation-gated tier on top of that baseline.
-
Article 25 testing (vulnerability assessments, scans, open source analysis, network security assessments, gap analyses, penetration testing) applies to essentially every in-scope financial entity and is scenario-agnostic. Article 26 TLPT is the advanced tier: intelligence-led, adversarial, run on live production systems supporting critical or important functions, and reserved for entities a competent authority has designated.
-
At least every 3 years for a designated entity, per Article 26(1). A competent authority may request a reduced or increased frequency based on the entity's risk profile, so the 3-year mark is a floor rather than a fixed cadence.
-
Conditionally. Article 27 allows internal testers only if the competent authority, or the single public authority designated for TLPT, approves their use and verifies dedicated resources and conflict-of-interest controls across design and execution.
Even then, the threat intelligence provider supplying the attack scenarios must always be external to the financial entity.
-
DORA defines a critical or important function by its disruption impact, not by naming crypto systems directly. Reasoning from that definition, a CASP's scope would typically include custody key-management and transaction-signing infrastructure, hot-wallet and withdrawal systems, the matching or order engine, on-chain settlement and reconciliation and customer-facing trading access.
This is engineering judgment applied to the definition, not a published regulatory list.
-
A test report from the red team, a blue-team report on detection and response, a remediation plan for the gaps found and an attestation submitted to the authority overseeing the test. Commission Delegated Regulation (EU) 2025/1190 sets the shared methodology testers, entities and authorities follow, in line with the TIBER-EU framework.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
