The Markets in Crypto Assets Regulation (MiCA) and the Digital Operational Resilience Act (DORA) are now very much in effect for anyone providing cryptoasset services across Europe.

The crypto industry wanted this legitimacy, a clear path toward becoming a recognised part of Europe’s financial infrastructure. But that legitimacy comes with significant expectations.

The key shift across both frameworks: operational resilience is no longer optional. Crypto Asset Service Providers (CASPs) face heightened expectations for operational resilience, business continuity, and, critically, the safeguarding and continuous availability of client assets. What was once considered “best practice” is now explicitly required: firms must detect, respond to, and recover from ICT incidents, including outages or failures at custodians and wallet providers.

What follows is a practical interpretation of MiCA and DORA’s resilience requirements, what regulators will expect, where CASPs are most exposed, and how firms can build evidence-based recoverability into their operations.

‍

1. What MiCA Requires: Continuity, Security, and Recoverability

MiCA sets the baseline operational requirements for CASPs in the EU. While broad, its ICT and business-continuity provisions are explicit and foundational.

MiCA Article 68(7): Business Continuity & ICT Recovery

CASPs must:

“take all reasonable steps to ensure continuity… including resilient and secure ICT systems,” and establish “ICT response and recovery plans… to ensure the timely recovery… and timely resumption of crypto-asset services.”

This means CASPs must be able to maintain business continuity and execute systems recovery even if custodians, wallet providers, or internal systems fail. For a CASP, restoring operational access to assets is not merely a technical requirement, it is core to performing the regulated service itself. If asset access is unavailable, the CASP is functionally unable to operate.

Most CASPs today rely entirely on a single custody or wallet provider, meaning they cannot recover access during an outage without that provider’s cooperation. This creates a regulatory and business vulnerability that MiCA makes difficult to justify.

Required controls:

• Business continuity plans
• Tested recovery and restoration procedures
• Custody-outage and failover plans
• Response capabilities for ICT disruptions
• Evidence of scenario testing, including provider unavailability

MiCA Article 70: Safeguarding Client Assets

CASPs holding client assets must:

“make adequate arrangements to safeguard the ownership rights of clients… especially in the event of the CASP’s insolvency.”

With crypto being bearer assets, safeguarding has an operational dimension: if the CASP cannot restore access to the asset, it cannot safeguard it. Operational recoverability is therefore an inherent part of demonstrating safeguarding under MiCA.

Required controls:

• Segregation of client assets
• Protection against unauthorised transactions
• Preservation of client ownership rights
• Operational recoverability of access
• Contingency plans for loss of access to primary custody systems

‍

2. What DORA Requires: Operational Resilience and ICT Substitutability

DORA applies directly to CASPs,  classified as financial entities, and indirectly to the service providers that support them. This means wallet vendors and other peripheral tools will be contractually required to meet DORA-level resilience expectations, even if they are not formally classified as CASPs.

DORA Article 11: Response and Recovery

CASPs must maintain a dedicated ICT business-continuity policy and disaster-recovery plan, implemented through concrete operational measures. Article 11(2) sets the most consequential requirements:

“Financial entities shall implement the ICT business continuity policy through dedicated, appropriate and documented arrangements, plans, procedures and mechanisms aiming to:

(a) ensure the continuity of the financial entity’s critical or important functions;

(b) quickly, appropriately and effectively respond to, and resolve, all ICT-related incidents in a way that limits damage and prioritises the resumption of activities and recovery actions;

(c) activate, without delay, dedicated plans that enable containment measures, processes and technologies suited to each type of ICT-related incident and prevent further damage, as well as tailored response and recovery procedures established in accordance with Article 12;

(d) estimate preliminary impacts, damages and losses.”

While DORA does not label crypto asset infrastructure as critical ICT by default, regulators will reasonably treat a CASP’s custody stack, wallet infrastructure, and transaction-processing flows as critical or important functions, because their failure directly interrupts the regulated service.

This means CASPs must be able to:

• Maintain continuity of custody and asset-availability operations
• Restore access to client assets rapidly following disruptions
• Activate recovery plans designed for the asset-service they provide
• Assess business impact and report appropriately

DORA expects demonstrable, confident recoverability of digital asset access. CASPs must have practical, testable mechanisms to fail over or recover access swiftly if any core technology provider becomes unavailable.

DORA’s incident reporting regime adds pressure here. Major incidents must be reported within tight timelines (often within hours), and firms will be expected to describe recovery actions, timings, and root cause. Delayed or ineffective recovery becomes a reportable regulatory failure.

DORA Article 12: Backup Policies and Recovery Methods

CASPs must document backup policies, clear restoration, and recovery methods. For CASPs, the systems enabling access to client assets, wallets, custody integrations, signing workflows, are inherently critical ICT.

CASPs should therefore:

• Identify components essential to maintaining access to client assets
• Ensure those components can be restored quickly
• Maintain tested recovery procedures for provider outages
• Define realistic recovery-time objectives (RTOs) for asset access

Article 12 reinforces that CASPs must be able to recover the systems that make asset access possible, not just theoretically, but in real-world, provider-failure scenarios.

DORA Articles 28–29: ICT Third-Party Concentration Risk

DORA warns against dependence on ICT providers “not easily substitutable.” Custodians, wallet vendors, MPC providers, and infrastructure vendors can all present concentration risk, and CASPs must demonstrate how they mitigate it.

This is a serious issue for CASPs because most rely on a single provider for custody or key management, meaning substitutability is extremely limited in practice.

‍

3. Meeting the Threshold: What CASPs Must Have

A CASP aiming to comply with MiCA and DORA must establish a layered control environment.

1. Prevention Controls

• Strong authentication
• Role-based access
• Multi-party approval controls (e.g., multi-signature or MPC)
• Hardening of custody and wallet systems

2. Detection Controls

• Anomaly monitoring for signing and transactions
• Telemetry and logging for custody integrations
• Availability monitoring for key service providers

3. Response Controls

• Classify incidents
• Contain and mitigate threats
• Document timelines and evidence
• Escalate security and operational events
• Coordinate response across stakeholders

4. Recovery Controls

• Restore operations when a custodian, wallet vendor, or internal system fails
• Define and meet appropriate recovery time objectives
• Execute tested and verifiable recovery workflows
• Demonstrate regulatory evidence of failover testing

‍

4. Why Incident Response Is a Compliance Obligation

Across both frameworks, the expectations are clear:

MiCA requires:

• Resilient ICT
• Detection and response capabilities
• Safeguarding of client assets
• Timely recovery of services

DORA requires:

• Documented continuity and disaster-recovery plans
• Working, testable recovery procedures
• Drills, evidence, and auditability
• Alternatives to single points of failure
• Management of concentration risk

‍

5. How Circuit Enables Active Compliance

Circuit’s Recovery solution plugs a gap in the existing tech stack enabling CASPs to restore access and maintain continuity under failure conditions within minutes.

To Illustrate This In Practice

If a wallet provider or custodian goes offline for 24 - 48 hours, a realistic scenario which should be included on most risk registers, a CASP cannot sign transactions, move assets, honour withdrawals, or meet client settlement obligations. Under DORA, this becomes a reportable major incident. Under MiCA, it raises questions about safeguarding and continuity. Without an independent, testable recovery mechanism, the CASP is effectively in breach of multiple regulatory expectations.

How Circuit Addresses This Gap

Circuit allows CASPs to programme and test recovery workflows in advance. These workflows can be activated during outages or as precautionary measures while incident diagnostics are underway, shielding customer funds from risk. They remove vendor concentration risk by providing the operational mechanism required for vendor substitution, enabling CASPs to implement technical diversity to their stack, and move swiftly across the stack as required.

Crucially, Circuit enables firms to test these workflows regularly and present evidence to regulators that recovery is real, functional, and secure, without compromising wallet integrity.

As MiCA and DORA reshape digital asset operations in Europe, CASPs opt for demonstrable resilience over aspirational resilience. That requires:

• Early detection of incidents
• Structured response workflows
• Reliable and testable recovery mechanisms
• Functional substitutability for high-risk custody dependencies
• Evidence-based operational resilience, not policy-level assertions

Firms that invest now will be better prepared for regulatory scrutiny and more resilient in the face of operational failures.