CASP Digital Operational Resilience: ESMA’s Custody CSA

ByOfficer

On 8 July 2026 the European Securities and Markets Authority launched a Common Supervisory Action on crypto-asset service providers, aimed squarely at one activity: custody. The exercise assesses the maturity of CASP digital operational resilience frameworks for custody services, and national competent authorities will run it on a risk-based sample of authorised CASPs from the second half of 2026 through the first half of 2027. If your firm holds clients’ crypto-assets or the means of access to them, an NCA information request is now a realistic item on your 2026 workplan.

The timing is not accidental. The transitional period under the Markets in Crypto-Assets Regulation ended on 1 July 2026, so by the time the review starts, the population it targets is the set of firms that actually obtained authorisation. Those firms already carry direct obligations under the Digital Operational Resilience Act. What the CSA does is test whether the resilience frameworks on paper survive contact with the specific way custody works on a distributed ledger.

Related reading: our guide to DORA ICT incident reporting.

A coordinated review, not a new return

A Common Supervisory Action is a supervisory-convergence tool. ESMA sets the scope and methodology for the coordinated exercise, NCAs carry out the fieldwork, and the findings collected from NCAs are consolidated into a final report for ESMA’s Board of Supervisors after the exercise concludes in the second half of 2027. No new regulation is created by a CSA, and no new reporting form falls due because one has been announced.

That distinction matters for how you resource the response. The obligations the CSA measures already exist in DORA and MiCAR. The review asks an NCA to look at how you already meet requirements that have applied since DORA started to apply on 17 January 2025, not to add a data return. A firm that treats the announcement as a signal to build a new report has misread it. The right reading is that documentation which was theoretically reviewable is about to be reviewed in practice, on custody specifically, and a sample of firms will be asked to produce it.

ESMA has framed the CSA as a response to its risk-based supervisory priorities, which flag both digital operational resilience and CASPs as areas of concern. The convergence goal is explicit: the aim is a consistent supervisory approach across the Union in a market segment that is still forming.

The calendar that matters

Deadline pressure is the reason this topic is worth planning around now. The operative dates are short and easy to miss inside a busy authorisation year:

  • 1 July 2026: end of the MiCA transitional period. From this point the review population is authorised CASPs.
  • Second half of 2026: the CSA begins. NCAs select a risk-based sample and open the exercise.
  • Second half of 2026 to first half of 2027: the fieldwork window during which selected CASPs respond.
  • Second half of 2027: ESMA consolidates NCA findings into a final report to its Board of Supervisors.

These are the boundaries of a supervisory exercise, not filing deadlines in the COREP or transaction-reporting sense. The practical deadline for a custodial CASP is earlier and self-imposed: the point at which your resilience evidence for custody is assembled and defensible, which needs to be before your NCA calls rather than after.

Why custody, and why now

Custody concentrates the risk that DORA and MiCAR both worry about. Under MiCAR, providing custody and administration of crypto-assets on behalf of clients is a distinct regulated service with its own obligations in Article 75. A custodial CASP holds either the crypto-assets or, more often, the private keys that control them. A single failure in key management can lose client assets outright, and MiCAR treats that outcome as the custodian’s problem: Article 75(3) requires a custody policy whose purpose is to minimise the risk of loss of clients’ crypto-assets, the related rights, or the means of access, due to fraud, cyber threats or negligence.

MiCAR then attaches liability to the same failure. Article 75(8) makes a custodial CASP liable to its clients for the loss of any crypto-assets, or of the means of access, as a result of an incident attributable to the provider, with liability capped at the market value of the asset lost at the time of the loss. Recital 83 spells out what “incident” reaches: losses resulting from an ICT incident, including a cyber-attack, theft or malfunction. The carve-out is narrow. An incident is not attributable to the CASP only where it can show the event occurred independently of the service, such as a problem inherent in the operation of the distributed ledger that the CASP does not control. Everything inside the firm’s own control surface is on the firm.

There is also fresh supervisory evidence that ICT incidents are not hypothetical. On 3 June 2026 the European Supervisory Authorities published their first annual report on major ICT-related incidents under Article 22 of DORA, drawn from the incident reports financial entities filed with competent authorities during 2025. That report is the backdrop against which the custody CSA lands: supervisors now have a full year of incident data across the financial sector and a reason to test whether the newest category of financial entity, the authorised CASP, can withstand the same shocks. Our note on the ESAs 2025 major incident report covers what that data showed.

CASP digital operational resilience: governance, key management and DORA Chapter II controls

Three of the CSA’s stated review areas map onto the first pillar of DORA: governance arrangements, key and storage management, and transaction controls. DORA Chapter II sets the ICT risk management framework. Article 5 places ultimate responsibility for ICT risk on the management body and requires it to define, approve and oversee the framework. Article 6 requires the framework itself, documented and reviewed. For a custodial CASP, the management-body ownership point is not a formality: the body that signs off the ICT risk framework is signing off the arrangement that stands behind the Article 75(8) liability.

Key and storage management is where custody diverges from a generic financial entity. DORA’s language is deliberately technology-neutral. It requires policies to maintain the availability, authenticity, integrity and confidentiality of data, and it requires the controls to be proportionate, but it does not tell a custodian how many signers a cold wallet needs or how private-key material should be sharded. MiCAR fills part of that gap by requiring the Article 75 custody policy and by requiring, in Article 75(7), that clients’ crypto-assets be segregated from the CASP’s own holdings both on the ledger and legally, so that the provider’s creditors have no recourse to them in insolvency, and operationally as well. An NCA reviewing key management will look at where the custody policy and the ICT risk framework meet, and whether the segregation the CASP describes is the segregation its systems actually enforce.

Transaction controls are the third strand. On a distributed ledger a mistaken or malicious transfer is generally irreversible, which raises the cost of a weak authorisation workflow well above the equivalent in a traditional book-entry system. The point a reviewer tends to probe is the gap between the documented four-eyes approval and the production reality, where a single compromised operator credential or a mis-configured signing service can move client assets. Article 75(2) requires CASPs to record any movements following client instructions in the register of positions as soon as possible, and to ensure that any movement affecting the registration of the crypto-assets is evidenced by a regularly registered transaction. Article 75(4) separately requires any event likely to create or modify client rights to be recorded immediately, so the audit trail behind custody movements is itself a regulated artifact.

Incident detection, response, and what DORA already requires you to report

“Incident detection and response” is one of the CSA’s named areas, and here the supervisory expectation is concrete because DORA Chapter III already prescribes it. Article 18 sets the criteria for classifying an ICT-related incident, with the materiality thresholds fixed in Commission Delegated Regulation (EU) 2024/1772. Article 19 then requires financial entities to report a major ICT-related incident to their competent authority through a sequence of submissions, and Commission Delegated Regulation (EU) 2025/301 sets the content and the time limits.

Those time limits are tight, and a custodial CASP should know them cold before a reviewer asks:

  • Initial notification: as soon as possible within four hours of classifying the incident as major, and no later than 24 hours from when the entity became aware of it.
  • Intermediate report: within 72 hours of the initial notification.
  • Final report: when the root-cause analysis has been completed, and no later than one month after the intermediate report or, where applicable, the latest updated intermediate report.

The forms and procedures sit in Commission Implementing Regulation (EU) 2025/302. What a reviewer wants to see is not just the runbook but evidence that detection actually triggers the clock: monitoring that would surface a key-management compromise or an anomalous transfer, a classification decision that maps to the Article 18 criteria, and a reporting path that hits the four-hour and 72-hour marks. A response plan that has never been exercised against a custody-specific scenario is the weak point the CSA is designed to find.

Smart-contract risk and the third-party chain

The last two review areas, smart contract risks and dependencies on third-party providers, are the ones DORA addresses least directly and where custodial CASPs carry the most unbudgeted exposure. Smart-contract risk barely appears in DORA’s text, because DORA was written for the financial sector at large rather than for on-chain execution. A custodian that stakes client assets, interacts with a bridge, or relies on a token contract to reflect balances is exposed to code it did not write and cannot patch. The CSA’s inclusion of smart-contract risk signals that supervisors expect this to be governed inside the ICT risk framework even though no article names it.

Third-party dependency is where DORA is precise. Chapter V requires financial entities to manage ICT third-party risk as part of the ICT risk framework, and Article 28(1) makes the point that firms most often underestimate: a financial entity that uses ICT services remains, at all times, fully responsible for compliance with its obligations. Outsourcing the wallet infrastructure does not outsource the accountability. Article 28(3) requires a register of information covering all contractual arrangements for ICT services, maintained at entity and group level, distinguishing services that support critical or important functions from those that do not, with a report to the competent authority at least yearly. Article 30 fixes the contractual provisions those arrangements must contain. The register of information is a likely NCA request because it is maintained using standard templates and shows how much of the custody stack the CASP has placed with ICT third-party providers.

Where teams get this wrong is the assumption that a sub-custodian or key-management vendor absorbs the resilience obligation. MiCAR closes that door twice. Article 73 provides that a CASP outsourcing operational functions remains fully responsible for its obligations and that outsourcing does not delegate its responsibility. And when the transitional period ended, ESMA reminded the market that MiCAR prohibits CASPs from outsourcing or delegating certain services, in particular custody, to entities that are not themselves authorised as CASPs. The third-party chain for custody is therefore both mandatory to document under DORA and constrained in who may sit in it under MiCAR. Our DORA register of information guide walks through the schema in detail.

Where DORA stops and DLT begins

The most useful way to read this CSA is as a probe of the space between a technology-neutral rulebook and a very specific technology. A CASP can be entirely conformant with DORA’s articles and still fail the review, because DORA tells a firm to manage ICT risk without telling a custodian how to run a signing ceremony, rotate keys, or assess a smart contract before it touches client assets. MiCAR narrows the gap for custody through Article 75 and through Article 68, which requires CASPs to hold the ICT systems, response and recovery plans, and data-safeguarding mechanisms that DORA prescribes, in particular the response and recovery plans set up under Articles 11 and 12 of DORA. Even together, the two texts leave the DLT-specific control design to the firm.

That is the design intent of a maturity assessment. The CSA asks whether the policy reaches the parts of custody that are unique to ledgers, not merely whether a CASP has a policy. A firm whose gap analysis stops at DORA article numbers, without translating each requirement into a wallet-architecture control, is the firm the exercise is built to surface. The translation work, from generic ICT requirement to concrete custody control, is the substance of being review-ready.

How to get review-ready

Preparation for this CSA is document assembly plus honest self-assessment, and the artifacts are already named in the two regulations. A custodial CASP that wants to respond without a scramble should have the following in a state it would show an NCA:

  • The ICT risk management framework and its most recent review report under DORA Article 6, with the management-body approval trail from Article 5 attached.
  • The MiCAR Article 75 custody policy, reconciled against the ICT risk framework so that key management, storage and segregation are described the same way in both.
  • The incident classification and reporting runbook, mapped to the Article 18 criteria and the Article 19 timelines, with evidence it has been exercised on a custody scenario.
  • The register of information under DORA Article 28(3), current and reconciled to the actual vendor stack, with the critical-or-important functions flagged.
  • Digital operational resilience testing evidence under DORA Articles 24 and 25, showing the custody systems were in scope.

The reconciliation between the custody policy and the ICT risk framework is the step firms skip and reviewers notice. The two documents are often written by different teams at different times, and when they describe segregation or key custody differently, the inconsistency reads as a control that exists on paper in two incompatible versions. Aligning them before the review is cheaper than explaining the mismatch during it. For firms still working through the broader MiCAR obligation set, our overview of MiCAR reporting obligations sets the wider context.

Scope limits worth confirming

Three assumptions about this exercise are worth correcting before they shape a response.

NCAs conduct the fieldwork under their own supervisory powers, and the output is a convergence report to ESMA’s Board of Supervisors, not a set of ESMA-level enforcement decisions. Individual supervisory follow-up, where it happens, comes from the national authority against a firm in its sample.

The sample is risk-based, so an NCA can pull in a smaller CASP whose custody model or client base raises its risk profile. Size is one input to selection, not a floor beneath it, and the exercise reaches well past the largest custodians.

Proportionality still applies: DORA Article 4 scales the framework to a firm’s size and risk profile, and a CASP that is a microenterprise, meaning fewer than 10 staff and turnover or balance sheet at or below EUR 2 million, faces a lighter application of some chapters. That proportionality changes only the depth expected of the controls, leaving the requirement to have them, and the custody liability under MiCAR Article 75(8), fully in force. A custodial CASP also falls outside the entities that DORA Article 16(1) allows to run the simplified ICT risk management framework, so a CASP above the microenterprise line applies the full framework.

Frequently Asked Questions

Does the CSA create a new reporting obligation for CASPs?

No. A Common Supervisory Action is a convergence exercise, not a rule. It measures compliance with obligations that already exist under DORA and MiCAR. Selected CASPs will respond to an NCA information request during the 2026 to 2027 window, but no new periodic return is introduced by the announcement.

Which CASPs are in scope of the review?

Authorised CASPs providing custody and administration of crypto-assets on behalf of clients, selected by their NCA on a risk-based sample. Because the MiCA transitional period ended on 1 July 2026, the population is firms that have obtained MiCAR authorisation. There is no published list; selection sits with each national authority.

How does DORA apply to a CASP in the first place?

DORA (Regulation (EU) 2022/2554) lists crypto-asset service providers authorised under MiCAR among the financial entities in its scope, so a CASP is directly subject to DORA’s ICT risk management, incident reporting, testing and third-party requirements. MiCAR Article 68 reinforces this by requiring CASPs to hold the ICT systems and response and recovery plans that DORA prescribes.

What are the DORA incident reporting deadlines a custodian must meet?

For a major ICT-related incident: an initial notification within four hours of classifying the incident as major and no later than 24 hours from becoming aware of it; an intermediate report within 72 hours of the initial notification; and a final report when the root-cause analysis has been completed, no later than one month after the intermediate report or, where applicable, the latest updated intermediate report. The criteria for classification sit in Delegated Regulation (EU) 2024/1772 and the report content and timing in Delegated Regulation (EU) 2025/301.

Can we rely on our wallet or key-management vendor to carry the resilience obligation?

No. DORA Article 28(1) keeps the financial entity fully responsible for its obligations regardless of outsourcing, and MiCAR Article 73 provides that outsourcing does not delegate a CASP’s responsibility. MiCAR also prohibits delegating custody itself to an entity that is not an authorised CASP. The vendor relationship must be captured in the DORA Article 28(3) register of information.

Who is liable if client crypto-assets are lost in a cyber-attack?

MiCAR Article 75(8) makes a custodial CASP liable to its clients for the loss of crypto-assets or the means of access resulting from an incident attributable to the provider, capped at the market value of the asset at the time of the loss. An incident is only outside that liability where the CASP can show it occurred independently of the service, such as a problem inherent in the ledger itself that the provider does not control.

Does being a microenterprise exempt a CASP from the review?

No. Proportionality under DORA Article 4 adjusts how deeply the requirements apply to a small firm, but it does not remove them, and the risk-based sample can still include a smaller custodian. Microenterprise status does not affect custody liability under MiCAR Article 75(8).

Related Articles

Key Takeaways

  • ESMA launched a Common Supervisory Action on CASP custody resilience on 8 July 2026; NCAs run it on a risk-based sample from H2 2026 to H1 2027, with a report to the Board of Supervisors in H2 2027.
  • The CSA adds no new return. It tests compliance with existing DORA and MiCAR obligations, applied to custody specifically.
  • The six review areas map to DORA pillars: governance, key management and transaction controls to Chapter II; incident detection and response to Chapter III; third-party dependencies to Chapter V. Smart-contract risk sits inside the ICT risk framework even though no article names it.
  • MiCAR Article 75(3) requires a custody policy to minimise loss from fraud, cyber threats or negligence, and Article 75(8) makes the custodian liable for losses from an attributable incident, capped at market value.
  • DORA incident reporting runs to strict clocks: initial notification within four hours of major classification and no later than 24 hours from awareness; intermediate report within 72 hours of the initial notification; final report when root-cause analysis is complete and no later than one month after the intermediate report or, where applicable, the latest updated intermediate report.
  • Outsourcing does not move the obligation: DORA Article 28(1) and MiCAR Article 73 keep the CASP responsible, and custody may only be delegated to another authorised CASP.
  • Get review-ready by reconciling the MiCAR custody policy with the DORA ICT risk framework and by having the register of information, incident runbook and testing evidence current and consistent.

Sources and References

  • ESMA, “ESMA launches Common Supervisory Action on CASPs’ digital operational resilience for custody” (8 July 2026): esma.europa.eu
  • Regulation (EU) 2022/2554 (Digital Operational Resilience Act, DORA), OJ L 333, 27.12.2022: EUR-Lex
  • Regulation (EU) 2023/1114 (Markets in Crypto-Assets Regulation, MiCAR), OJ L 150, 9.6.2023: EUR-Lex
  • Commission Delegated Regulation (EU) 2024/1772 (RTS on classification of ICT-related incidents and cyber threats), OJ L, 2024/1772, 25.6.2024: EUR-Lex
  • Commission Delegated Regulation (EU) 2025/301 (RTS on content and time limits for major ICT-related incident reports), OJ L, 2025/301, 20.2.2025: EUR-Lex
  • Commission Implementing Regulation (EU) 2025/302 (ITS on forms, templates and procedures for reporting major ICT-related incidents), OJ L, 2025/302, 20.2.2025: EUR-Lex
  • Commission Implementing Regulation (EU) 2024/2956 (ITS on standard templates for the register of information), OJ L, 2024/2956, 2.12.2024: EUR-Lex
  • Joint ESAs, “2025 Report on major ICT-related incidents” (JC 2026 16, 3 June 2026): eba.europa.eu (PDF)
  • ESMA Public Statement ESMA75-113276571-1710, “ESMA calls on unauthorised crypto-asset service providers to wind down orderly … as MiCA transitional period ends” (23 June 2026): PDF

Custody puts digital operational resilience to the test

Every other financial entity manages ICT risk to protect a service. A crypto custodian manages it to protect the assets themselves, because the key is the asset and a lost key is a lost holding with a market-value liability attached. That is why ESMA picked custody, and why the maturity question the CSA asks is sharper than a compliance checklist. The firms that come through the review well will be the ones that treated their DORA articles and their MiCAR custody policy as one control set for one job, rather than two documents owned by two teams. The review is a rehearsal. The real test is the incident that has not happened yet.

Last updated: July 2026

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts