MiCA and DORA: From Authorisation to Resilient CASP Operations 

MiCA provides the framework under which a crypto-asset service provider is authorised. DORA determines whether that authorised entity can actually deliver its services securely, continuously and under effective control. The two should be designed into one operating model before authorisation, not run as sequential projects. 

For firms seeking to enter the EU crypto-asset market, MiCA is usually the starting point. Authorisation, however, is only part of the journey. 

Once authorised, a crypto-asset service provider must be capable of delivering regulated services securely, continuously and under effective control. This requires clear ICT governance, resilient systems, effective incident management, controlled technology dependencies and evidence that these arrangements work in practice. 

That is where the Digital Operational Resilience Act (DORA) becomes critical. 

When designed well, a coherent MiCA and DORA operating model can enable secure growth, strengthen service continuity, support sustained access to the EU market and provide a sound basis for regulatory compliance. 

Key Takeaways 

• MiCA and DORA are separate regulations, but they converge in the same CASP operating model. 

• DORA should be considered during authorisation, not only after a licence has been granted. 

• Applicants must translate group and third-party technology arrangements into an operating model that the authorised EU entity can govern, explain and evidence. 

• ESMA’s 2026 custody focused Common Supervisory Action illustrates the shift from documented compliance to evidence of operational effectiveness. 

• The evidence expected from a custody CASP will depend on whether infrastructure and controls are operated internally or through third parties. 

MiCA and DORA: Two Regimes, One CASP Operating Model 

MiCA establishes the framework for authorising and supervising crypto-asset service providers and sets requirements relating to governance, conduct, outsourcing, record-keeping and client protection. 

DORA addresses the operational resilience of the systems and arrangements supporting those regulated services. 

MiCA asks: 

• What crypto-asset services will the firm provide? 

• What authorisation and organisational requirements apply? 

• How will clients and their crypto-assets be protected? 

• What governance, conduct and record-keeping obligations must be met? 

DORA asks: 

• How are ICT risks identified and managed? 

• Who is accountable for digital operational resilience? 

• How are incidents detected, escalated, classified and reported? 

• How are critical systems and technology providers controlled? 

• Can the firm maintain or recover services during disruption? 

• Can it demonstrate that controls operate effectively? 

DORA expressly includes CASPs authorised under MiCA within its scope as financial entities. It establishes requirements covering ICT risk management, incident management and reporting, resilience testing and ICT third-party risk. 

The relationship is also explicit within MiCA. 

Article 68(7) requires CASPs to take all reasonable steps to ensure continuity and regularity in the performance of their services, including through resilient and secure ICT systems as required by DORA. It also links CASP business-continuity arrangements to the ICT business-continuity, response and recovery plans established under Articles 11 and 12 of DORA. 

Article 68(8) further requires systems and procedures to safeguard the availability, authenticity, integrity and confidentiality of data in accordance with DORA. 

DORA should therefore not be treated as a technology project that begins after authorisation. 

A proposed CASP operating model that does not adequately address ICT risk, third-party dependencies, incident management, continuity and resilience testing may be incomplete. An authorised CASP must also demonstrate that these arrangements remain effective as its services, systems and outsourcing relationships evolve. Firms preparing a CASP licence application in Malta should reflect this from the outset. 

ESMA’s supervisory briefing on CASP authorisation reinforces this position by identifying substance, governance and outsourcing as key areas for assessment, including the relevance of DORA where authorities assess outsourced ICT infrastructure and third-party risk. 

Why MiCA and DORA Matter  for Non-EU Crypto Groups 

Many non-EU crypto firms enter Europe with mature technology platforms, experienced engineering teams and established security processes. 

The challenge is translating that capability into an EU-regulated operating model with: 

• clear accountability within the authorised entity; 

• effective management-body oversight; 

• documented ICT and service dependencies; 

• control over group and external outsourcing; 

• formal incident-classification and reporting procedures; 

• repeatable resilience testing; and 

• evidence accessible to the CASP and its supervisor. 

This is particularly important where the EU entity relies on global platforms, group security teams, cloud environments or third-country technology providers. 

The authorised CASP cannot rely solely on the statement that technology is managed centrally by the wider group. It must understand the systems supporting its regulated services, retain effective decision-making and oversight, access relevant records and challenge weaknesses where necessary. 

The objective is not simply to replicate group arrangements in Europe. It is to ensure that the EU CASP can govern, explain and evidence those arrangements in its own right. 

DORA and CASP Authorisation: A Maltese Perspective 

The MFSA’s June 2026 observations on digital operational resilience in authorisation applications provide a useful Maltese perspective. 

Drawing on applications received across the financial-services sector during 2025, the Authority identified ICT risk management as the area presenting the greatest challenge. Recurring weaknesses included ICT business continuity, response and recovery plans, business-impact analysis, backup and restoration methods, and the wider ICT risk-management framework. 

The MFSA also identified weaknesses in incident detection, handling, recording, classification and reporting. 

ICT third-party risk was another area requiring attention, particularly contractual provisions, proportionate due diligence and provider-specific exit planning. 

Although these observations were not specific to CASPs, they are directly relevant to prospective MiCA applicants. They show that DORA readiness is receiving substantive attention during authorisation and that applicants must translate regulatory requirements into arrangements tailored to their operations. 

Operational resilience should therefore be reflected in governance, systems, contracts, continuity planning and supporting evidence before regulated operations begin. 

ESMA’s Custody Review: MiCA and DORA in Practice 

ESMA’s 2026 Common Supervisory Action on CASPs’ digital operational resilience in relation to custody activities provides a clear example of how MiCA and DORA interact in practice. 

National competent authorities will assess a risk-based sample of authorised CASPs, focusing on the maturity of their CASP digital operational resilience frameworks in relation to custody activities. The exercise will run from the second half of 2026 to the first half of 2027 and covers six areas of DLT-related custody risk: 

• governance arrangements; 

• key and storage management; 

• transaction controls; 

• incident detection and response; 

• smart-contract risks; and 

• dependencies on third-party providers. 

The timing matters. The MiCA transitional period ended on 1 July 2026, so the population under review is the set of firms that actually hold authorisation, and findings will be consolidated into a final report for ESMA in the second half of 2027. 

Custody is a strong example because MiCA and DORA address different dimensions of the same risk. 

Article 75 of MiCA sets MiCA custody requirements, including client agreements, registers of positions, custody policies, segregation of client holdings, return of crypto-assets or means of access, and measures to minimise losses arising from fraud, cyber threats or negligence. It also establishes liability for losses attributable to the CASP. 

DORA addresses whether the governance, ICT environment, incident arrangements, testing and third-party dependencies supporting those obligations are resilient and effective. 

The practical supervisory question is therefore: can the CASP demonstrate that the controls protecting client crypto-assets and means of access remain effective during normal operations and disruption? 

Six Custody Areas CASPs Should Be Ready to Evidence 

ESMA has not publicly issued a detailed questionnaire for the Common Supervisory Action. The six published areas do, however, indicate where CASPs providing custody should review the maturity and effectiveness of their arrangements. 

The evidence required will depend on how the custody service is delivered. Arrangements may involve the CASP operating relevant infrastructure itself, or using third-party technology and outsourced operational functions while retaining responsibility for the custody service. A CASP may also make use of another CASP authorised under MiCA to provide custody and administration of crypto-assets on behalf of clients. 

Where services or activities are outsourced, the CASP remains responsible for its MiCA obligations. It must retain sufficient expertise, oversight and access to relevant information, and obtain appropriate assurance over externally operated controls. 

1. Governance 

Custody responsibilities should be clearly allocated across the CASP, relevant group entities and third parties. 

The CASP should identify ownership of key management, wallet administration, transaction controls, registers of positions, reconciliation, incident management and provider oversight. Appropriate segregation of duties and meaningful management-body review should also be evidenced. 

2. Key and Storage Management 

The CASP should demonstrate that client crypto-assets and means of access are safeguarded throughout the key lifecycle. 

Relevant evidence may include wallet and key inventories, controlled key generation and storage, privileged-access reviews, backup arrangements and tested recovery procedures. 

Where a provider operates part of the infrastructure, the CASP should understand the architecture, identify retained responsibilities and obtain appropriate assurance over provider-operated controls. The arrangements should also support segregation of client holdings and the return of crypto-assets or means of access where required. 

3. Transaction Controls 

The custody model should support appropriate authentication, approval, execution, monitoring, exception handling and reconciliation of crypto-asset transfers. 

The CASP should maintain accurate registers of positions and a complete control trail showing how transactions, including failed or unusual transfers, were initiated, reviewed and executed. 

4. Incident Detection and Response 

The CASP should be able to detect, or receive timely notification of, custody-related incidents, assess their impact, escalate and classify them, determine whether regulatory reporting is required and coordinate recovery and communications. 

Where a provider performs the technical response, the CASP should retain access to sufficient information and remain responsible for its own regulatory assessment, decisions and reporting obligations. 

Where crypto-assets or means of access are lost, the CASP should also assess whether the incident is attributable to it under MiCA’s custody-liability provisions. 

5. Smart Contract Risk 

Where smart contracts support custody activities, the CASP should understand which contracts are material, how they are governed and who holds upgrade, pause or other privileged rights. 

Appropriate security assessment, change control, monitoring and incident procedures should be evidenced. These are practical preparedness considerations arising from ESMA’s smart-contract-risk theme. 

6. Third-Party Dependencies 

Custody services may depend on wallet providers, MPC solutions, hardware-security modules, cloud platforms, blockchain nodes, external developers or group technology entities. 

CASPs should demonstrate: 

• appropriate due diligence and monitoring; 

• clear allocation of responsibilities; 

• relevant contractual, information and incident-notification provisions; 

• access and audit rights where required; 

• visibility over relevant subcontracting; 

• assessment of concentration and substitutability risks; and 

• credible contingency and exit arrangements. 

The depth of oversight should reflect the importance of the dependency and the consequences of failure, with contractual protections, information and audit rights, contingency arrangements and exit planning tailored accordingly. 

Where another CASP provides custody and administration of crypto-assets on behalf of clients, the firm should verify that it is appropriately authorised under MiCA and inform clients of the arrangement. 

The central supervisory question is whether custody risks are effectively controlled across the end-to-end operating model. 

For internally operated models, this requires direct evidence that controls do function. Where third parties are involved, it requires clear responsibility mapping, retained internal capability and credible assurance over externally operated controls. 

Why Supervisors Now Ask for Evidence, Not Just Policies 

Policies remain important, but they are only one part of the control environment. 

A regulator may also expect to see: 

• management and committee records; 

• system, wallet and dependency inventories; 

• access reviews; 

• reconciliation and transaction records; 

• incident logs; 

• supplier due-diligence files; 

• contractual protections; 

• test and recovery results; and 

• remediation tracking. 

A CASP may have capable engineers and functioning technical controls but still struggle if the authorised entity cannot explain how those controls are governed, monitored and challenged. 

The focus is not only on whether controls are designed. It is whether they are owned, operating and capable of supporting the regulated service during disruption. 

Wider DORA Pressure Points for CASP Operations 

Custody is a particularly topical supervisory example, but similar considerations apply across other crypto-asset services, including trading platforms, exchange, order execution and transfer services. 

Three broader pressure points remain particularly important. 

ICT Third-Party Risk Oversight 

CASPs should understand which providers support regulated services, where concentration risk exists, how subcontracting chains operate and what would happen if a material provider failed. 

Article 28 of DORA requires ICT third-party risk to be managed as an integral component of the financial entity’s ICT risk-management framework. It also requires financial entities to maintain and update a Register of Information covering contractual arrangements for ICT services. 

For CASPs, this means moving beyond a supplier list towards a structured view of services, systems, data, contracts, subcontractors, recovery dependencies and exit feasibility. 

Incident-Management Readiness 

A technical incident-response capability is only one part of the requirement. 

DORA requires financial entities to establish and implement an ICT-related incident-management process, classify incidents according to prescribed criteria and report major ICT-related incidents to the competent authority. 

The CASP therefore needs clear classification criteria, escalation paths, management decision-making, regulatory-reporting procedures and a defensible record of what was decided and why. 

A useful readiness question is this. If a serious ICT incident occurred tomorrow, could the firm identify the affected service, assess client impact, determine whether it was reportable and produce the necessary evidence under pressure? 

Resilience-Testing Governance 

Article 24 of DORA requires financial entities, other than microenterprises, to establish, maintain and review a sound and comprehensive digital operational resilience testing programme as part of the ICT risk-management framework. 

Testing should be linked to critical services and credible disruption scenarios. It should assess whether a regulated service can continue or recover when a critical application, cloud environment, custody component or blockchain dependency fails. 

The value lies not only in performing tests, but in demonstrating that weaknesses are prioritised, remediated and retested. 

Where specialist technical providers are used, the CASP should retain appropriate governance over scope, findings and remediation. 

What Prospective Applicants and Authorised CASPs Should Do Now 

Prospective Applicants 

Applicants should reflect MiCA and DORA in the target operating model from the outset. 

This should include: 

• confirming the regulatory perimeter and services to be offered; 

• mapping systems, data, DLT components and providers; 

• identifying critical or important functions and dependencies; 

• assessing existing group controls against DORA; 

• determining what evidence must be available to the EU entity; and 

• prioritising gaps that could affect authorisation or go-live. 

This is consistent with the MFSA’s observations from the 2025 authorisation cycle, which show that ICT risk, continuity, incident-management and third-party arrangements are receiving substantive attention during authorisation. Requirements can also differ in emphasis between member states, which is worth weighing when comparing CASP licensing across EU jurisdictions. 

Authorised CASPs 

Authorised firms should focus on maintaining and evidencing effective operation. 

This includes: 

• refreshing service and dependency maps; 

• reviewing ICT risks and third-party arrangements; 

• evaluating incident, continuity and recovery exercises; 

• monitoring control exceptions and remediation; 

• ensuring the management body receives meaningful resilience information; and 

• assessing readiness for supervisory scrutiny, including potential regulator engagement under ESMA’s custody focused Common Supervisory Action. 

The objective is not to build an unnecessarily complex framework. 

DORA requires financial entities to apply its ICT risk-management requirements with regard to their size, overall risk profile and the nature, scale and complexity of their services and activities. 

Proportionality does not, however, mean informality. It still requires documented reasoning, clear accountability and evidence that the selected approach is appropriate. 

From Authorisation to Resilient CASP Operations 

MiCA provides the framework for authorisation and the delivery of regulated crypto-asset services. DORA is fundamental to ensuring that those services can be delivered reliably, securely and under effective control. 

The MFSA’s observations from the 2025 authorisation cycle show that operational-resilience weaknesses are already being identified while firms seek authorisation. ESMA’s custody focused Common Supervisory Action demonstrates how scrutiny continues once a CASP is authorised. 

For prospective applicants, the stronger approach is to design MiCA and DORA into one coherent operating model. 

For authorised CASPs, the priority is to demonstrate that the model continues to operate effectively as the business, technology and risk environment evolve. 

How A2CO Supports MiCA and DORA Readiness 

A2CO supports firms across four connected areas. 

MiCA Authorisation and Regulatory Advisory 

Regulatory-perimeter analysis, licensing and authorisation support, governance arrangements, policies and procedures, and regulatory engagement, including MiCA regulation advisory. 

DORA Readiness and Assurance 

Gap assessments, ICT governance and risk-management reviews, incident-management readiness, continuity and recovery advisory, resilience-testing planning, oversight and remediation, delivered through our DORA compliance service. 

Custody and ICT Third-Party Risk Assessments 

Custody-control readiness reviews, outsourcing assessments, Register of Information readiness, concentration-risk assessment and exit planning. 

Ongoing Governance and Compliance Support 

Compliance, risk and information-security support, thematic reviews, remediation programmes, assurance and ongoing regulatory engagement.