ESMA's 2026 Custody Resilience CSA and the Rules That Actually Bind

Summary

The CSA is a supervisory-convergence exercise. ESMA coordinates the work, while national competent authorities examine a risk-based sample of CASPs.

The controlling requirements arise principally from MiCA Articles 68, 73, 74 and 75, DORA, and the related delegated regulations. These rules cover management-body responsibility, custody policies, continuity, ICT controls, incident handling, recordkeeping, outsourcing and third-party risk.

The management body retains ultimate responsibility for custody and ICT risk. Outsourcing does not transfer that responsibility. A CASP must prove that named decision-makers approve the custody design, receive material risk information, challenge deficiencies, and track remediation. Written policies alone do not establish that controls operate.

MiCA does not prescribe one wallet or key-storage architecture. The CASP must justify its chosen design and prove effective key generation, storage, use, backup, recovery, revocation, access control and segregation. The legal test concerns the protection of client assets and means of access, not whether the firm uses a particular commercial product.

“Transaction controls” are not exhaustively defined in the CSA announcement. Binding recordkeeping, access-control and logging rules nevertheless require traceability from an authenticated client instruction through signing, broadcast, settlement and the client position register. Controls involving approvals, limits, address validation and reconciliation are defensible supervisory expectations when proportionate to the custody model.

An ICT incident can trigger DORA classification and reporting, MiCA continuity duties, client communications and separate liability analysis under MiCA Article 75(8). DORA reporting does not determine whether the incident is attributable to the CASP. Article 75 requires the CASP to demonstrate that an excluded event occurred independently of its services and operations.

Smart-contract exposure is now an express factor in the MiCA continuity self-assessment. Control, selection, deployment, upgrade rights, administrative keys and operational integration will affect whether a contract failure is connected to the CASP’s operations. A protocol-level defect outside the CASP’s control presents a stronger independence argument than a defect in a contract that the CASP selected, configured or maintained.

Third-party classification must follow operational substance. A technology supplier is not automatically a sub-custodian. A provider that safeguards or controls client assets or the means of access may fall within MiCA Article 75(9), which permits sub-custody only through another CASP authorised under Article 59. DORA and MiCA Article 73 remain relevant even where the provider is not a sub-custodian.

Legal status and scope of the CSA

ESMA announced the CSA on 8 July 2026. National competent authorities will examine a risk-based sample of CASPs during the second half of 2026 and the first half of 2027. ESMA expects to present a consolidated report to its Board of Supervisors during the second half of 2027. The announced topics include governance arrangements, key and storage management, transaction controls, incident detection and response, smart-contract risks and third-party dependencies. (ESMA)

The exercise is best characterised as a supervisory-convergence instrument under Article 29 of Regulation (EU) No 1095/2010. That provision authorises ESMA to promote a common supervisory culture, methods and practices. It does not allow a press announcement or CSA questionnaire to amend a directly applicable regulation. The CSA can standardise how authorities gather evidence and compare firms. It cannot replace the statutory elements of an infringement.

A control finding therefore requires two analytical steps. The authority must first establish what the CASP’s architecture and operating record show. It must then connect that evidence to MiCA, DORA, an applicable delegated regulation, or a lawful national measure. A maturity rating may support prioritisation or remediation. It is not, without that legal connection, a free-standing breach.

MiCA’s maximum transitional period for pre-existing providers expired no later than 1 July 2026. ESMA launched the CSA one week later. The sampled population should therefore consist of firms operating under the MiCA permission structure rather than the maximum Article 143 grandfathering period. ESMA’s public announcement does not identify the sampled firms or publish a detailed questionnaire, scoring method or firm-level timetable.

The same custody duties can apply where a financial entity provides the service through Article 60 rather than a standalone Article 63 authorisation. Article 60(10) lists the provisions from which those entities are exempt. Articles 68 and 75 are not among the listed exemptions. A bank, investment firm or other Article 60 entity should not assume that its existing sectoral status removes the MiCA custody requirements.

The supervisory test concerns operating effectiveness

MiCA Article 68 requires sufficiently effective policies and procedures. It also requires the management body to assess their effectiveness periodically and address deficiencies. DORA requires a documented ICT risk-management system, periodic review, internal audit and formal remediation. The applicable MiCA recordkeeping regulation requires records of relevant policies, management-body reviews, identified deficiencies and corrective action.

These provisions support an effectiveness test with four distinct elements:

1. Design: the control addresses the identified custody risk.
2. Implementation: systems, roles, permissions and contracts reflect the approved design.
3. Operation: records show that the control operated during the period examined.
4. Correction: testing and incidents produce tracked, timely remediation.

A policy may establish the first element. It cannot, by itself, establish the remaining three. A CASP should expect transaction sampling, access-log review, incident reconstruction, wallet walkthroughs, vendor-file review and inspection of management-body decisions.

Evidence should be internally consistent. The custody policy, wallet diagram, asset register, key inventory, DORA information register, client disclosures and business-continuity plan should describe the same operating model. Material inconsistencies can indicate that the board-approved model does not match production.

Management-body responsibility and internal control

MiCA Article 68 requires suitable knowledge, skills and experience within the management body. It requires clear organisational arrangements, competent staff and periodic review of the firm’s policies. DORA places ultimate responsibility for ICT risk on the management body. That responsibility includes risk tolerance, continuity plans, recovery arrangements, audit resources, third-party policy and relevant budgets.

The CSA is therefore likely to examine who makes each material custody decision. Relevant decisions include:

• approval of the wallet and signing architecture;
• acceptance of hot-wallet and counterparty exposure;
• selection of a cloud, MPC, HSM, node or wallet provider;
• approval of smart-contract deployment or integration;
• authority to pause withdrawals or disable a signing path;
• acceptance of unresolved vulnerabilities;
• classification of major ICT incidents;
• approval of recovery, compensation or client-return actions.

The firm should be able to identify the decision-maker, the information presented, the challenge recorded and the final decision. A responsibility matrix without board papers, minutes or escalation evidence will carry limited weight.

The board need not perform the work of cryptographers or infrastructure engineers. It must possess enough collective knowledge to challenge the control owners. Board reporting should convert technical events into decision-relevant information: assets exposed, key paths affected, clients affected, recovery progress, provider dependency, control exceptions and unresolved risk.

ESMA’s 2025 supervisory briefing on CASP authorisation is nonbinding. It nevertheless indicates how authorities may approach these questions. The briefing states that internal control should remain within the CASP, even when functions are outsourced. It also identifies key management and other highly important outsourced functions as matters requiring close scrutiny. It expects the management body to possess sufficient technical knowledge.

Material warning signs include a board that receives only availability statistics, no named owner for custody risk, unresolved audit findings without deadlines, vendor decisions made outside the approved process, and emergency powers that have never been exercised or tested.

Key and storage management

MiCA Article 75 regulates custody at the service and client-protection level. It requires a custody agreement, client-by-client position records, evidence of asset movements, a custody policy, security arrangements, prompt return, and legal and operational segregation. The custody policy must reduce the risk of loss arising from fraud, cyber threats and negligence.

DORA and its delegated regulations regulate the related ICT controls. Commission Delegated Regulation (EU) 2024/1774 addresses the lifecycle of cryptographic keys, including generation, renewal, storage, backup, archival, retrieval, transmission, retirement, revocation and destruction. It also requires protection against loss, unauthorised access, disclosure and modification, with replacement following compromise or damage. That regulation is framed through encryption and cryptographic controls. MiCA Article 75 independently and expressly covers the means of access to client crypto-assets.

Commission Delegated Regulation (EU) 2025/299 makes private-key security part of the CASP’s continuity self-assessment. Its annex refers to the methods used to secure private keys or other means of access, including software wallets, hardware wallets and arrangements involving more than one fiduciary. It also directs attention to outsourcing, DLT infrastructure, nodes, smart contracts and the value of assets held in custody.

No cited provision requires every CASP to use cold storage, an HSM, MPC, multisignature wallets or one fixed quorum. The CASP must justify the architecture against its asset values, transaction volumes, supported networks, client profile, geographic exposure and recovery needs.

A defensible key-control record should cover:

• the complete inventory of production, backup, recovery and administrative keys;
• ownership and control of each key or key share;
• generation methods and ceremony records;
• approved wallet tiers and exposure limits;
• signing quorum and segregation of duties;
• privileged, emergency and vendor access;
• backup location and protection;
• recovery, rotation, revocation and destruction procedures;
• test results for key loss, shard loss and site failure;
• monitoring and tamper-resistant access logs;
• wallet creation, migration and retirement;
• the connection between each blockchain address and the client position register.

A CASP using MPC should not treat the absence of a single complete private key as the end of the analysis. Supervisors should examine who controls each share, who can change signing policy, whether a provider can substitute participants, and whether administrative credentials can alter the quorum. The same analysis applies to account-abstraction wallets and smart-contract wallets.

Operational segregation requires more than accounting labels. The firm should demonstrate separation between client and proprietary assets, controlled use of omnibus wallets, client-level entitlement records, and reconciliation between on-chain balances and the internal register. Legal segregation remains partly dependent on applicable Member State property and insolvency law. A CASP should hold a current legal analysis explaining how its records and contractual arrangements protect client ownership if the firm or a provider fails.

Material deficiencies include undocumented seed copies, shared privileged credentials, one-person signing authority, unreconciled balances, untested recovery material, provider access that is absent from the custody policy, and backup arrangements that cannot meet the approved recovery objective.

Transaction controls and audit trail

The CSA announcement does not define “transaction controls.” For custody-resilience purposes, the term should cover instruction intake, client authentication, authorisation, transaction construction, signing, broadcast, confirmation, reconciliation and record retention. AML, sanctions and transfer-of-funds controls may overlap, but they are outside the present scope unless the NCA’s questionnaire states otherwise.

MiCA requires a register of each client’s positions and records of movements made under the client’s instructions. Commission Delegated Regulation (EU) 2025/1140 requires records that allow an authority to reconstruct key stages of activity. Records must reveal amendments and resist unauthorised alteration. On-chain records include transaction hashes, originating and destination wallet addresses, smart-contract addresses, timestamps, fees and links to related off-chain records.

DORA’s access-control and logging rules add requirements for unique identities, controlled account lifecycles, least privilege, emergency access, segregation of duties and protected logs. Logged events should cover access, configuration changes, system operations and network activity, with synchronised timestamps.

These rules support an end-to-end transaction evidence chain:

• Client instruction. The CASP records the authenticated request, the authorised account, the destination and the instruction time.
• Policy decision. The CASP records the limits, approvals, holds or exceptions applied to the request.
• Transaction construction. The CASP records the network, asset, amount, destination, fee parameters and smart-contract call data.
• Signing. The CASP records the policy, quorum, signing components and privileged actions.
• Broadcast and finality. The CASP records the transaction hash, broadcast status, confirmation status and any reorganisation or replacement.
• Internal accounting. The CASP connects the on-chain result to the client position and reconciles aggregate client entitlements to controlled assets.

A reasonable supervisory inference is that higher-risk custody models should use preventive controls before broadcast. These may include dual approval, destination allowlists, transaction simulation, velocity limits, value thresholds, network and asset validation, anomalous-instruction alerts and delayed execution for defined risk events. These controls are not universally prescribed. The CASP should document why each control is present, absent or calibrated at its chosen level.

Blockchains generally do not provide a conventional rollback function. A signing or destination error may therefore become irreversible at broadcast or confirmation. This feature gives added legal weight to pre-signing authentication, segregation of duties and transaction validation.

Testing should include ordinary withdrawals and adverse cases. Relevant cases include an invalid address, wrong network, replaced transaction, fee spike, chain reorganisation, smart-contract revert, duplicated instruction, stale allowlist entry and privileged override. The test result should connect the control response to the recorded client position.

Incident detection, response and reporting

DORA requires a process to detect, manage and notify ICT-related incidents. The CASP must record incidents, classify them, perform root-cause analysis, allocate response roles, preserve evidence, escalate internally and track resolution. Major incidents must be reported to the competent authority.

Commission Delegated Regulation (EU) 2025/301 establishes the reporting timetable. The initial report must be submitted as early as possible, no later than four hours after classification as major, and no later than 24 hours after awareness of the incident. The intermediate report is due within 72 hours of the initial report. The final report is due within one month after the intermediate report or the latest updated intermediate report.

The DORA classification rules consider affected clients and transactions, reputational impact, duration and downtime, geographic spread, data loss, critical-service impact and economic impact. A major classification generally requires an effect on critical services together with the applicable qualitative or quantitative thresholds. Recurrent incidents may require aggregated assessment.

MiCA continuity rules operate alongside DORA. Commission Delegated Regulation (EU) 2025/299 requires escalation arrangements, defined roles, recovery objectives, backup arrangements, client and authority communications, realistic testing and written test results. It also requires procedures for failures affecting outsourced critical or important functions. Where a disruption involves a permissionless distributed ledger, it further requires the CASP to communicate when services are expected to resume, the reasons for and the impact of the incident, any risks to client funds and crypto-assets, and the measures it intends to take, on a best-effort basis where that information is not readily available.

A single event can therefore produce four separate legal workstreams:

1. DORA classification and reporting.
2. Service continuity, recovery and client communication.
3. MiCA Article 75(8) attribution and client-loss analysis.
4. Third-party contractual, escalation and exit action.

These workstreams answer different questions. A DORA major incident may cause no loss of client crypto-assets. A smaller incident may cause an attributable asset loss. Timely regulatory reporting does not establish that the CASP avoided liability. Late reporting does not, by itself, prove that the underlying asset loss was attributable.

Under MiCA Article 75(8), the custodian is liable for loss of crypto-assets or means of access resulting from an incident attributable to it. Liability is capped at the market value of the lost asset when the loss occurred. The Article identifies events occurring independently of the custody service or CASP operations as non-attributable and places a specific demonstration requirement on the CASP. It gives a defect inherent in the operation of a DLT outside the CASP’s control as an illustration. National procedural law will govern the mechanics of a private claim.

“Attributable” is not accompanied by an exhaustive statutory test. Relevant facts should include:

• whether the CASP selected, deployed or configured the failed component;
• whether it controlled keys, privileges or upgrade rights;
• whether the event was detected within approved thresholds;
• whether known vulnerabilities were accepted or left unresolved;
• whether the CASP monitored the provider or protocol;
• whether recovery arrangements operated;
• whether outsourced functions complied with the approved custody policy;
• whether delayed response increased the loss;
• whether the event would have occurred despite compliant controls.

The statutory independence example should be read narrowly. A consensus defect affecting a public DLT is closer to an inherent network event. A bug in an application-layer smart contract selected or deployed by the CASP is more closely connected to its services. A third-party failure is not automatically independent because MiCA Article 73 preserves the CASP’s responsibility for outsourced functions.

A CASP should maintain an attribution file for each loss event. It should contain the incident timeline, blockchain evidence, system and access logs, affected keys and wallets, provider evidence, control status, response decisions, client impact, loss calculation and reasoned legal position. The file should distinguish the root cause from factors that increased the duration or amount of loss.

Smart-contract risk

MiCA does not create a separate general smart-contract liability rule for custodians. Smart contracts enter the binding analysis through the continuity self-assessment, DORA’s software and change-management controls, MiCA custody duties and Article 75 attribution. Commission Delegated Regulation (EU) 2025/299 expressly identifies the number and type of smart contracts deployed and maintained by the CASP as a complexity factor.

A CASP should classify each material contract by its actual relationship to the service:

• an immutable external protocol that the CASP does not control;
• an external contract selected and integrated into the custody service;
• a contract deployed or maintained by the CASP;
• an upgradeable contract controlled through CASP or vendor administrative keys;
• a wallet contract that defines signing, recovery or spending policy.

The classification affects both control expectations and attribution. A CASP-deployed contract should be subject to approved development, testing, deployment and change procedures. An external contract still requires a reasoned selection, dependency and monitoring decision when client assets depend on it. DORA’s delegated ICT controls require testing before use and following relevant maintenance or change.

Relevant evidence includes the contract inventory, source-code and bytecode mapping, ownership, upgrade and pause rights, administrative-key holders, test and review records, deployment approval, dependency mapping, monitoring, incident triggers and client exposure. Dependencies may include libraries, proxies, oracles, bridges, relayers and sequencers.

No cited rule compels formal verification or a third-party code audit in every case. Their absence may still require justification where the contract controls material client assets or forms part of the signing path. The CASP may use other evidence, including independent review, constrained functionality, staged exposure, transaction simulation, monitoring, value limits and tested emergency procedures.

Administrative keys deserve separate treatment. A contract described as decentralised may remain operationally controlled through upgrade, pause, recovery or role-management keys. Those keys can be means of access under MiCA and should appear in the key inventory, privileged-access process and incident plan.

A smart-contract failure should not be classified automatically as an inherent DLT defect. The contract may operate on the DLT without being part of the DLT’s consensus or base protocol. Selection, deployment, configuration, upgrade control and monitoring will determine how closely the event relates to the CASP’s services and operations.

Third-party dependencies and the sub-custody boundary

MiCA Article 73 permits outsourcing subject to strict conditions. The CASP remains fully responsible for its obligations. Outsourcing may not alter the relationship with clients, change the conditions of authorisation or prevent effective supervision. The CASP must retain expertise and resources, preserve access to relevant information and permit authority access.

DORA treats ICT third-party risk as part of the CASP’s own ICT risk. It requires a register of contractual arrangements, pre-contract risk assessment, due diligence, monitoring, contract controls, concentration assessment and tested exit arrangements. The financial entity remains fully responsible.

Contracts supporting critical or important functions must address service descriptions, subcontracting, data and service locations, availability, integrity, confidentiality, recovery and return of data, incident assistance, cooperation with authorities, service levels, audit and access rights, testing and termination.

The delegated third-party rules extend the analysis to intra-group providers and subcontracting chains. Due diligence must consider operational, legal, ICT, data-location and concentration risks. Where subcontracting supports critical or important functions, Commission Delegated Regulation (EU) 2025/532 requires the CASP to assess subcontractor location, chain complexity, authorisation, oversight, data access, service transferability and continuity.

MiCA Article 75(9) creates a stricter rule for actual sub-custody. A CASP may use another provider of custody and administration only where that provider is authorised under Article 59. The client must be informed.

The classification should examine technical and operational power:

• Pure ICT support. A cloud provider, node service, monitoring provider or wallet-software supplier may be an ICT provider without being a sub-custodian. This is more likely where it cannot safeguard or control client assets or means of access.
• Key-management dependency. An HSM, MPC or wallet provider that holds a key share, changes signing policy or administers recovery presents a closer question. The result depends on whether it exercises practical control over access, alone or jointly.
• Actual custody. A provider that holds client assets, controls sufficient signing material, operates the operative wallet, or can effect transfers under the service design may itself be providing custody and administration. Article 75(9) then becomes material.

The classification should be documented before onboarding and revisited after architecture changes. A provider may begin as a software supplier and later receive remote administrative access, recovery authority or a signing share. That change can alter its MiCA status.

DORA exit plans must be operational rather than aspirational. The CASP should know whether it can retrieve data, revoke access, migrate keys or policies, replace nodes, reconstruct client positions and continue withdrawals. Testing should address provider insolvency, region failure, loss of a key share, refusal to cooperate, subcontractor failure and termination during an incident.

Public blockchains and decentralised protocols require separate treatment. Not every network or protocol has an identifiable contractual ICT provider. The CASP must still map the dependency, monitor material conditions and define operational responses. DORA’s contractual requirements apply where an ICT third-party service relationship exists; MiCA continuity and custody duties remain relevant regardless.

Proportionality

DORA requires proportional application based on the firm’s size, risk profile, and the nature, scale and complexity of its services. Proportionality changes the depth, staffing and frequency of controls. It does not remove MiCA Article 75 custody duties or the CASP’s responsibility for client assets. (EUR-Lex)

DORA gives microenterprises specific modifications. CASPs do not enter the simplified Article 16 ICT regime merely because they are small. Article 16 identifies particular categories of financial entity, and CASPs are not included solely by reason of size. (EUR-Lex)

A smaller CASP may operate fewer wallets, networks and providers. That can support simpler evidence and less complex testing. A small firm holding high-value client assets through one critical signing path may still present concentrated risk requiring detailed controls.

Remediation and enforcement

The CSA itself does not impose a fine. A national authority may use evidence obtained through the exercise to exercise its MiCA and DORA powers. MiCA powers include information and document requests, inspections, temporary suspension, prohibition of services, public disclosure and measures directed at client protection.

Under DORA, competent authorities may obtain documents, conduct investigations and inspections, and require corrective action. Sanctions and remedial measures must be effective, proportionate and dissuasive. The detailed procedure and appeal route depend on Member State law.

MiCA Article 111 requires Member States to establish administrative-sanction maximums for listed CASP infringements. For legal persons, the benchmarks for the relevant category include at least EUR 5 million and at least 5 percent of total annual turnover. These are required national maximum levels, not automatic penalties for every deficiency. National legislation may set higher maximums and determines the procedure.

For an Article 63-authorised CASP, persistent failure to meet authorisation conditions or a serious infringement can also engage Article 64 withdrawal powers. Article 60 financial entities require separate consideration because Article 60(10) exempts them from Article 64 and leaves sectoral permission consequences to the applicable supervisory regime.

A weak control or low assessment score is not automatically an infringement. The authority should identify the applicable provision, the required conduct, the evidence of failure and the legal basis for the proposed measure. The CASP should preserve its response record, address factual inaccuracies, distinguish recommended practice from binding duty, and provide a dated remediation plan where a deficiency is accepted.

Supervisory-readiness evidence

A CASP should be able to produce one coherent evidence chain rather than six disconnected policy files.

• Management body. The record should contain approved risk tolerance, custody architecture decisions, competence records, reporting packs, incident escalations, third-party approvals and remediation tracking.
• Keys and storage. The record should contain the architecture, inventory, ownership and control map, lifecycle procedures, access logs, ceremony records, backup evidence, recovery tests and client-segregation analysis.
• Transactions. The record should allow a sample instruction to be traced through authentication, approvals, construction, signing, broadcast, confirmation, client accounting and reconciliation.
• Incidents. The record should contain the event chronology, classification decision, reporting timestamps, preserved evidence, root cause, recovery actions, client impact and Article 75 attribution analysis.
• Smart contracts. The record should identify each material contract, its owner, code version, deployment path, administrative rights, dependencies, testing, monitoring and client-asset exposure.
• Third parties. The record should contain the DORA register, criticality assessment, due diligence, contract, subcontractor chain, service monitoring, incident obligations, access rights, concentration assessment and tested exit plan. Any provider exercising custody must also satisfy the Article 75(9) analysis.

The strongest demonstration will connect these records. A wallet diagram should identify the providers in the DORA register. The key inventory should identify smart-contract administrative keys. Incident scenarios should test the recovery arrangements in vendor contracts. Transaction samples should reconcile with the MiCA position register.