MiCA Compliance for CASPs: ICT, Operational Resilience and DORA Obligations

In this article ↓

1. Short answer
2. Who is a CASP under MiCA?
3. MiCA authorisation: what CASPs must demonstrate
4. MiCA ICT and security requirements for CASPs
5. Governance obligations under MiCA
6. How DORA applies to CASPs
7. MiCA and DORA: complementary, not duplicative
8. MiCA CASP timeline
9. Evidence: what a CASP needs to maintain
10. Related reading
11. Primary sources
12. FAQ
13. Who qualifies as a CASP under MiCA?
14. When did MiCA CASP provisions apply?
15. Does DORA apply to CASPs?
16. What is the relationship between MiCA and DORA for ICT compliance?
17. What ICT evidence does a CASP need for MiCA authorisation?
18. What is the MiCA Article 143 transitional period?
19. Does every CASP need threat-led penetration testing (TLPT)?
20. Where should a CASP confirm its competent authority and authorisation requirements?

Last reviewed: 14 August 2026

This page covers MiCA authorisation requirements for CASPs, with DORA as the operative ICT framework. For a side-by-side comparison of DORA and MiCA obligations across all in-scope entities, see DORA vs MiCA: 2026 Compliance Guide →.

Short answer

A crypto-asset service provider in 2026 operates under two EU-level regulations at once.

MiCA — Regulation (EU) 2023/1114 — governs who can provide crypto-asset services in the EU, on what conditions, and with what ongoing obligations on governance, prudential requirements, conduct of business and client protection. Title V provisions for CASPs have applied since 30 December 2024.

DORA — Regulation (EU) 2022/2554 — governs ICT risk management, incident reporting, resilience testing and ICT third-party risk for EU financial entities, including authorised CASPs. DORA has applied since 17 January 2025.

The practical implication is that a CASP needs a MiCA-compliant conduct and governance framework alongside a DORA-compliant ICT operational resilience programme. Evidence from DORA — ICT risk register, incident workflows, Register of Information, resilience test records, board reporting — also supports the MiCA supervisory picture on operational risk. The two frameworks are not duplicative: they address different dimensions. Well-designed programmes share a core evidence layer rather than running two parallel documentation projects.

For a worked engagement case, see the CASP MiCA and DORA readiness case study. For a fixed-scope engagement that builds one MiCA × DORA control set, see MiCA & DORA: one ICT control set for CASPs →.

Who is a CASP under MiCA?

Under MiCA, a crypto-asset service provider is any legal person or other undertaking whose occupation or business is the provision of one or more crypto-asset services to third parties on a professional basis, and that is authorised under MiCA to do so (MiCA Title V, Chapter 1).

MiCA defines ten categories of crypto-asset service:

1. Custody and administration of crypto-assets on behalf of clients
2. Operation of a trading platform for crypto-assets
3. Exchange of crypto-assets for funds
4. Exchange of crypto-assets for other crypto-assets
5. Execution of orders for crypto-assets on behalf of clients
6. Placing of crypto-assets
7. Reception and transmission of orders for crypto-assets on behalf of clients
8. Providing advice on crypto-assets
9. Providing portfolio management on crypto-assets
10. Providing transfer services for crypto-assets to clients

Entities providing any of these services in the EU generally require CASP authorisation under MiCA. Certain EU-regulated entities (credit institutions, central securities depositories, investment firms, electronic money institutions, UCITS management companies, alternative investment fund managers and market operators already authorised under sector-specific law) may provide specified crypto-asset services under a notification procedure rather than a full CASP authorisation (MiCA Article 60). Entity-specific legal analysis is required before assuming an exemption applies.

MiCA authorisation: what CASPs must demonstrate

To obtain and maintain authorisation as a CASP, an entity must meet and continue to meet the conditions set out in MiCA Title V. Core ongoing requirements include:

The national competent authority of the Member State where the CASP is registered handles authorisation. Once authorised, the CASP can passport services across the EU under the MiCA notification mechanism.

For jurisdiction-specific NCA contacts, see the DORA National Competent Authorities hub.

MiCA ICT and security requirements for CASPs

MiCA requires CASPs to operate resilient and secure ICT systems and to have systems and procedures that safeguard the availability, authenticity, integrity and confidentiality of data, both pursuant to DORA (MiCA Article 68(7)-(8)).

This cross-reference to DORA in MiCA's ICT requirement is intentional. For CASPs that are DORA financial entities — which all authorised CASPs are, under DORA Article 2 — DORA is the operative ICT risk framework. MiCA does not impose a separate ICT risk management regime on top of DORA for ongoing ICT operations: Article 68(7)-(8) ties the CASP's system resilience and data-safeguarding duties directly to DORA. What DORA does not replace is the MiCA-specific authorisation evidence (Article 62(2)) and the evidence table below, a DORA-compliant operating posture is the substance, but the MiCA application and supervisory record still need their own documentation.

In practice, the DORA ICT risk management framework (DORA Articles 5–16) covers the MiCA ICT requirement:

Business continuity. MiCA requires CASPs to maintain and operate a documented business continuity policy (MiCA Article 68(7)), with CASP-specific content set out in Commission Delegated Regulation (EU) 2025/299: scope and governance, escalation to the management body, adverse scenarios, recovery objectives, external communication and annual testing. This aligns with DORA's ICT business continuity and disaster recovery requirements under DORA Articles 11 and 12, but a DORA-compliant BCDR programme alone does not fully satisfy the MiCA obligation. The CASP-specific elements in RTS 2025/299 still need to be addressed. For a practical guide, see DORA Business Continuity and Disaster Recovery.

Incident notification. MiCA itself does not create a general regime for notifying the competent authority of operational incidents. Its Title V Chapter 2 notification duties (Articles 68-69) cover business continuity plan governance and changes to the management body, plus a narrower communication duty under RTS 2025/299 when a continuity plan is activated. DORA creates the tiered, detailed incident classification and reporting regime for major ICT-related incidents — with prescribed timelines for initial notification, intermediate report and final report under DORA Article 19. For CASPs, DORA incident reporting is the operative regime for ICT-related events. For full timelines, see DORA Incident Reporting.

Governance obligations under MiCA

MiCA requires CASPs to maintain a clear and transparent governance structure with well-defined lines of responsibility and accountability. The main obligations:

• Management body: Members must be of good repute, hold appropriate knowledge, skills and experience, give sufficient time commitment, and collectively reflect diversity of experience.
• Internal control framework: CASPs must maintain adequate internal controls — including compliance and risk management functions — proportionate to the nature, scale and complexity of their services.
• Policies and procedures: Written policies covering governance, risk management, conflicts of interest, complaints, safeguarding and ICT must be maintained, reviewed periodically and available to supervisors on request.
• Regular review: MiCA requires the management body to periodically assess and review the effectiveness of governance policies and procedures, and to address any deficiencies found (MiCA Article 68(6)). Reviewing after a material change in service scope, technology stack or regulatory context is good practice, not a separate MiCA requirement.

Board-level ICT risk oversight is required under both DORA (DORA Article 5) and MiCA governance requirements. Neither regulation defines a single certifying "reporting pack," but a board reporting pack covering ICT risks, incidents, third-party exposure, remediation status and testing results, built to DORA's Article 5 governance expectations, can serve as the evidence base for both the DORA and the MiCA management-body conversation. For board reporting guidance, see DORA Board Responsibilities for EU Financial Entities.

How DORA applies to CASPs

CASPs authorised under MiCA are explicitly listed as financial entities in DORA Article 2. Four of DORA's five pillars apply as binding obligations from 17 January 2025: ICT risk management (Articles 5–16), incident management (Articles 17–23), resilience testing (Articles 24–27) and ICT third-party risk (Articles 28–44), proportionate to the CASP's size, risk profile and complexity under DORA's proportionality principle (Article 4). The fifth, information sharing (Article 45), is voluntary for all financial entities, CASPs included.

For most CASPs, the practical starting point is the ICT risk management framework, the Register of Information and an incident classification workflow. For a gap analysis approach, see the DORA Gap Analysis hub and DORA Third-Party ICT Risk.

For the full DORA vs MiCA comparison — which regime owns which obligation, side-by-side evidence tables, and the 30-day CASP readiness plan — see DORA vs MiCA: 2026 Compliance Guide →.

MiCA and DORA: complementary, not duplicative

The two regulations govern different dimensions of CASP operations:

A CASP benefits from building one operating model — DORA as the ICT backbone, MiCA as the authorisation and conduct layer — rather than running two parallel documentation programmes. Evidence reuse is the practical objective, not conflation of legal obligations.

For the full DORA vs MiCA comparison, see DORA vs MiCA: 2026 Compliance Guide.

MiCA CASP timeline

Article 143 transitional note: An entity that was lawfully providing crypto-asset services in a Member State under national law before 30 December 2024 could continue operating during the Article 143 transitional period, which ran until the entity's MiCA authorisation was granted or refused, or 1 July 2026 at the latest for most jurisdictions, whichever came sooner. That transitional period has now ended everywhere in the EU. Some Member States used the Article 143 option to shorten this period below 1 July 2026.

Article 143(3) framed this as a choice, not an unconditional filing duty: an entity in the transitional period could continue operating only until it obtained MiCA authorisation, was refused authorisation, or reached its national deadline (1 July 2026 at the latest), whichever came first. Every Member State's transitional window has now closed; operating without MiCA authorisation is not permitted.

Evidence: what a CASP needs to maintain

An authorised CASP in 2026 must be able to demonstrate compliance across both regimes. The evidence landscape by area:

The practical approach is a shared evidence index — one document owner per area, with annotations showing which obligation each artefact supports. This avoids duplicate maintenance and makes regulatory reviews and partner due diligence faster. For a template, see DORA Evidence Index Template.

Related reading

• DORA vs MiCA: 2026 Compliance Guide for EU Fintechs and CASPs
• Case Study: MiCA and DORA Readiness for a CASP
• DORA Gap Analysis: A Practical Guide for EU Fintechs
• DORA Third-Party ICT Risk: Articles 28–30 Guide for 2026
• DORA Incident Reporting 2026: Initial Notification, Intermediate and Final Report Timeline
• DORA Business Continuity and Disaster Recovery: Articles 11–12 Roadmap
• DORA National Competent Authorities — selected jurisdiction guides
• vCISO for EU Fintechs: 2026 Guide to Scope, Evidence and Retainers

Primary sources

• Regulation (EU) 2023/1114 — MiCA, EUR-Lex
• Regulation (EU) 2022/2554 — DORA, EUR-Lex
• ESMA — Markets in Crypto-Assets Regulation (MiCA)
• MiCA Article 143 — Transitional measures
• EBA — Digital Operational Resilience Act (DORA)
• EBA — Markets in Crypto-Assets (MiCA)
• Commission Delegated Regulation (EU) 2025/299 — RTS on continuity and regularity in the performance of crypto-asset services (CASP business continuity plans)
• Commission Delegated Regulation (EU) 2025/305 — RTS on the information to be included in an application for authorisation as a crypto-asset service provider

FAQ

Who qualifies as a CASP under MiCA?

A crypto-asset service provider is any legal person providing one or more of MiCA's ten defined crypto-asset services on a professional basis in the EU, and authorised to do so under MiCA. Services include custody, trading platform operation, exchange of crypto-assets for funds or for other crypto-assets, order execution, placing, reception and transmission of orders, advice, portfolio management and transfer services. Certain EU-regulated entities (credit institutions, central securities depositories, investment firms, EMIs, UCITS management companies, alternative investment fund managers, market operators) may provide specified services under a notification procedure rather than a full CASP authorisation (MiCA Article 60).

When did MiCA CASP provisions apply?

MiCA Title V provisions for crypto-asset service providers applied from 30 December 2024. Entities lawfully providing crypto-asset services under national law before that date could continue during the Article 143 transitional period, which ran until the entity's MiCA authorisation was granted or refused, or 1 July 2026 at the latest in most Member States. Some Member States shortened this period further. That transitional period has now ended everywhere in the EU; operating without MiCA authorisation is not permitted.

Does DORA apply to CASPs?

Yes. CASPs authorised under MiCA are explicitly listed as financial entities in DORA Article 2. DORA has applied since 17 January 2025. Four of the five DORA pillars, ICT risk management (Articles 5–16), incident management (Articles 17–23), resilience testing (Articles 24–27) and ICT third-party risk (Articles 28–44), apply to CASPs as they do to other DORA financial entities, subject to DORA's proportionality principle (Article 4) and entity-size exemptions built into individual articles. The fifth pillar, information sharing (Article 45), is voluntary for every financial entity, not just CASPs.

What is the relationship between MiCA and DORA for ICT compliance?

MiCA requires CASPs to operate resilient and secure ICT systems and to have systems and procedures that safeguard the availability, authenticity, integrity and confidentiality of data, both pursuant to DORA (MiCA Article 68(7)-(8)). For authorised CASPs, DORA is the operative ICT risk framework for ongoing ICT operations, but it does not replace the MiCA-specific authorisation evidence (Article 62(2)): a DORA-compliant operating posture is the substance, but the MiCA application and supervisory record still need their own documentation. The two regulations are complementary, not duplicative: MiCA governs authorisation and conduct, DORA governs ICT operational resilience.

What ICT evidence does a CASP need for MiCA authorisation?

For MiCA authorisation, a CASP must demonstrate appropriate ICT systems and security protocols, a business continuity policy and adequate governance arrangements. In practice, the application package must include technical documentation of the ICT systems and security arrangements, with a non-technical description (MiCA Article 62(2)(j)), alongside governance and internal-control/risk-management documentation (Article 62(2)(f)/(i)), detailed further by RTS 2025/305. For ongoing supervision, live DORA evidence — ICT risk register, incident records, Register of Information, test results, board reporting — provides the operational substantiation that supervisors and partner banks look for.

What is the MiCA Article 143 transitional period?

MiCA Article 143 allowed entities that were lawfully providing crypto-asset services in a Member State under national law on 30 December 2024 to continue operating until they obtained MiCA authorisation, were refused it, or reached 1 July 2026 at the EU-wide latest, whichever came first. Some Member States used the Article 143 national option to shorten this period below 1 July 2026. That transitional period has now ended everywhere in the EU.

Does every CASP need threat-led penetration testing (TLPT)?

No. TLPT under DORA Article 26 applies only to financial entities identified by competent authorities based on specific criteria — systemic importance, size, ICT risk profile and service criticality. CASPs not identified for TLPT, other than microenterprises, still need the digital operational resilience testing programme under DORA Article 24 (backups, DR tests, incident exercises, vulnerability assessments); microenterprises follow a separate, proportionate testing approach under DORA Article 25(3) instead of the full programme. TLPT is not a universal CASP obligation, and neither is the standard testing programme for the smallest providers.

Where should a CASP confirm its competent authority and authorisation requirements?

The national competent authority for the Member State where the CASP is — or will be — registered handles MiCA authorisation. ESMA maintains a public register of authorised CASPs. For jurisdiction-specific NCA contacts and guidance on DORA reporting channels, see the DORA National Competent Authorities hub.