What Is Threat-Led Penetration Testing

Threat-led penetration testing (TLPT) is an advanced form of red team exercise that uses real-world threat intelligence to define the scenarios, tactics, techniques, and procedures (TTPs) used during testing. Unlike a conventional penetration test, which assesses a defined scope for known vulnerability classes, TLPT starts by answering a different question: which specific threat actors are most likely to target this organisation, and what would their attack look like in practice?

The answer to that question drives everything that follows. The threat intelligence phase produces a structured report profiling the firm's most relevant adversaries, their preferred initial access methods, their lateral movement techniques, and their ultimate objectives. Red team testers then execute those specific scenarios against live production systems, targeting not just technical vulnerabilities but the full kill chain from initial compromise through to the attacker's end goal, whether that is exfiltrating assets, manipulating transaction flows, or achieving persistent access.

TLPT is a controlled but realistic simulation of an advanced persistent threat. It is specifically designed to test whether the organisation's detection and response capabilities can identify and contain a sophisticated, targeted attack. For financial entities, this is precisely the threat category that poses the most significant systemic risk. Automated scanning tools and standard penetration tests do not surface the weaknesses that allow nation-state actors and professional criminal groups to operate undetected inside a network for months.

The term TLPT in the EU regulatory context refers specifically to testing that meets the requirements set out in DORA Article 26 and the associated regulatory technical standards. DORA compliance mandates that significant financial entities conduct TLPT at least every three years, with the scope, methodology, and assurance requirements defined in the framework.

Who Is in Scope for DORA TLPT

DORA applies to a broad range of financial entities, and its TLPT requirement does not apply universally across all of them. The TLPT obligation under Article 26 applies specifically to financial entities designated as significant by their relevant national competent authority (NCA). Designation as significant is not automatic; it is a formal supervisory determination based on criteria including systemic importance, scale, nature of operations, and interconnectedness with other financial infrastructure.

The categories of financial entity subject to DORA that may be designated as significant for TLPT purposes include:

• Crypto-asset service providers (CASPs): Firms authorised under MiCA to provide one or more crypto-asset services, including custody and administration of crypto-assets on behalf of clients, operation of a trading platform, exchange of crypto-assets for funds or other crypto-assets, and portfolio management. CASPs that operate at significant scale, hold material assets under management, or are systemically interconnected with other financial entities are most at risk of designation.
• Payment institutions: Firms authorised under the Payment Services Directive that have integrated crypto payment or settlement rails are in scope for DORA and potentially for TLPT designation.
• Credit institutions with crypto exposure: Banks providing custody, trading, or lending services against crypto-assets face TLPT obligations through their existing DORA obligations as credit institutions, with the crypto-specific aspects of their ICT systems likely to be included in any TLPT scope.
• Electronic money institutions: EMIs that have built stablecoin or tokenised payment products sit squarely within the DORA scope and may be designated for TLPT based on their systemic importance.

It is important to note that even firms not formally designated for TLPT benefit from conducting TLPT-equivalent exercises voluntarily. The designation creates a mandatory floor; it does not create a ceiling. Institutional investors and counterparties increasingly regard voluntary TLPT as a meaningful indicator of security programme maturity. For firms preparing for MiCA authorisation or DORA supervisory review, a completed TLPT exercise provides substantive evidence of ICT resilience testing capability.

The TLPT requirement also has a third-party dimension. Under DORA Article 26(8), where a financial entity's critical ICT functions are outsourced to a third-party ICT provider, the NCA may require that provider to participate in the TLPT scope. This has direct implications for crypto firms that rely on third-party custody technology, institutional-grade key management infrastructure, or outsourced security operations. Firms should review their critical third-party dependencies and assess whether those dependencies would be included in any TLPT scope.

How TLPT Differs from Standard Penetration Testing

The distinction between TLPT and standard penetration testing matters because it changes the preparation required, the value delivered, and the resources involved. Firms that approach TLPT as a larger or more expensive penetration test are likely to be disappointed by both the process and the outcome.

Standard penetration testing is a structured technical assessment against a defined scope. A tester is given a list of systems, applications, or network ranges and asked to identify vulnerabilities within a defined time period, typically one to four weeks. The methodology is often compliance-driven, following frameworks such as OWASP or the PTES, and the output is a vulnerability report with risk ratings and remediation recommendations. Standard penetration testing is valuable, particularly for identifying technical weaknesses in specific systems. Our post on penetration testing costs for crypto firms covers scope and pricing for standard engagements in detail.

TLPT operates on a fundamentally different model across several dimensions:

Intelligence-driven scope. In TLPT, the scope is not a list of IP addresses or application URLs. The scope is defined by the threat intelligence assessment of which threat actors are relevant and which parts of the firm they would most likely target. This means the scope can include people (social engineering), physical access, and supply chain vectors that standard penetration tests typically exclude.

Scenario-based execution. Red team testers in a TLPT exercise are executing specific attack scenarios derived from the threat intelligence report. They are simulating a named or profiled threat actor, not simply looking for any vulnerability they can find. This makes the exercise directly relevant to the firm's actual threat environment rather than a generic assessment of vulnerability density.

Live production systems. TLPT is conducted against live production systems, not test environments. This is both a source of additional risk that must be carefully managed and the source of its superior validity. Testing against production systems means the detection and response capabilities being tested are the ones that actually matter.

Defensive integration. TLPT explicitly tests the blue team, not just the red team. The exercise is designed to assess whether the organisation's security operations, monitoring, and incident response capabilities can detect and respond to an advanced attack. Standard penetration tests typically do not engage the defensive team at all. Our coverage of red team and blue team exercises for crypto provides foundational context for how both sides of this equation function.

Duration and depth. Standard penetration tests typically run for days or a few weeks. TLPT exercises are structured over a period of months: the threat intelligence phase alone typically takes four to eight weeks, and the red team execution phase may run for eight to twelve weeks. This duration allows red teamers to use slow, stealthy attack techniques that would not be viable in a short-duration test, which is precisely what advanced persistent threat actors do.

Regulatory assurance. For DORA purposes, TLPT must meet specific quality standards defined in the regulatory technical standards. The intelligence providers and red team testers must meet defined competency and independence requirements. Self-conducted TLPT-equivalent exercises do not satisfy the DORA obligation for designated entities; the exercise must be conducted by qualified external providers operating within the regulatory framework.

TIBER-EU: The EU Framework for TLPT

The TIBER-EU (Threat Intelligence-Based Ethical Red Teaming for the European Union) framework, published by the European Central Bank, is the reference framework for TLPT in the EU. DORA's TLPT requirements are directly aligned with TIBER-EU, which means that firms undertaking TLPT to satisfy DORA should use TIBER-EU as their primary implementation guide.

TIBER-EU is built around three phases: the preparation phase, the testing phase, and the closure phase. Each phase has defined deliverables, roles, and quality standards that must be met for the exercise to be recognised as compliant by supervisory authorities.

Within the testing phase, TIBER-EU distinguishes between the Targeted Threat Intelligence (TTI) phase and the Red Team Testing (RTT) phase. The TTI phase is conducted by a specialist threat intelligence provider who produces a bespoke report on the firm's specific threat landscape. This report is not a generic cyber threat briefing; it is a detailed assessment of the threat actors, motivations, and TTPs most relevant to the specific firm based on its sector, geography, asset profile, and known adversary targeting. The RTT phase uses that intelligence to design and execute the red team scenarios.

TIBER-EU also defines the roles of the Test Manager (typically a senior security or compliance official within the firm), the White Team (a small group within the firm that is aware of the test and manages its coordination), and the Blue Team (the firm's existing security operations, which must remain unaware that a test is taking place in order for the exercise to produce valid results about detection capability).

National implementations of TIBER exist across the EU: TIBER-NL (Netherlands), TIBER-BE (Belgium), TIBER-DE (Germany), TIBER-DK (Denmark), and others. These national frameworks adapt the core TIBER-EU structure to local supervisory requirements. Firms operating in multiple EU jurisdictions should identify which national framework applies to their primary supervisory relationship.

DORA's regulatory technical standards for TLPT, published by the ESAs in 2024, align closely with TIBER-EU but include some additional requirements specific to the DORA context, including requirements around the documentation of TLPT results and the remediation programme. Firms should review both the TIBER-EU framework and the DORA RTS when planning their first TLPT exercise.

The TLPT Process Step by Step

Understanding the full TLPT process before initiating it allows firms to plan accurately for resource requirements, timeline, and the internal capabilities they need to have in place. A typical TLPT exercise for a financial entity of moderate complexity runs over six to twelve months from initiation to closure report.

Phase 1: Preparation and Scoping

The preparation phase begins with the appointment of the Test Manager and the White Team. The White Team typically comprises the CISO, a senior member of the compliance function, and a representative of executive management. The firm's NCA may need to be notified or consulted at this stage, depending on whether the TLPT is being conducted under regulatory designation or voluntarily.

The scope of the exercise is defined during preparation. Scope definition covers which systems, services, and physical or organisational boundaries will be in scope for red team testing. For crypto firms, this typically includes trading infrastructure, custody systems, internal communication platforms, identity and access management systems, and the people who operate them. The scope should be sufficiently broad to allow realistic simulation of the threat scenarios identified in the intelligence phase.

Provider selection occurs during preparation. The threat intelligence provider and red team provider must be selected. TIBER-EU and DORA both specify that these providers must meet defined competency requirements. In most jurisdictions, a register of approved or recognised providers is maintained by the NCA or central bank. Firms should verify whether their chosen providers are recognised in the relevant national framework.

Phase 2: Threat Intelligence Phase

The Targeted Threat Intelligence (TTI) phase is where TLPT diverges most sharply from standard penetration testing. The threat intelligence provider undertakes a detailed assessment of the threat landscape specific to the firm. This assessment draws on open source intelligence, proprietary threat intelligence feeds, dark web monitoring, analysis of peer-organisation incidents, and direct engagement with the firm to understand its business model, technology stack, and known threat history.

The output of the TTI phase is a formal Targeted Threat Intelligence report. This report profiles the most relevant threat actor groups, describes their objectives and capabilities, identifies the attack vectors they are most likely to use against the firm specifically, and proposes the specific red team scenarios to be executed. The TTI report is the blueprint for the red team exercise.

For crypto firms, common threat actor profiles identified in TTI reports include nation-state actors targeting high-value digital assets (particularly North Korean threat groups with a documented history of targeting crypto exchanges and custodians), financially motivated criminal groups using social engineering and malware to gain access to key management infrastructure, and insider threat scenarios based on access to privileged systems and key material.

Phase 3: Red Team Planning

Using the TTI report, the red team provider develops a detailed test plan. The test plan translates each threat scenario into specific attack sequences with defined TTPs, timelines, and success criteria. The test plan is reviewed and approved by the White Team before execution begins. The Blue Team remains unaware of the test plan.

Red team planning for crypto firms must account for the operational sensitivity of live production systems. Attack scenarios that could cause genuine service disruption or asset loss require specific safeguards and escalation procedures. The White Team must have clear authority to pause or halt the exercise if a red team action risks causing actual harm to production systems or customer assets.

Phase 4: Red Team Execution

The red team execution phase is the live testing period. Red teamers attempt to execute the defined scenarios against production systems using the agreed TTPs. The execution phase typically runs for eight to twelve weeks for a comprehensive exercise, though timelines vary based on scope complexity and the number of scenarios being tested.

During execution, the red team maintains detailed logs of every action taken. These logs are critical for the closure phase, both for the purple team review and for the assurance documentation required under DORA. Red teams operating under TIBER-EU are required to log timestamps, systems accessed, techniques used, and outcomes achieved for every action in the exercise.

The Blue Team operates normally throughout execution. If they detect anomalous activity and begin responding to it, that is a valid and valuable outcome of the exercise. How the Blue Team responds, including whether it correctly identifies the activity as a red team exercise or treats it as a genuine incident, is itself an important data point about detection and response maturity.

Phase 5: Purple Team Exercise

The purple team phase brings the red and blue teams together in a structured debrief after the red team exercise concludes. The purpose is not simply to review what happened but to transfer knowledge from the red team to the blue team in a way that directly improves defensive capabilities.

In the purple team exercise, red teamers walk through each technique they used and the outcome: was it detected, was it blocked, did it produce an alert, did the blue team respond appropriately. For each technique that went undetected or was not responded to effectively, the teams work together to understand why and to identify what detection rules, monitoring configurations, or response procedures would need to change to address the gap.

The purple team phase is where a significant portion of the security programme improvement value from TLPT is generated. The red team and blue team exercises for crypto model works precisely because the offensive and defensive perspectives are brought together in this structured way rather than producing a report that sits unimplemented.

Phase 6: Reporting and Remediation

The TLPT exercise closes with a formal report covering the threat intelligence findings, the red team execution outcomes, the purple team findings, and the identified gaps. Under DORA, this report must be submitted to the NCA if the exercise was conducted under regulatory designation. The firm must also produce a remediation plan addressing the identified findings.

Remediation planning after TLPT is covered in more detail in the section on security governance below. The remediation plan should be treated as a security programme improvement project with defined owners, timelines, and success criteria rather than as a compliance document.

Prerequisites: What Your Firm Must Have in Place

TLPT is designed to test an organisation that has a baseline of security controls and operational capability in place. Attempting TLPT without those prerequisites will result in an exercise that surfaces fundamental operational gaps rather than providing the nuanced testing of advanced detection and response capabilities that TLPT is designed for.

The following prerequisites should be in place before a crypto firm initiates a TLPT engagement:

Asset Register and System Documentation

An up-to-date asset register covering all systems, services, and infrastructure components is the foundation for scope definition. Without a comprehensive asset register, it is not possible to define an accurate TLPT scope or to ensure that the most critical systems are included. The asset register should cover both on-premises and cloud infrastructure, including third-party integrations, API dependencies, and outsourced services. For crypto firms, this must specifically include all wallet infrastructure, key management systems, and the networks connecting them.

Incident Response Plan

A documented and tested incident response plan is essential for two reasons. First, the TLPT exercise will generate security events that the Blue Team may treat as genuine incidents; without a tested IR plan, the response will be chaotic and the detection data from the exercise will be unreliable. Second, one of the key outcomes of TLPT is an assessment of IR capability. If the IR plan does not exist or has never been tested, there is nothing to assess.

Access Control Documentation

Formal access control documentation, covering who has access to which systems, under what authorisation, and with what review frequency, is required for the red team to accurately model insider threat scenarios and for the purple team phase to assess whether privileged access was appropriately monitored. Access control documentation includes IAM policies, privileged access management procedures, and service account registers.

Security Monitoring Baseline

The Blue Team needs a functioning security operations capability to run the defensive side of the TLPT exercise. This means centralised logging, a SIEM or equivalent detection capability, and defined monitoring procedures. A firm that has no security monitoring capability will have nothing meaningful to test on the defensive side of TLPT. The value of TLPT is precisely in testing whether existing monitoring and detection capabilities can identify advanced adversary behaviour; if those capabilities do not exist, the exercise cannot deliver that value.

Key Management and Custody Controls

For crypto firms specifically, the key management and custody control environment must be documented and operational before TLPT begins. Red team scenarios targeting wallet infrastructure and key management systems require the firm to have defined access controls, approval workflows, and monitoring in place for those systems. Firms with immature key management controls should address those gaps, ideally supported by a review of hardware security module deployment and multi-signature governance, before proceeding to TLPT.

Internal Project Governance

TLPT requires active management over a period of months. The firm must have a designated Test Manager with appropriate authority and availability, a White Team that can commit time to oversight and decision-making, and legal counsel that has reviewed the scope and rules of engagement. Firms that initiate TLPT without adequate internal governance in place frequently encounter delays and scope disputes mid-exercise that undermine the quality of the outcome.

"TLPT is not a test you buy and forget. It is a structured, multi-month operational exercise that requires active participation from your most senior security and compliance personnel. Firms that treat it as a vendor-managed process rather than an internal programme will consistently underperform on the defensive side of the exercise."

Common Findings from Financial Entity TLPT Exercises

Drawing on findings from TLPT exercises conducted at financial entities across the EU, several patterns emerge consistently. These common findings provide a useful benchmark for crypto firms undertaking their first TLPT or preparing for designation.

Social Engineering Success Rates

Social engineering remains one of the most consistently successful initial access vectors in TLPT exercises against financial entities. Spear-phishing campaigns targeting employees with access to privileged systems and key material achieve high click and credential capture rates, even at firms with formal security awareness training programmes. The most effective social engineering scenarios exploit urgent operational contexts, such as simulated alerts about account compromise or requests from apparent counterparties for urgent transaction authorisation.

For crypto firms, social engineering scenarios specifically targeting people with access to signing keys or custody infrastructure are particularly concerning. Red teams operating under Lazarus Group or similar APT TTPs frequently achieve initial access via targeted social engineering of engineers or operations staff, as documented across multiple major crypto exchange compromises.

The finding from most TLPT exercises is not simply that phishing works, but that detection of successful phishing is poor. Firms frequently have no automated detection of credential use from anomalous locations or devices following a successful phish, meaning that an attacker who captures credentials can use them for extended periods before being identified.

Privilege Escalation via Insider Access Patterns

A second consistent finding is that privilege escalation from a standard user account to a highly privileged one is achievable in the majority of TLPT exercises. The escalation paths most commonly exploited include misconfigured cloud IAM policies that grant excessive permissions to service roles, unpatched local privilege escalation vulnerabilities on endpoint devices, and access to internal documentation or configuration repositories that contain credentials or keys for privileged systems.

The insider threat dimension of privilege escalation findings is significant for crypto firms. In several high-profile financial entity TLPT exercises, red teams have demonstrated that a compromised employee account with apparently limited access could be escalated to full control of critical infrastructure within hours. The asymmetry between the access granted to a legitimate employee and the access achievable by an adversary who has compromised that employee's account is consistently underestimated by firms before they undergo TLPT.

Weak Key Management Controls

For crypto firms specifically, key management controls are among the most frequently identified gaps in TLPT exercises. Common findings include private keys or key material stored in configuration files, code repositories, or internal documentation systems accessible to a broader population than intended; multi-signature approval processes that can be bypassed by compromising a single system or person; and hardware wallet or HSM access that relies on single-factor authentication for the device PIN or passphrase.

Key management findings in TLPT exercises at crypto firms typically reveal that the formal key management policy and the operational reality of key management practice have diverged significantly. Policy documents may specify stringent requirements for key ceremony procedures, multi-party authorisation, and hardware storage, but the operational team may have introduced informal workarounds for efficiency reasons that undermine those controls entirely.

Detection and Response Timing

Across most financial entity TLPT exercises, the time between red team initial access and Blue Team detection is measured in days rather than hours. In exercises where initial access is achieved via social engineering, detection times of five to fifteen days are common. In exercises where initial access is achieved via exploitation of a technical vulnerability, detection times are shorter but still frequently exceed forty-eight hours.

For crypto firms, detection timing matters in an extreme way because of the irreversibility of on-chain asset transfer. An adversary who achieves access to key management infrastructure and is undetected for five days can cause losses that cannot be recovered. The detection and response timing findings from TLPT should be a direct input to investment priorities in security monitoring and SOC capability.

Third-Party Integration Weaknesses

A recurring finding across financial entity TLPT exercises is that third-party integrations provide attack paths that bypass the primary perimeter controls. This is particularly relevant for crypto firms that rely on oracle networks, custody technology providers, KYC and AML platforms, and exchange connectivity APIs. In several exercises, red teams have achieved access to production systems via compromised third-party integration credentials or by exploiting weaknesses in the trust relationships between the firm and its critical service providers.

How TLPT Feeds Back into Security Governance

The value of TLPT is only fully realised if the findings are systematically fed back into the security programme and used to drive measurable improvements. A TLPT report that is filed without driving change is a compliance exercise; a TLPT exercise that generates a prioritised security improvement programme is a genuine investment in resilience.

Board and Executive Reporting

TLPT findings should be reported to the board or relevant board committee, not merely to the security operations team. DORA's ICT governance requirements explicitly require senior management oversight of ICT resilience testing results. For crypto firms, board-level engagement with TLPT findings is also a commercial signal: institutional investors and regulators are increasingly asking whether boards are actively engaged with security testing outcomes rather than treating them as purely operational matters.

The board report does not need to cover every technical finding in detail. It should cover the key themes identified, the highest-priority remediation items, the timeline for remediation, and the resource implications. The board should formally acknowledge and approve the remediation plan.

Remediation Prioritisation

TLPT exercises typically produce a large number of findings across a spectrum of severity. Effective remediation prioritisation requires distinguishing between findings that represent fundamental control failures, findings that represent mature attacker techniques for which perfect defence is not realistic, and findings that represent monitoring and detection gaps rather than prevention gaps.

For crypto firms, findings related to key management controls, social engineering susceptibility among personnel with access to privileged systems, and detection timing for initial access scenarios should be treated as the highest priority. These are the finding categories that most directly correspond to the scenarios that have caused the largest crypto losses in practice.

Security Programme Integration

TLPT findings should feed directly into the following security programme elements:

• Detection rule development: Techniques used by the red team that were not detected should generate new detection rules, tuning of existing rules, or deployment of additional monitoring capabilities.
• Security awareness training: Social engineering success rates and specific pretexts used by red teamers provide precise inputs for updating security awareness training content and running targeted phishing simulation exercises.
• Policy and procedure updates: Where the gap between documented policy and operational practice is identified, policies should be updated to reflect achievable controls, and operational procedures should be updated to close the gap.
• Penetration testing schedule: The findings from TLPT should inform the scope and focus areas for the firm's ongoing annual penetration testing programme, ensuring that the highest-priority areas continue to receive testing attention between TLPT cycles.
• Third-party risk programme: Findings related to third-party integration weaknesses should feed into the vendor risk management programme, triggering updated security assessments or contract requirements for the relevant providers.

Regulatory Submission and Follow-Up

For entities conducting TLPT under DORA designation, the regulatory submission of the TLPT report initiates a supervisory dialogue. NCAs may follow up on specific findings, request clarification on the remediation plan, or use the findings to inform their supervisory assessment of the firm's ICT risk posture. Firms should treat the regulatory submission not as the end of the process but as the beginning of a supervisory engagement that will continue until the remediation programme is complete.

The DORA requirement for TLPT every three years means that firms should treat each exercise as a waypoint in a continuous security improvement cycle rather than a one-off compliance obligation. The gap between exercises should be used to implement the findings from the previous exercise, mature the security programme, and prepare the organisation to achieve meaningfully better outcomes in the next exercise.

Frequently Asked Questions

What is threat-led penetration testing (TLPT) under DORA?

Threat-led penetration testing (TLPT) under DORA is a mandatory red team exercise for significant financial entities. Unlike standard penetration testing, TLPT begins with a structured threat intelligence phase that identifies the specific threat actors and attack scenarios relevant to the firm. Red team testers then simulate those scenarios against live production systems using the same tactics, techniques, and procedures as real adversaries. The TIBER-EU framework published by the European Central Bank is the reference framework for TLPT execution across EU member states.

Which crypto firms are in scope for DORA TLPT?

DORA TLPT applies to financial entities designated as significant by the relevant national competent authority. Crypto-asset service providers (CASPs) authorised under MiCA are subject to DORA and may be designated as significant based on factors including systemic importance, scale of operations, and interconnectedness. National competent authorities designate which entities must undertake TLPT; the designation is not automatic. However, CASPs that operate at scale or hold significant assets under management should treat TLPT scoping as a live compliance risk requiring active management.

How does TLPT differ from a standard penetration test?

Standard penetration testing uses a defined scope and methodology to identify known vulnerability classes in systems and applications. TLPT is scenario-based and intelligence-led. It begins with a threat intelligence phase that produces a targeted threat intelligence report identifying which specific threat actor groups are most likely to attack the firm and which attack paths they would use. The red team then executes those specific scenarios against live production systems. TLPT typically targets the full kill chain from initial access through to impact, rather than cataloguing individual vulnerabilities. TLPT exercises are also significantly longer than standard penetration tests, often running for several months.

What prerequisites must a crypto firm have before undertaking TLPT?

Before undertaking TLPT, a crypto firm must have an up-to-date asset register covering all systems in scope, a documented and tested incident response plan, formal access control documentation including privileged access policies, a security operations capability capable of running the defensive side of the exercise, and a clear chain of command for authorising and managing the exercise. Firms that attempt TLPT without these prerequisites in place will find that the exercise surfaces fundamental operational gaps rather than providing the targeted testing value that TLPT is designed to deliver.

How do TLPT findings feed back into a security programme?

TLPT findings feed into the security programme through a structured remediation plan that addresses identified gaps in detection, response, and control effectiveness. The purple team phase, which brings red and blue teams together to review findings jointly, is particularly valuable because it allows defenders to understand exactly which techniques were used and why existing controls failed to detect or prevent them. TLPT findings should be reviewed at board or executive level and should drive updates to security policies, control configurations, detection rules, and the security testing programme for subsequent years.