DORA Sector Guide

DORA for Crypto-Asset Service Providers (CASPs)

DORA operational resilience for MiCA-authorised crypto firms, built for 24/7 markets, custody and on-chain dependencies.

Supervised by National Competent Authorities (NCAs) authorise and supervise CASPs under MiCA, with ESMA and EBA coordinating, maintaining the CASP register and (with the ECB) overseeing significant ART/EMT issuers.

Crypto-asset service providers authorised under MiCA are explicitly listed as financial entities under DORA (Regulation (EU) 2022/2554, Article 2(1)(s)), so the same digital operational resilience rules that apply to banks and investment firms also apply to exchanges, custodians, brokers and crypto advisers. DORA has applied since 17 January 2025, and MiCA authorisation now goes hand in hand with demonstrable ICT risk management, incident reporting, resilience testing and third-party oversight.

For CASPs this is not a paperwork exercise. Trading venues match orders around the clock, custodians hold private keys that cannot be reissued if compromised, and most firms depend on cloud platforms, blockchain nodes, oracles and market-data feeds they do not control. DORA forces these operational realities into a governed framework: a board-owned ICT risk strategy, a tested incident response capability, threat-led testing for the most critical firms, and contractual control over the third parties that keep the platform online.

Is your firm in scope?

All CASPs authorised under MiCA Title V are DORA financial entities under Article 2(1)(s), covering custody and administration of crypto-assets, operation of a trading platform, exchange, execution, placement, reception/transmission of orders, advice and portfolio management. DORA applies proportionately under Article 4, so a small portfolio-management CASP carries lighter expectations than a large multi-asset exchange, but no CASP is exempt from the core ICT risk, incident-reporting and third-party rules. Issuers of asset-referenced tokens (ART) and e-money tokens (EMT) are separately in scope as financial entities and face MiCA-specific operational and reserve requirements alongside DORA.

How DORA fits your existing regime

MiCA already imposes operational-resilience duties on CASPs (Article 68 on systems and security access protocols, custody safekeeping under Article 75, and business-continuity obligations), and DORA acts as the cross-sectoral lex specialis that deepens and standardises the ICT dimension of those duties. Rather than running two parallel programmes, firms should map MiCA's security, custody-segregation and continuity clauses onto DORA's five pillars so a single control set satisfies both: DORA's ICT risk framework operationalises MiCA Article 68, and DORA incident reporting feeds the same evidence base NCAs expect under MiCA. The practical challenge unique to crypto is applying these requirements to 24/7 markets and to private-key custody, where downtime and key compromise have no banking-hours grace period and no chargeback to fall back on.

What DORA means for Crypto-Asset Service Providers (CASPs)

Wallet key management and HSMs

Private keys are the irreplaceable crown jewels of a CASP: lose or leak them and the assets are gone irreversibly. DORA's ICT risk framework (Articles 6-8) requires documented key-lifecycle controls, hardware security modules or MPC, dual control and segregation of duties over signing, mapped to MiCA's safekeeping duties under Article 75.

Hot/cold custody architecture

Most exchanges keep the bulk of assets in cold storage and a working float in hot wallets. DORA asks firms to identify these as critical ICT assets, assess the concentration and single-points-of-failure in the signing and withdrawal path, and document protection and recovery measures so a hot-wallet breach cannot cascade into total loss.

Matching-engine and platform resilience

A trading platform's matching engine and order-management stack are critical functions whose failure stops the market. DORA requires capacity, redundancy and tested failover for these systems, plus monitoring that can detect latency spikes, degraded order routing or partial outages before they become a market-integrity event.

Blockchain node and oracle dependencies

CASPs rely on full nodes, RPC providers, indexers and price oracles to confirm deposits, broadcast withdrawals and value assets. DORA's third-party rules (Articles 28-30) require these to be inventoried, risk-assessed and contractually governed even when a provider is a decentralised or non-traditional vendor, with fallback nodes to avoid a single chain dependency.

Cloud concentration and exit strategy

Heavy reliance on one or two hyperscalers for compute, storage and KMS creates concentration risk that DORA (Articles 28-29) treats as a board-level concern. CASPs must hold an information register of ICT contracts, assess substitutability, secure audit and access rights, and document a tested exit and portability plan for critical cloud services.

24/7 incident detection and response

Crypto markets never close, so DORA's incident management (Articles 17-19) must be staffed and tooled for round-the-clock detection, escalation and reporting. CASPs need on-call rotations, automated alerting on abnormal withdrawals or chain reorganisations, and runbooks that distinguish a hack from market volatility within minutes, not hours.

Incident reporting

For CASPs the most consequential ICT incidents are wallet compromises, exchange hacks, smart-contract or bridge exploits, and chain-level events such as reorganisations or a major node-provider outage; market-manipulation enabled by an ICT failure (for example a frozen order book or manipulated price feed) can also qualify. DORA (Article 19 and the related RTS/ITS) requires major incidents to be classified against thresholds such as clients and amounts affected, duration, geographic spread, data losses, criticality of services and economic impact, then reported to the NCA on a strict clock: an initial notification, an intermediate report, and a final root-cause report. Because crypto operates 24/7 and exploits drain funds in minutes, the reporting and containment clock starts the moment the incident is detected regardless of weekend or holiday, so on-call coverage and pre-drafted templates are essential to meeting the early notification window.

The Crypto-Asset Service Providers (CASPs) compliance pack

Everything tailored to your sector, ready to use on day one.

  • 30-point sector compliance checklist (Excel) across the 5 DORA pillars
  • Sector policy & contract adaptations
  • Scoping & proportionality notes + action plan
  • Sector implementation guide (PDF) with the questions and the regime mapping
€129 excl. VAT
one-off · instant download · lifetime updates
  Get the pack — €129

Frequently asked questions

We are MiCA-authorised. Does DORA actually apply to us?

Yes. CASPs authorised under MiCA are named as financial entities in DORA Article 2(1)(s), so all of DORA applies. MiCA gives you market authorisation; DORA governs the operational resilience and ICT risk side of running the business, and your NCA will expect evidence of both.

How do DORA and MiCA operational requirements fit together without duplicating work?

Treat DORA as the detailed ICT framework that operationalises MiCA's high-level security, custody and continuity obligations (notably MiCA Articles 68 and 75). Map a single control set to DORA's five pillars and reuse it as evidence for both regimes rather than building two separate programmes.

Are we subject to Threat-Led Penetration Testing (TLPT)?

Only a subset of firms is. TLPT under DORA Articles 26-27 applies to entities designated by their authority based on systemic importance and ICT risk profile, on roughly a three-year cycle. Many smaller CASPs will not be designated, but every CASP must still run a proportionate testing programme including vulnerability scans, penetration tests and scenario-based resilience tests.

Do blockchain nodes, RPC providers and oracles count as ICT third-party providers?

Yes, where you depend on them to deliver your service they fall within DORA's third-party rules (Articles 28-30). They must appear in your register of information, be risk-assessed for concentration and substitutability, and ideally be backed by fallback providers, even though decentralised or non-traditional vendors make traditional contracting harder.

What is the reporting deadline if our hot wallet is drained on a weekend?

DORA's clock is not paused for weekends or holidays. Once you detect a major incident you must submit the initial notification within the early window set by the RTS/ITS, followed by intermediate and final reports. For 24/7 crypto operations this means on-call staffing and pre-approved templates so you can notify your NCA promptly regardless of when the breach occurs.

Does using a qualified sub-custodian transfer our DORA obligations?

No. Outsourcing custody or signing to a sub-custodian or wallet provider does not transfer accountability. Under DORA the CASP remains responsible for managing that third-party ICT risk: due diligence, contractual audit and access rights, monitoring, and a documented exit plan, all recorded in your information register.

Start free: check your DORA scope, run a gap analysis, or estimate implementation cost. Need the full risk view? See the Risk Assessment Toolkits or compare all kits. All prices exclude VAT; an EU VAT invoice is issued at checkout. Professional templates, not legal advice.

How Compliant Is Your Institution?

Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.

Get Your Free DORA Score Join Free Monthly Webinar