DORA Compliance for Crypto Firms: 2026 Guide for CASPs
DORA compliance for crypto firms in 2026: CASP scope, the ICT register, 4h/72h/1-month incident deadlines, CTPP oversight, 2025 incident data and a checklist.
Last updated: 4 October 2026
Most crypto firms in Europe spent 2024 and 2025 focused on MiCA. Meanwhile a second regulation was quietly imposing a different kind of obligation, one that has nothing to do with crypto specifically and everything to do with whether your systems stay up.
DORA, the Digital Operational Resilience Act, is the EU's framework for ICT risk in the financial sector. It applies to crypto-asset service providers alongside banks, insurers and payment institutions, and it treats an outage or a compromised supplier as a supervisory matter rather than an engineering inconvenience.
DORA compliance for a crypto firm means five things. You need an ICT risk framework owned by the board, a register of every ICT provider, classification and reporting of major incidents (initial notice within four hours of classifying an incident as major), a resilience testing programme, and contracts and exit plans for critical suppliers. It has applied to MiCA-authorised CASPs since 17 January 2025. With MiCA's transitional period now over, every CASP operating in the EU is either authorised and in scope, or not allowed to operate.
This guide covers who is in scope, the five pillars, what the third-party register actually requires, the incident reporting deadlines, what the first year of reporting showed, where crypto firms differ from banks, and how DORA sits alongside MiCA. Educational only, not legal advice.
What is DORA?
DORA is Regulation (EU) 2022/2554. It entered into application on 17 January 2025 and creates a single, harmonised set of requirements for managing information and communication technology risk across EU financial entities.
Its premise is straightforward. Financial regulation has traditionally concentrated on financial risk: capital, liquidity, conduct. But a firm with a pristine balance sheet is still unable to serve customers if its systems are down or its critical cloud provider fails. DORA makes operational resilience a regulated obligation with named accountability rather than an internal engineering standard.
The scope is deliberately broad. It covers roughly twenty categories of financial entity, and it explicitly includes crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens. If you hold or are seeking a CASP authorisation, DORA applies to you. The ESAs' incident statistics now report on a separate "crypto" sector alongside credit, payments, insurance and the others (ESAs 2025 report on major ICT-related incidents, 3 June 2026).
DORA also scales with size. The regulation applies proportionately, so a small CASP is not expected to run the same programme as a large exchange. But no in-scope firm is exempt from the core pillars.
The five pillars
| Pillar | What it requires |
|---|---|
| ICT risk management | A documented framework covering identification, protection, detection, response and recovery, owned by the management body |
| Incident reporting | Classify ICT incidents and report major ones to your competent authority on a defined timetable |
| Resilience testing | Regular testing, with threat-led penetration testing for significant entities |
| Third-party risk | Register of all ICT providers, mandatory contract terms, exit strategies |
| Information sharing | Voluntary exchange of cyber threat intelligence between firms |
The part firms underestimate
DORA places ultimate responsibility for ICT risk on the management body, and members are expected to maintain sufficient knowledge to discharge it. This is not a control you can fully delegate to a CTO or an outsourced provider. Boards are required to approve the strategy, understand the risks, and be able to demonstrate that they did.
In practice that means ICT risk needs a standing agenda slot, documented board training, and minutes that show genuine engagement rather than a rubber stamp.
The third-party register
If DORA has one requirement that consumes more time than firms expect, it is the register of information on contractual arrangements with ICT third-party providers. Its format is fixed by the implementing technical standards on register templates, Commission Implementing Regulation (EU) 2024/2956.
You must maintain a structured record of every ICT service you rely on, identifying which support critical or important functions. That last classification drives most of the downstream obligations, and it is where judgement is required. Your cloud host is obviously in scope. Your blockchain node provider, your KYC vendor, your market data feed, your custody technology, your alerting tool: each needs assessing rather than assuming.
Contracts with providers supporting critical functions must include specific terms: service level descriptions, data location, access and audit rights for you and your regulator, incident notification obligations, termination rights, and exit arrangements.
That last one is the hard part. DORA expects a documented, tested exit strategy: how you would move off a provider without interrupting service. Many firms discover during this exercise that they could not realistically leave their primary cloud or custody provider at all, which is precisely the concentration risk the regulation is designed to surface.
Why the register matters beyond your own firm
The registers are also how EU supervisors find systemic dependencies. Under the ESAs' roadmap of 18 February 2025, competent authorities had to pass the registers they received from financial entities to the ESAs by 30 April 2025. The ESAs then used them to assess which providers are critical, notified those providers by July 2025, and gave them a six-week window to object before final designation. Designated critical ICT third-party providers (CTPPs) now sit under direct EU oversight, with one of the ESAs acting as Lead Overseer.
Two practical consequences for a CASP. First, a poor-quality register is visible upstream, not just to your own supervisor. Second, CTPP oversight does not move any of your obligations onto the provider. You still need your own contract terms, risk assessment and exit plan for a designated cloud provider.
Incident classification and reporting
DORA requires classifying ICT-related incidents against criteria including clients affected, duration, geographic spread, data losses, criticality of services affected, and economic impact. The materiality thresholds are set in Commission Delegated Regulation (EU) 2024/1772. Incidents crossing the thresholds are major and must be reported to your competent authority.
Reporting runs in three stages, with deadlines set by Commission Delegated Regulation (EU) 2025/301 (as summarised in the ESAs' June 2026 report):
| Report | Deadline | What it contains |
|---|---|---|
| Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it | Limited available information |
| Intermediate report | Within 72 hours of the initial notification | More detailed information as the picture develops |
| Final report | No later than one month after the latest intermediate report | Root cause analysis and all relevant information |
The operational implication is that classification cannot be improvised during an incident. You need the criteria mapped in advance, a named person able to make the call at 2am, and a template ready. The templates themselves are set by Commission Implementing Regulation (EU) 2025/302. Firms that treat reporting as a post-incident exercise routinely miss the first deadline. For a crypto business the clock is especially unforgiving, because markets trade around the clock and an exploit can drain funds in minutes.
What the first year of reporting showed
The ESAs' first annual report on major incidents (published 3 June 2026) gives a useful baseline:
- Financial entities reported 3,383 major incidents in 2025, an average of 282 a month.
- Almost one third (29%) originated from a failure at an ICT third-party provider, including providers not designated as critical. The ESAs flag this as an area of supervisory attention.
- Human error caused 12% of major incidents.
- In the crypto sector, only one third of the incidents that affected clients hit more than 1,000 of them.
- For 2026, the ESAs say they will focus on "open" incidents and help competent authorities identify overdue cases.
The third-party figure is the one to take to your board. It is the strongest evidence yet that the register and exit-strategy work is not paperwork.
Resilience testing
All in-scope entities must run a testing programme covering vulnerability assessments, scenario-based testing, and business continuity exercises, at least annually for critical systems.
Entities designated as significant face an additional requirement: threat-led penetration testing, modelled on the TIBER-EU framework, conducted at least every three years using realistic adversary tactics against live production systems. This is materially more demanding than a standard penetration test and requires accredited testers.
Where DORA bites differently for crypto firms
DORA was written for the whole financial sector, but a CASP's ICT estate looks different from a bank's. Four areas deserve specific attention:
- Key management. Private keys are the crown jewels. Your ICT risk framework should document the key lifecycle: generation, storage in hardware security modules or multisig and MPC setups, signing approvals, rotation and recovery. The hot and cold wallet split belongs in it too.
- Blockchain infrastructure as third parties. Node and RPC providers, custody technology vendors, price oracles and market data feeds are ICT services. Each belongs in the register, classified by whether it supports a critical function.
- Incident criteria for on-chain events. A smart-contract exploit, a halted chain, a stuck bridge or a wallet compromise needs mapping to DORA's classification criteria in advance. Those scenarios rarely appear in templates written for banks.
- Testing against crypto-specific scenarios. Scenario tests should cover a hot-wallet compromise, the loss of a primary node provider and a chain halt, not only a data-centre outage.
How DORA and MiCA interact
They are complementary and independent. Meeting one does not satisfy the other.
- MiCA governs authorisation, conduct, client asset safeguarding, disclosure and market abuse. It answers: are you permitted to offer this service, and are you treating clients properly?
- DORA governs the technology underneath. It answers: will your systems keep working, and can you recover when they do not?
A CASP applying for authorisation will find that competent authorities examine ICT resilience as part of the application. In practice the two are assessed together even though they are separate instruments. Our guide to verifying MiCA authorisation covers the licensing side, and top blockchains for Europe under MiCA covers the ecosystem context. For a side-by-side view of where the two regulations overlap, clause by clause, see our guide to how MiCA and DORA overlap.
The timing has also changed. MiCA's transitional period ended on 1 July 2026, so firms that relied on grandfathering now need a CASP authorisation to keep serving EU clients, and DORA comes with it. Our guide to the CASP licence under MiCA covers the authorisation itself. CASP licence cost covers the budget, including the DORA work, and CASP licence jurisdictions compared covers where to apply.
DORA is also part of why the mid-tier exchange model has come under pressure. Compliance cost here is largely fixed: the register, the testing programme, the board governance and the exit strategies cost roughly the same whether you serve fifty thousand users or five million. That arithmetic contributed to the 2026 wave of exchange wind-downs.
Where to start
- Confirm scope. Are you an in-scope financial entity, and are any of your group companies?
- Build the register. Inventory every ICT provider and classify which support critical or important functions. Include node, RPC, custody-technology and oracle providers. This takes longer than anticipated and everything else depends on it.
- Gap-check contracts. Review agreements with critical providers against DORA's mandatory terms. Renegotiation takes months.
- Write and test exit strategies for critical providers. Untested plans do not count.
- Set incident classification criteria and rehearse the reporting timeline before you need it: 4 hours, 72 hours, one month. Include on-chain scenarios.
- Give the board its role. Documented training, standing agenda item, approved strategy.
- Plan the testing programme. Annual testing of critical systems, and TLPT readiness if you could be designated significant.
DORA compliance checklist for crypto firms
- ICT risk management framework approved by the management body and reviewed regularly
- Documented key-management controls and segregation of duties
- Register of information complete, in the prescribed template, with critical or important functions identified
- Mandatory contract terms in place with every provider supporting a critical function
- Tested exit strategy for each critical provider
- Incident classification criteria mapped, named decision-maker on call around the clock, report templates ready
- Annual testing programme, with results tracked to remediation
- Board training records and minutes that show ICT risk discussed
- A process to follow ESAs updates, such as the July 2026 statement on ICT risks from frontier AI models
Does DORA apply to DeFi?
DORA applies to defined categories of financial entity, principally those authorised under EU financial services legislation. A genuinely decentralised, non-custodial protocol with no authorised entity behind it does not fit those categories.
JewelSwap is non-custodial across MultiversX, Sui and Radix, with users interacting directly with smart contracts from their own wallets. It is not a CASP and does not hold client assets, so the DORA obligations described here do not attach to the protocol. As with MiCA, that reflects the architecture rather than an exemption anyone granted: a business that operates a front end commercially, holds client assets, or seeks CASP authorisation will find DORA applies alongside it.
Frequently asked questions
What is DORA compliance?
Meeting the requirements of the EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554, which sets harmonised rules for managing ICT risk across financial entities. It covers ICT risk management, incident reporting, resilience testing, third-party risk and information sharing.
When did DORA come into force?
DORA entered into application on 17 January 2025, following a two-year implementation period after its adoption in 2022.
Does DORA apply to crypto companies?
Yes. Crypto-asset service providers authorised under MiCA and issuers of asset-referenced tokens are explicitly within scope, alongside banks, insurers, payment institutions and around twenty other categories of financial entity.
What is the DORA register of information?
A structured record of all contractual arrangements with ICT third-party service providers, identifying which support critical or important functions. That classification determines which contractual terms, oversight and exit-strategy requirements apply. Supervisors also pass the registers to the ESAs, which use them to designate critical ICT third-party providers.
How quickly must a major ICT incident be reported under DORA?
The initial notification is due within 4 hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report with root cause no later than one month after the latest intermediate report.
What is a critical ICT third-party provider (CTPP)?
An ICT provider, such as a large cloud provider, that the ESAs have designated as critical to the EU financial sector, based largely on the registers of information firms submit. CTPPs are overseen directly by a Lead Overseer, but firms that use them keep all their own DORA obligations, including contract terms and exit plans.
Is DORA the same as MiCA?
No. MiCA governs authorisation, conduct and client asset protection for crypto services. DORA governs the operational resilience of the technology underneath. They apply independently, and complying with one does not satisfy the other.
Keep reading
