MiCA and DORA: How the Two Regimes Overlap for Crypto Firms

Firms preparing a CASP application often treat MiCA as the whole job. It is not. DORA applies to the same entities, covers different ground, and is increasingly reviewed alongside the authorisation file. Teams that budget for one and discover the other halfway through lose months.

Here is how the two fit together.

What each regime is for

MiCA is market conduct and prudential regulation. It governs who may provide crypto-asset services in the EU, what capital they hold, how they treat clients, how they safeguard client assets, and what they must disclose.

DORA is operational resilience. It governs how financial entities manage ICT risk — systems, incidents, testing, and dependence on third-party technology providers. It applies across financial services, and authorised CASPs are in scope.

Put simply: MiCA asks whether you should be allowed to operate. DORA asks whether your systems will hold up when something breaks.

Where they overlap

Governance

Both require a management body that understands and owns the risk. MiCA wants fit-and-proper directors with relevant experience. DORA wants that same body to approve and periodically review the ICT risk framework. One board, two sets of documented responsibilities — and the minutes need to show both.

Incident reporting

MiCA has disclosure obligations around operational events affecting clients. DORA imposes a specific, tightly timed regime for major ICT-related incidents, with initial, intermediate and final reports. If you build only to MiCA's expectations, you will miss DORA's clocks.

Third-party risk

This is the sharpest overlap for crypto firms, because the stack is almost entirely outsourced. Your custody technology, node infrastructure, KYC vendor, screening provider and monitoring tool are all ICT third-party providers under DORA. That means a register of information, contractual clauses on audit and exit, and concentration-risk assessment.

Firms are frequently caught out here: they have selected good vendors but have no register, no exit plan, and contracts that lack the required audit rights.

Business continuity

Both regimes want continuity and recovery plans. DORA is more prescriptive, requiring testing on a defined cadence and, for significant entities, threat-led penetration testing.

Where they diverge

• Capital. MiCA sets prudential minimums by service class. DORA sets none.
• Client asset safeguarding. Purely MiCA.
• Resilience testing. Purely DORA — MiCA has nothing equivalent.
• Passporting. A MiCA concept. DORA applies regardless.
• Whitepapers and marketing. MiCA only.

The practical sequencing mistake

The common failure is treating DORA as a post-authorisation project. Two reasons that backfires:

First, your CASP application describes your operational setup. If the ICT risk section is thin, you invite questions that stop the clock — and every round of questions adds weeks. See CASP licence cost in 2026 for how those delays compound.

Second, the third-party register requires contract terms you may not have. Renegotiating audit and exit clauses with an incumbent vendor after signing is slow and expensive. Get them in the first contract.

A combined checklist

1. One risk framework, two mappings. Write it once, map controls to both regimes, so evidence is not duplicated.
2. Build the ICT third-party register early. Every vendor touching production, with criticality, exit plan and substitutability.
3. Fix contracts before you sign. Audit rights, incident notification, exit assistance, subcontracting limits.
4. Set incident clocks in the runbook. DORA's timings are tight; discovering them during an incident is too late.
5. Schedule resilience testing. Put dates in the plan the regulator sees.
6. Name owners. Both regimes want a person, not a department.

What this means for vendor selection

Because vendors become your DORA third-party dependencies, procurement stops being purely a compliance-features question. When you evaluate KYC providers, sanctions screening software or transaction monitoring software, ask about uptime history, incident notification commitments, audit rights and what exit actually looks like.

A vendor that cannot give you an exit plan is a concentration risk you will have to document and justify.

Further reading

Our DORA compliance guide for crypto firms goes deeper on the ICT requirements, and the CASP and MiCA overview covers the authorisation side. If you are still choosing where to apply, jurisdictions compared sets out what actually differs.