An EU crypto-asset service provider (CASP) is governed by two interlocking regimes. MiCA is the authorisation regime that lets a firm provide crypto-asset services and sets the high-level obligation to keep those services continuous. DORA is the operational resilience regime that specifies, in detail, how the ICT risk management, incident reporting, resilience testing, and recovery behind that obligation must be built. A CASP is subject to both, and demonstrating MiCA's continuity obligation is largely a matter of meeting DORA. This page covers what the two require for response and recovery. For how MiCA and DORA sit alongside the other frameworks, see the regulatory requirements overview.

What are MiCA and DORA, and how do they fit together?

MiCA (the Markets in Crypto-Assets Regulation, Regulation (EU) 2023/1114) is the EU's harmonised authorisation and conduct framework for crypto-assets and the firms that service them. To provide services such as custody and administration of crypto-assets, operation of a trading platform, exchange, execution, placement, reception and transmission of orders, advice, or portfolio management, a firm must be authorised as a CASP under MiCA Title V.

DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554) harmonises digital operational resilience requirements across the EU financial sector. Because DORA Article 2(1)(s) brings CASPs authorised under MiCA within its definition of financial entities, every authorised CASP is directly subject to DORA. Both are regulations, so they apply directly across member states without transposition into national law.

The division of labour is the thing to hold onto: MiCA sets the obligation to ensure continuity of crypto-asset services and to hold a business continuity policy; DORA supplies the detailed ICT risk management, incident reporting, testing, and recovery requirements that satisfy it. MiCA Article 68(7) makes the link explicit, requiring resilient and secure ICT systems as required by DORA and business continuity and recovery plans set up pursuant to DORA.

When did MiCA and DORA start applying to CASPs?

MiCA's provisions for CASPs began applying on 30 December 2024. A transitional regime under MiCA Article 143(3) allows firms that were operating lawfully under national law before that date to continue for a limited period, up to 1 July 2026, though member states could shorten or disapply it, so the exact end date varies by jurisdiction.

DORA has applied since 17 January 2025 (it entered into force on 16 January 2023). From that date, CASPs in scope have been expected to meet DORA's requirements in full. In practice this means an authorised CASP faces both regimes concurrently as of 2025.

What operational resilience does MiCA require?

MiCA's central operational obligation for CASPs sits in Article 68(7). It requires a CASP to take all reasonable steps to ensure continuity and regularity in the performance of its services by using appropriate and proportionate resources and systems, including resilient and secure ICT systems as required by DORA. In the same paragraph, the CASP must maintain a business continuity policy that includes ICT business continuity plans and ICT response and recovery plans, set up pursuant to Articles 11 and 12 of DORA, so that in the event of an interruption essential data and functions are preserved and services are maintained or, where that is not possible, recovered in a timely manner.

The practical reading for a digital asset operator is that the essential function to be recovered is control of client and firm assets. A continuity plan that restores systems but leaves assets stranded or attacker-controlled does not satisfy the spirit of Article 68(7).

What are DORA's requirements for CASPs?

DORA sets four operational obligations for financial entities, all of which apply to an in-scope CASP. This page focuses on the resilience, response, and recovery elements.

ICT risk management framework

DORA requires an internal governance and control framework for identifying, protecting against, detecting, responding to, and recovering from ICT risk. The management body (board) is responsible for defining, approving, and overseeing the framework (Article 5(2)), and the framework must be documented and reviewed at least once a year (Article 6(5)). In practice this means a documented ICT risk strategy, named owners, and a mapped inventory of the ICT assets and processes that support critical or important functions. For a CASP, the assets under management and the signing and settlement infrastructure are among the most critical functions, so the framework must account for their protection, the detection of compromise, and their recovery.

Incident reporting

DORA requires financial entities to classify ICT-related incidents and report major ones to the competent authority in three stages. The timelines are strict, and the initial clock starts at classification, which is why fast triage matters.

• Initial notification: as early as possible, within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it.
• Intermediate report: within 72 hours of the initial notification.
• Final report: within one month.

These timelines are set out in DORA Article 19 and the associated regulatory technical standards (Commission Delegated Regulation (EU) 2025/301). The 4-hour figure is not 4 hours from detection; it runs from the point of classifying the incident as major.

Digital operational resilience testing

DORA requires a resilience testing programme. Financial entities identified by their competent authority as significant must carry out threat-led penetration testing (TLPT) at least every three years, with the frequency adjustable by the authority. Not every CASP is in scope for TLPT; the competent authority identifies which entities are, based on impact and risk criteria. All in-scope entities, however, must test their ICT tools and systems on a regular basis.

ICT third-party risk

DORA requires firms to manage ICT third-party risk: maintain a register of ICT third-party contracts, assess substitutability and concentration risk, and document a tested exit and portability plan for critical providers. For a CASP that relies on external custody, signing, or cloud infrastructure, this is where vendor concentration becomes a named regulatory concern rather than an informal one.

What must a CASP do in practice?

• Assign board-level ownership of the ICT risk management framework and review it at least annually.
• Map critical and important functions, including asset custody, signing, and settlement, and set recovery objectives for each.
• Build an incident classification and reporting workflow that can meet the 4-hour, 72-hour, and one-month clocks.
• Maintain and test ICT business continuity, response, and recovery plans, not just backups, so that essential data and functions are preserved and services recovered in a timely manner.
• Hold an information register of ICT third-party contracts, assess substitutability and concentration risk, and document a tested exit plan for critical providers.
• Treat the MiCA Article 68(7) continuity obligation as satisfied largely through the DORA programme, and be able to evidence both.

How does keyless recovery, set up in advance, map to MiCA and DORA?

Both regimes require that critical functions can be restored after a compromise, not merely that systems are backed up. For a digital asset operator the critical function is control of the assets. Keyless recovery, meaning recovery that does not depend on your private keys, set up in advance, addresses the exact failure these regimes care about: an incident where keys are lost, a signer is unavailable, or an attacker controls the wallet, and conventional restore-the-key recovery is impossible.

Circuit Security provides operational resilience for institutional digital assets. Its Recovery and Response products, powered by Automatic Asset Extraction (AAE), give a recovery path that does not depend on the private keys, so they support the Respond and Recover obligations that prevention-only controls leave open. See operational resilience for digital assets and /recovery.

Frequently asked questions

What is the difference between DORA and MiCA for a CASP?
MiCA is the EU authorisation regime that lets a firm provide crypto-asset services and sets the high-level obligation to ensure continuity of those services. DORA is the detailed operational resilience regime that specifies how the ICT risk management, incident reporting, testing, and recovery elements of that obligation must be implemented. A CASP is subject to both, and meets much of its MiCA Article 68(7) continuity obligation by complying with DORA.

Does DORA apply to crypto firms?
Yes. CASPs authorised under MiCA are financial entities under DORA (Article 2(1)(s)), so operators providing regulated crypto-asset services in the EU are in scope and have been since DORA began applying on 17 January 2025.

What is the DORA incident reporting deadline?
Major ICT incidents require an initial notification within 4 hours of classifying the incident as major (and no later than 24 hours after becoming aware of it), an intermediate report within 72 hours, and a final report within one month.

When did MiCA and DORA start applying to CASPs?
MiCA's CASP provisions began applying on 30 December 2024, subject to transitional arrangements that vary by member state and can run to 1 July 2026. DORA has applied since 17 January 2025.

Does MiCA or DORA require more than backups for recovery?
Yes. DORA requires tested ICT business continuity, response, and recovery plans that can restore critical functions and preserve essential data, and MiCA Article 68(7) requires timely recovery of services. A backup that has never been exercised against a realistic failure does not by itself demonstrate the required recovery capability.

‍