Operational resilience under DORA for MiCA-authorised crypto-asset service providers

Live law

Regulation (EU) 2022/2554 has applied since 17 January 2025, and crypto-asset service providers authorised under MiCA are within its list of financial entities, alongside banks, payment institutions and investment firms. The architecture rests on five pillars: a documented ICT risk-management framework with explicit management-body responsibility; harmonised classification of ICT-related incidents and reporting of the major ones; digital operational resilience testing proportionate to the entity's size and risk profile; management of ICT third-party risk, including mandatory contractual provisions and a register of information covering all ICT contractual arrangements; and voluntary threat-intelligence sharing. The register is not a one-off: the ESAs began collecting registers of information through national authorities in April 2025, and the ESAs designate critical ICT third-party providers for direct EU-level oversight. All of this applies to an authorised CASP today.

Why the third-party pillar lands hardest on CASPs

Banks outsource heavily too: the ECB's 2025 analysis of supervised banks' outsourcing registers reports that nearly all have cloud contracts for critical functions and that most externally outsourced critical functions would be difficult to substitute. The difference for a typical CASP is the base it starts from. The production stack itself is bought in, cloud infrastructure, blockchain node and RPC access, custody technology, wallet infrastructure, screening tools and market-data feeds, often from a small set of providers that the whole industry shares, with no legacy core of the firm's own around it. ESMA's supervisory briefing on CASP authorisation treats outsourcing of key functions and of ICT infrastructure as grounds for elevated scrutiny and directs national authorities to DORA when they evaluate it.

Under DORA's third-party pillar that has three consequences. The register of information becomes, in effect, a map of the entire business, and its first complete compilation shows how many single points of failure the business contains. Contract remediation follows: DORA prescribes minimum contractual content for every ICT service arrangement, covering the service description, data location and protection, data return on insolvency or termination, service level descriptions, incident assistance, cooperation with authorities and termination rights, and a second tier for services supporting critical or important functions, adding full quantitative service levels, access, inspection and audit rights, contingency testing and exit provisions; exit strategies are required for that second tier. Much of the crypto vendor market still papers relationships on start-up terms that do not meet it. Concentration analysis becomes concrete when your custody technology, your node access and your cloud all resolve to dependencies that could fail together. Where a provider is designated as critical at EU level, the oversight lands on the provider, but the practical effect reaches you through repapered contracts and shifted terms.

Proportionality within the framework

DORA scales. The framework, the testing programme and the documentation are expressly calibrated to size, risk profile and the criticality of the functions supported, and a ten-person CASP is not expected to run a global bank's resilience programme. The regulation also excuses microenterprises, fewer than ten staff and no more than EUR 2 million in turnover or balance sheet total, from specific duties: the comprehensive testing programme and its annual minimum, threat-led penetration testing, cyber-attack scenarios in continuity testing and the aggregation of recurring incidents, while still requiring risk-based testing and the rest of the framework. Beyond that, proportionality is an argument you make inside the framework. The board still owns ICT risk; every incident is recorded and classified, and the major ones, those affecting critical services and crossing the materiality thresholds in the Commission's classification standard, are reported on that standard's deadlines; the register still exists and is still collected. In supervisory practice, a proportionate programme with gaps draws a finding; a missing one is a licensing problem, and for applicants ESMA directs national authorities to DORA when they evaluate ICT outsourcing in the authorisation assessment.

The worklist

Five items cover most of the ground. Build the register of information as a maintained process with an owner, kept current between deadlines. Run contract remediation against DORA's mandatory clauses, starting with the vendors supporting critical functions, and accept that some crypto vendors will need to be pushed or replaced. Write the incident procedure: every incident recorded; classification against the criteria and materiality thresholds of Delegated Regulation (EU) 2024/1772, which decide whether an incident is major; for major incidents, the deadlines in Delegated Regulation (EU) 2025/301, an initial notification within four hours of classification and no later than 24 hours after becoming aware, an intermediate report within 72 hours, a final report within a month; internal escalation, and a communication line to the supervisor that has been tested once before it is needed.

Set a testing calendar proportionate to your profile, with the statutory floor built in: unless you are a microenterprise, every ICT system supporting a critical or important function is tested at least yearly, and document why the rest of the calendar is proportionate. And prepare exit strategies for the dependencies you cannot afford to lose, because a cloud migration is a plan only once it has steps, owners and a tested backup.

A Swiss note for groups: Switzerland has no directly equivalent, generally applicable resilience act (FINMA Circular 2023/1 on operational risks and resilience imposes resilience requirements on banks and the other FINMA-supervised institutions within its scope), so the EU entities of a Swiss group carry DORA on their own, and group ICT arrangements that route through the Swiss parent belong in the EU entity's register and contracts.

What this means for you

• Applicants: budget DORA into the licence. Operational-resilience readiness is part of the authorisation conversation, and retrofitting is costlier than building it in.
• Compile the register completely, then repaper the critical vendors. The register will show your concentration risk, and you should see it before the supervisor does; access, audit, exit and service-level clauses to DORA standard follow, starting where failure hurts most.
• Test the incident chain once. A dry run of classification, escalation and reporting finds the gaps a policy document hides.
• Make proportionality a documented argument. Size calibrates the programme, and only a microenterprise is excused from specific duties; write down why your programme fits your risk.

Isak Legal advises crypto-asset service providers and fintechs on DORA readiness, ICT contract remediation and the interaction of MiCA, AML and resilience obligations in one programme. See our Digital Assets and Financial Regulation pages, or get in touch.

This client update is provided for general information only, reflects the position as at 26 September 2026 and does not constitute legal advice or create a lawyer-client relationship. Technical standards and supervisory expectations under DORA continue to develop; verify the current texts at the official sources linked above before acting. For advice on a specific matter, please contact us.