DORA vs MiCA: 2026 Compliance Guide for EU…

In this article ↓

DORA vs MiCA: the short answer
DORA vs MiCA at a glance
Which regime owns which question?
DORA in scope: what changed in 2025-2026
MiCA in scope: dates that matter through 2026
MiCA Article 143 transitional measures and the 1 July 2026 cliff
Who is in scope?
DORA financial entities relevant to crypto and fintech
MiCA-authorised or MiCA-relevant entities
Scope map for common CASP models
What CASPs must do in 2026
Incident reporting and operational resilience
One incident workflow, two regulatory paths
MiCA authorisation and transitional period
Side-by-side: what a CASP actually files under each regime
DORA and MiCA evidence index
Common pitfalls
30-day CASP readiness plan
FAQ
Does MiCA replace DORA for crypto firms?
Does DORA apply before MiCA authorisation?
Are all CASPs required to perform threat-led penetration testing?
What if our CASP application is still pending on 1 July 2026?
Do we need separate DORA and MiCA evidence sets?
How does MiCA interact with PSD2/EMD for EMTs?
Which jurisdictions matter most for CASP planning?
Related NCA guides
Related reading
Primary sources
Bottom line

Last reviewed: 30 April 2026

DORA vs MiCA: the short answer

DORA and MiCA are two distinct EU regulations that increasingly intersect for crypto-asset firms operating in the Union:

DORA — Regulation (EU) 2022/2554 — governs digital operational resilience for financial entities: ICT risk management, incident reporting, resilience testing and ICT third-party risk.
MiCA — Regulation (EU) 2023/1114 — governs issuance of crypto-assets and the provision of crypto-asset services in the EU: authorisation, conduct, market abuse, consumer protection and prudential requirements.

For MiCA-authorised CASPs and issuers of asset-referenced tokens (ARTs), both frameworks apply. MiCA defines the licence, services and conduct perimeter. DORA defines the digital operational resilience operating model for the same financial entity.

The practical rule for 2026: do not build a MiCA programme first and a DORA programme later. Build one governance and evidence base with two regulatory views.

DORA vs MiCA at a glance

Topic	DORA	MiCA	CASP impact
Subject matter	Digital operational resilience for financial entities	Markets in crypto-assets: issuance, services, conduct and authorisation	Both regimes apply once the CASP is authorised under MiCA
Status in 2026	Applies since 17 January 2025	Titles III-IV apply since 30 June 2024; main regime applies since 30 December 2024	Authorisation, conduct and resilience evidence are live issues
Authorisation	No DORA licence; DORA attaches to entities already in scope	Mandatory MiCA authorisation by national competent authority	MiCA authorisation creates the CASP operating perimeter
Scope of entities	Financial entities listed in Article 2, including authorised CASPs and ART issuers	CASPs, ART issuers, EMT issuers, offerors and persons seeking admission to trading	CASPs sit in both frameworks
ICT risk	Core requirement: governance, framework, controls, testing, incidents, third parties	ICT resilience is not the main MiCA framework	Build ICT resilience to DORA and use it as MiCA evidence where relevant
Incident reporting	Major ICT-related incidents and voluntary significant cyber-threat notification	MiCA-specific notifications and conduct / market integrity events	One incident workflow with DORA and MiCA decision points
Resilience testing	Risk-based testing programme; TLPT for entities identified by competent authorities	No equivalent TLPT regime	DORA drives resilience test evidence
Third-party ICT risk	Register of Information, lifecycle oversight and contract provisions	MiCA application and governance evidence may include outsourcing / operational arrangements	One supplier model, mapped to both views
Supervisory route	Financial competent authority / ESA technical standards	National competent authority under MiCA, ESMA coordination in defined areas	Authority mapping matters by Member State
Best evidence model	ICT risk, incident, testing, BCDR, supplier and board evidence	Authorisation, governance, conduct, prudential and disclosure evidence	One evidence index with DORA and MiCA columns

Which regime owns which question?

This is the fastest way to avoid duplication.

Question	Primary regime	Practical answer
Can the firm provide crypto-asset services in the EU?	MiCA	Confirm authorisation, transitional status and service perimeter
Can the firm withstand ICT disruption?	DORA	Maintain ICT risk, BCDR, testing and third-party evidence
Is the CASP's governance adequate?	MiCA + DORA	MiCA for authorisation / conduct governance; DORA for ICT risk oversight
How are ICT incidents classified and reported?	DORA	Use DORA classification, notification and evidence workflow
How are conduct, market abuse or customer-impact events handled?	MiCA	Route through MiCA-specific governance and authority channels
Are critical ICT suppliers controlled?	DORA	Maintain Register of Information, criticality, contracts and exit evidence
Are customer disclosures and crypto-asset services compliant?	MiCA	Maintain MiCA service, disclosure, complaints and conduct evidence
Does the board understand operational resilience?	DORA + MiCA	Use one board pack with separate ICT resilience and MiCA conduct views

For a CASP, DORA is not a side annex. It is the operational resilience layer under the licensed business.

DORA in scope: what changed in 2025-2026

DORA has applied since 17 January 2025. The deadline question is closed. In 2026 supervisors, partner banks and counterparties examine operating evidence:

ICT risk management framework approved by the management body and reviewed on a defined cadence;
ICT-related incident management aligned with the EU technical standards on classification and reporting;
digital operational resilience testing programme;
threat-led penetration testing (TLPT) where the entity is identified by competent authorities under Article 26;
ICT third-party risk lifecycle, Register of Information and contractual provisions for ICT services supporting critical or important functions.

For CASPs and ART issuers, being a "financial entity" under DORA Article 2 means the framework applies. What each entity implements should be calibrated by proportionality to size, risk profile, nature, scale and complexity.

MiCA in scope: dates that matter through 2026

MiCA — Regulation (EU) 2023/1114 — entered into force in 2023 with staggered application dates set out in MiCA Article 149:

30 June 2024 — Titles III and IV apply: rules for issuers of asset-referenced tokens (ARTs) and e-money tokens (EMTs).
30 December 2024 — the main MiCA regime applies, including Title V on the authorisation and operating conditions for crypto-asset service providers (CASPs).

MiCA Article 143 transitional measures and the 1 July 2026 cliff

MiCA Article 143 allows an entity providing crypto-asset services in a Member State before 30 December 2024 to continue under existing national rules until 1 July 2026.

The permission ends earlier if MiCA authorisation is granted or refused. Member States could also shorten this by national option.

On 17 April 2026, ESMA issued a public statement on the end of the MiCA transitional periods. The safe operating message is:

after 1 July 2026, an entity providing crypto-asset services to clients in the EU without MiCA authorisation should expect enforcement risk and must not assume continued grandfathering;
Member State transitional options and national supervisory practice still matter;
a pending application should not be treated as a substitute for authorisation after the transitional period ends.

For CASPs that have applied for authorisation but have not received a decision, the practical exposure window is narrow. The compliance plan should include both the MiCA authorisation file and the DORA evidence base.

Who is in scope?

DORA financial entities relevant to crypto and fintech

Crypto-asset service providers authorised under MiCA
Issuers of asset-referenced tokens under MiCA
Credit institutions, payment institutions and electronic money institutions
Investment firms, central counterparties and trading venues
ICT third-party service providers under the separate DORA oversight framework where designated

MiCA-authorised or MiCA-relevant entities

CASPs providing services such as custody, exchange, execution, placing, reception and transmission, advice, portfolio management or transfer services
Issuers of asset-referenced tokens (ARTs)
Issuers of e-money tokens (EMTs)
Offerors and persons seeking admission to trading of crypto-assets other than ARTs and EMTs

A MiCA-authorised CASP or ART issuer is therefore in DORA scope as a financial entity. An EMT issuer may also sit across MiCA, e-money / payment services law and DORA depending on the entity and activity.

Scope map for common CASP models

Business model	MiCA view	DORA view	Main operating risk
Crypto custody provider	CASP service authorisation, safeguarding and conduct controls	ICT risk, key management, access control, incident and BCDR evidence	Loss of access, key compromise, supplier outage
Crypto exchange / broker	CASP authorisation, order handling, market integrity and complaints	Platform resilience, incident classification, supplier and testing evidence	Trading outage, data integrity issue, customer impact
Transfer service provider	CASP transfer service and AML / operational controls	Availability, transaction integrity, incident and supplier evidence	Failed transfers, chain analytics dependency, API outage
ART issuer	MiCA Title III issuance, governance and reserve-related obligations	DORA financial entity scope and ICT resilience evidence	Reserve process disruption, wallet / platform dependency
EMT issuer	MiCA Title IV plus e-money / payment-services alignment	DORA applies where the entity is a financial entity	Payment continuity, redemption process, core banking dependency
CASP using group technology company	MiCA authorisation remains with CASP	Intra-group technology may be ICT third-party / dependency evidence	Informal service ownership and weak exit assumptions

This table is not a legal scope opinion. It is an operating map for evidence planning.

What CASPs must do in 2026

Workstream	What to do	Evidence to keep
MiCA authorisation	Confirm authorised, refused, pending or transitional status by Member State	Authorisation file, NCA correspondence, service perimeter
DORA scope	Confirm CASP / ART issuer status under DORA Article 2	Scope note, entity map, licence map
ICT risk	Map systems, critical functions, controls and owners	ICT risk framework, risk register, control map
Incidents	Add DORA major ICT-related incident decision points	Incident workflow, classification log, authority route
Testing	Run a risk-based digital operational resilience testing programme	Test plan, tabletop, findings, remediation tracker
TLPT	Confirm whether competent authority identification applies	TLPT scope decision or rationale
Suppliers	Map ICT third-party arrangements supporting critical or important functions	Register of Information, contract gap tracker, exit assumptions
Board reporting	Report ICT risk and MiCA operating risk in one governance cadence	Board pack, decision log, risk acceptance
Evidence index	Reconcile DORA and MiCA artefacts	Evidence index with owner, location, review date

The highest-risk sequencing mistake is to wait for MiCA authorisation before building DORA evidence. A CASP application and a DORA operating model should be prepared in parallel.

Incident reporting and operational resilience

DORA's incident-reporting cadence under Articles 17-19 follows the Joint Technical Standards on major incident reporting:

Major ICT-related incidents — once an incident is classified as major:
- initial notification — within 4 hours after classification, and no later than 24 hours after the entity becomes aware of or detects the incident;
- intermediate report — within 72 hours of the initial notification;
- final report — within one month of the latest intermediate report, including root cause and remediation.
Significant cyber threats — voluntary notifications. There is no mandatory cyber-threat reporting regime under DORA.

MiCA carries its own conduct, authorisation-condition, market-integrity and customer-impact notification routes. For a CASP, the practical answer is: ICT incidents on the DORA path; MiCA-specific conduct events on the MiCA path; same incident-management process.

One incident workflow, two regulatory paths

Event	DORA path	MiCA path	Evidence note
Cloud outage affecting custody platform	Assess ICT-related incident and major-incident criteria	Assess customer / service continuity and authorisation-condition impact	Keep detection, classification, customer impact and supplier evidence
Key management system compromise	Assess major ICT-related incident and security impact	Assess safeguarding, conduct and customer notification implications	Use one incident log with DORA and MiCA decisions
Trading platform outage	Assess ICT service disruption and financial / client impact	Assess service obligations, complaints and market integrity impact	Capture duration, transactions affected and remediation
Complaint surge after technical failure	DORA if caused by ICT disruption	MiCA complaints / conduct route likely relevant	Link complaints evidence to incident root cause
Market abuse surveillance failure	DORA only if ICT disruption or control failure meets criteria	MiCA / market abuse governance path likely primary	Keep control failure, duration and remediation evidence
Supplier breach	Assess third-party ICT incident and critical function impact	Assess service, customer and outsourcing implications	Use supplier contract and notification evidence

This table prevents a common failure: classifying an event only as a technical incident while missing MiCA conduct consequences, or treating a conduct issue as a MiCA-only matter while missing DORA ICT reporting.

MiCA authorisation and transitional period

Apply early. MiCA authorisation is national-competent-authority-led, and timelines vary by Member State.
Treat the application as a control-evidence exercise. Governance, capital, AML/CFT, conflicts of interest, ICT risk, BCDR documentation, complaints handling and outsourcing arrangements can all become part of the review.
Plan for parallel DORA scrutiny. As soon as authorisation is granted and the entity is in DORA scope, DORA obligations apply as a financial entity. Do not sequence it as "MiCA first, DORA later."
Watch national transitional shortenings. Some Member States use the Article 143 national option to shorten the transitional period below 1 July 2026. Confirm the local cut-off.
Do not assume pending status solves the cliff. After the transitional period, providing crypto-asset services without authorisation creates enforcement exposure.

Side-by-side: what a CASP actually files under each regime

The discovery question we hear most often: "as a MiCA-authorised CASP, what does each regulator actually want to see?" The two evidence sets overlap less than the policy text suggests.

Artefact	DORA view	MiCA view	Same evidence?
Authorisation file	Not a DORA artefact	Core MiCA application pack	No, MiCA-only
ICT risk management framework	Core DORA framework approved and reviewed under governance	Supports operational-resilience credibility in authorisation / supervision	Yes, DORA artefact relied on in MiCA context
ICT risk register	DORA risk ownership, treatment and control evidence	Supports governance and operational risk narrative	Shared evidence
Register of Information	DORA Article 28 ICT third-party arrangements	Supports supplier / outsourcing view where relevant	Shared base, DORA format
Incident classification taxonomy	DORA Article 18 and related technical standards	MiCA conduct / customer / market-integrity events use a separate logic	One workflow, different triggers
Major ICT incident notification	DORA reporting path	Not a MiCA filing by default	Separate filing
Conduct / complaints event	DORA only if ICT-related and reportable	MiCA path likely relevant	Separate filing, shared incident log
TLPT scope decision	DORA Article 26, authority-led identification	No equivalent MiCA requirement	DORA-only
Whitepaper / public disclosures	Not applicable	ART / EMT / crypto-asset disclosure obligations	MiCA-only
BCDR evidence	DORA Articles 11-12 continuity and recovery evidence	Supports operational continuity narrative	Shared evidence
Board / management-body reporting	ICT risk, incidents, testing, suppliers and remediation	MiCA conduct, prudential and service governance	Combine into one pack with two views

The clean operating model: one underlying control set, two regulator views. CASPs that try to maintain a "DORA pack" and a separate "MiCA pack" duplicate work and produce inconsistent narratives.

DORA and MiCA evidence index

Evidence artefact	DORA owner	MiCA owner	Refresh trigger
Entity and licence map	Compliance / legal	Compliance / legal	Authorisation, service or jurisdiction change
ICT risk framework	ICT risk owner	Governance owner relies on it	Annual review or material change
ICT risk register	Risk / security / technology	Operational risk input	Quarterly or material risk change
Incident workflow	Incident manager / compliance	Conduct / customer-impact owner	Incident, tabletop or authority-route change
BCDR test report	Operations / technology	Governance / continuity owner	Annual test or material service change
Register of Information	Supplier / ICT risk owner	Supplier / outsourcing evidence owner	Supplier, contract or function change
Contract gap tracker	Legal / procurement / risk	Legal / operations	Contract renewal or new critical supplier
Complaints handling evidence	Not DORA unless ICT-related	MiCA conduct owner	Complaints trend or process change
Board pack	CEO / COO / risk owner	CEO / compliance / conduct owner	Each management-body review
Remediation tracker	Control owners	Control owners	Weekly or monthly until closure

This evidence index is useful because it shows where one artefact can support both regimes and where separate filings remain necessary.

Common pitfalls

Pitfall	Why it is risky	Better approach
Treating DORA as an add-on after MiCA authorisation	DORA applies when the entity is in scope as a financial entity	Build DORA evidence alongside MiCA authorisation work
Saying "CASPs must implement every DORA item in the same way"	Overstates non-universal items such as TLPT	Say DORA applies, calibrated by scope, proportionality and authority identification
Over-applying TLPT	TLPT is not universal for every CASP	Record whether authority identification applies
Using a generic "24-hour incident rule"	Misses DORA classification and 4-hour trigger	Use DORA incident workflow with classification timestamps
Treating significant cyber threats as mandatory reports	DORA significant cyber-threat notification is voluntary	Keep voluntary-notification decision logic
Maintaining two supplier registers	Creates inconsistent supplier evidence	Maintain one Register of Information and map MiCA supplier evidence
Assuming national grandfathering will extend	Article 143 has a hard EU backstop subject to national options	Confirm national position and authorisation status
Ignoring intra-group technology	CASPs often depend on group engineering or infrastructure	Treat intra-group ICT services as real dependencies

30-day CASP readiness plan

Week	Action	Output
Week 1	Confirm MiCA authorisation / transitional status by Member State	Licence and authority map
Week 1	Confirm DORA scope and entity perimeter	DORA scope note
Week 2	Map critical services, systems and suppliers	Critical function and supplier dependency map
Week 2	Build incident workflow with DORA and MiCA decision points	Unified incident classification and notification process
Week 3	Review ICT contracts and Register of Information inputs	Contract gap tracker and RoI update list
Week 3	Prepare board pack view	ICT risk, MiCA conduct risk, incidents, suppliers, remediation
Week 4	Run one tabletop scenario	Evidence of timestamps, decisions, gaps and remediation
Week 4	Build evidence index	Owner, location, review date and regulatory view for each artefact

This plan does not replace authorisation legal work. It gives the CASP an operating base that makes MiCA and DORA evidence consistent.

FAQ

Does MiCA replace DORA for crypto firms?

No. They cover different subject matter and apply in parallel. MiCA defines the licence and the conduct rules; DORA defines digital operational resilience obligations on the same entity once it is in scope as a financial entity.

Does DORA apply before MiCA authorisation?

DORA applies to entities in DORA scope. For CASPs, the clearest DORA trigger is MiCA authorisation bringing the entity into the DORA financial-entity perimeter. Transitional, group and provider scenarios may need separate analysis.

Are all CASPs required to perform threat-led penetration testing?

No. Article 26 TLPT applies at least every three years to financial entities identified by competent authorities based on the relevant criteria. CASPs that are not so identified are outside the mandatory TLPT requirement, although they may still perform advanced testing voluntarily.

What if our CASP application is still pending on 1 July 2026?

The safe position is not to treat a pending application as authorisation. MiCA Article 143 and ESMA's 17 April 2026 statement point to a hard transition risk after 1 July 2026, subject to the exact national facts and supervisory position.

Do we need separate DORA and MiCA evidence sets?

No. Build one underlying control set for ICT risk, BCDR, third-party risk, incident management and board reporting, then present it through DORA and MiCA views. Some artefacts remain MiCA-only, such as authorisation and disclosure materials.

How does MiCA interact with PSD2/EMD for EMTs?

E-money token issuers may need to align MiCA Title IV with e-money and payment-services regimes depending on activities. ICT and resilience obligations for a financial entity flow through DORA.

Which jurisdictions matter most for CASP planning?

Start with the Member State of authorisation and any jurisdictions where the entity provides services or relies on transitional arrangements. Cyprus, Malta, Estonia, Lithuania and Ireland often appear in fintech / CASP planning, but the correct route depends on the entity and service model.

Primary sources

Bottom line

DORA and MiCA are not competing frameworks.

MiCA decides whether and how the crypto-asset business is authorised and supervised. DORA decides whether the same financial entity can govern, protect, test and recover its ICT services.

For CASPs in 2026, the strongest operating model is one evidence base with two views: MiCA for authorisation and conduct, DORA for digital operational resilience.

DORA vs MiCA: 2026 Compliance Guide for EU Fintechs and CASPs