MiCA After Authorisation: What ESMA’s Custody Resilience CSA Means for CASPs
- 4 days ago
- 10 min read
A MiCA authorisation shows that a CASP has designed an acceptable regulatory framework. ESMA’s new Common Supervisory Action brings a harder question into focus: does that framework continue to work under operational pressure?
Obtaining a MiCA authorisation is a significant milestone for any crypto-asset service provider.
It is not, however, proof that the firm’s custody model will remain effective during a technology failure, access compromise, third-party disruption or operational incident.
That distinction lies at the heart of ESMA’s new Common Supervisory Action on the digital operational resilience of authorised CASPs providing custody services.
The exercise signals that supervisory attention is moving beyond the frameworks presented during authorisation. The next phase is about how those frameworks operate in practice — and whether firms can produce reliable evidence that their controls continue to work.
Authorisation was the starting point
On 8 July 2026, ESMA announced a Common Supervisory Action focused on the digital operational resilience of authorised Crypto-Asset Service Providers in relation to custody activities.
National Competent Authorities will assess a risk-based sample of authorised CASPs. The exercise will run from the second half of 2026 until the first half of 2027, with consolidated findings expected to be considered by ESMA’s Board of Supervisors during the second half of 2027.
The timing is difficult to ignore.
The maximum MiCA transitional period ended on 1 July 2026. Only days later, ESMA announced a coordinated supervisory review of one of the most operationally sensitive crypto-asset services.
ESMA has not formally described this as a transition from authorisation to ongoing supervision. Nevertheless, the broader direction is clear.
Authorised CASPs will increasingly be expected to show not only that appropriate policies exist, but that their systems, responsibilities and controls perform as described.
For many firms, this will require a different type of regulatory readiness.
During authorisation, the emphasis is often on documenting the proposed operating model. Under ongoing supervision, the firm must show how that model behaves in real situations.
What ESMA has announced
The CSA will examine the maturity of CASPs’ digital operational resilience frameworks in relation to custody activities.
ESMA has identified six areas of focus:
governance arrangements;
key and storage management;
transaction controls;
incident detection and response;
smart contract risks;
dependencies on third-party providers.
These areas reflect the operational risks created by distributed ledger technology and the infrastructure used to safeguard crypto-assets or control access to them.
The announced scope is important, but so are its limits.
ESMA has not described the CSA as a complete review of every MiCA custody obligation. Its stated focus is digital operational resilience in connection with custody.
Nor has ESMA published a detailed questionnaire, common document request list or assessment methodology. There is currently no official checklist setting out the evidence that selected CASPs will be required to provide.
Firms should therefore be cautious about treating market commentary as confirmed supervisory expectations.
At the same time, the six announced areas give authorised CASPs enough information to begin a meaningful internal review.
The sensible question is not:
Can we predict every document that the supervisor may request?
It is:
Can we explain how our custody model works, who controls it, how failures are detected and what evidence shows that the framework remains effective?
Why custody is where rules meet reality
Crypto-asset custody is sometimes viewed primarily as a technical service involving wallets, private keys and storage solutions.
Under MiCA, it is much broader.
A functioning custody model must connect technology with:
protection of client ownership rights;
governance and accountability;
access and transaction controls;
accurate books and records;
incident management;
business continuity;
third-party oversight;
the ability to return assets or means of access to clients.
Article 75 of MiCA requires CASPs to maintain a custody policy containing internal rules and procedures for safeguarding crypto-assets or the means of access to them. The arrangements must minimise the risk of loss resulting from fraud, cyber threats or negligence.
The same Article also addresses position records, the return of assets, and the legal and operational segregation of client holdings.
Article 70 reinforces the obligation to protect clients’ ownership rights and prohibits CASPs from using clients’ crypto-assets for their own account.
Taken together, these requirements make custody a point at which several types of risk meet:
client asset risk, ICT risk, access risk, DLT risk, governance risk and outsourcing risk.
A failure in any one of these areas may affect the CASP’s ability to retain control over assets entrusted to it.
This is why custody resilience cannot be managed by the technology function alone. It depends on decisions, responsibilities and controls across the wider organisation.
MiCA and DORA operate within the same control environment
The CSA should not be approached simply as a review of the firm’s Custody Policy.
It sits at the intersection of MiCA’s custody obligations and the digital operational resilience requirements introduced by DORA.
Article 68 of MiCA requires CASPs to maintain effective policies and procedures, use appropriate resources, operate resilient and secure ICT systems and establish business continuity, response and recovery arrangements.
It also requires the management body to assess periodically whether those policies and procedures remain effective and to take action where deficiencies are identified.
This changes the nature of the supervisory question.
It is no longer enough to ask:
Does the firm have a documented custody framework?
The more relevant question is:
Can the firm maintain control over its custody operations when systems fail, access is compromised or a critical provider becomes unavailable?
A policy explains how the control environment is intended to work.
Operational resilience depends on what actually happens when that environment is placed under pressure.
Six areas that CASPs should examine
ESMA has not yet published its detailed assessment framework. The six announced areas nevertheless indicate where authorised CASPs should expect closer supervisory attention.
1. Governance arrangements
Custody resilience starts with clear responsibility.
It should be possible to identify who owns the material custody risks, who approves the relevant controls, who receives information about incidents and who can make urgent decisions when something goes wrong.
This is not only a question of whether responsibilities appear in a policy or organisational chart.
The firm should understand:
whether custody risks are visible to the management body;
how incidents and control failures are escalated;
who owns remediation;
how overdue actions are tracked;
whether the effectiveness of the custody framework is reviewed periodically.
A general cyber-risk report may not be enough if it does not show the condition of the firm’s custody-specific controls.
The management body does not need to perform technical key management. It does, however, need sufficient information to understand whether the associated risks are being controlled.
2. Key and storage management
Private keys and other access mechanisms sit at the centre of most custody models.
But key management is not simply a choice between hot, warm and cold storage. It covers the full lifecycle of the keys and credentials used to control client assets.
This may include:
key generation;
distribution and storage;
access approval;
privileged access;
rotation;
backup;
recovery;
compromised or unavailable keys;
emergency access;
access logging and review.
A technically sophisticated storage model can still contain governance weaknesses.
For example, a firm may use secure infrastructure but lack a reliable process for reviewing privileged access. It may have backup keys but no current evidence that recovery procedures work. Emergency access may exist without sufficiently clear approval or retrospective review.
The relevant issue is therefore not only how keys are stored, but how access to them is governed throughout their lifecycle.
3. Transaction controls
Custody resilience also depends on the controls surrounding the initiation, approval and recording of transactions.
These may include:
segregation of duties;
multi-person approval;
transaction limits;
address allowlisting;
reconciliation;
exception handling;
emergency overrides;
failed or delayed transaction management;
transaction logs;
investigation of unusual activity.
Many of these controls look straightforward when described in a procedure. Their effectiveness becomes less certain when exceptions arise.
A dual-approval requirement, for example, provides limited protection if emergency overrides are not recorded or independently reviewed.
A reconciliation procedure is equally weak if breaks remain unresolved without escalation.
Supervisors are likely to be interested not only in the standard process, but in what happens when that process cannot be followed.
4. Incident detection and response
Custody-related incidents can have consequences that differ significantly from ordinary ICT disruption.
A generic Incident Response Plan may not adequately address:
compromise of private keys;
unauthorised asset movements;
loss of access to wallets;
failure of signing infrastructure;
disruption at a custody technology provider;
smart contract vulnerabilities;
blockchain congestion or instability;
reconciliation failures;
breakdown of transaction approval controls.
The firm’s response arrangements should connect technical detection with operational decision-making.
That means establishing how an incident is identified, classified and escalated; how client assets and services are affected; who decides whether transactions should be suspended; how recovery is managed; and how regulatory reporting requirements are assessed.
For custody services, detecting an incident is only the beginning.
The more difficult task is preserving control over client assets while the organisation investigates, makes decisions and restores critical functions.
5. Smart contract risks
The express inclusion of smart contract risk is notable.
It shows that the CSA is not limited to traditional wallet and key infrastructure.
Depending on the business model, smart contract dependencies may arise through:
staking;
settlement arrangements;
bridges;
token wrapping;
decentralised protocols;
automated transaction logic;
upgradeable contracts;
emergency pause functions.
A one-off smart contract audit is useful, but it does not create a complete control framework.
The firm may also need to understand:
which contracts it depends on;
how materiality and risk are assessed;
who approves their use;
who controls administrative or upgrade keys;
how changes are monitored;
how vulnerabilities are escalated;
what emergency action is available.
The practical issue is whether smart contract risk has been integrated into the organisation’s governance, incident management and operational risk arrangements.
It should not exist as a separate technical topic understood only by developers or external auditors.
6. Dependencies on third-party providers
Third-party dependency may prove to be one of the most demanding areas of the CSA.
Custody providers frequently rely on external firms for wallet infrastructure, key management, cloud services, blockchain nodes, transaction screening, cybersecurity tools and operational data.
MiCA makes clear that outsourcing does not transfer regulatory responsibility.
The authorised CASP must retain enough expertise, information and organisational capacity to understand and control the outsourced service.
This means the relevant question is unlikely to be limited to:
Is there a signed outsourcing agreement?
A more meaningful review may consider whether the CASP:
understands how the outsourced infrastructure operates;
receives appropriate performance and incident information;
monitors service quality;
assesses sub-outsourcing and concentration risk;
retains sufficient internal technical competence;
can require corrective action;
maintains workable contingency and exit arrangements.
An exit plan may look credible on paper while remaining almost impossible to execute.
Moving a custody infrastructure to another provider may require system changes, data migration, new access arrangements, revised customer communications and extensive operational testing.
Unless those dependencies are properly understood, the existence of an exit clause provides limited comfort.
What authorised CASPs should review now
The absence of a published ESMA checklist does not mean that firms need to wait.
Each of the six announced areas can be reviewed across five connected layers.
Governance
Who owns the risk? Who receives the information? Who makes decisions? Who follows up when controls fail?
Documentation
Do the custody, key management, transaction control, incident response, business continuity, smart contract and outsourcing documents describe the same operating model?
Operational controls
Are access controls, approval workflows, reconciliations, monitoring and escalation arrangements actually being performed?
Systems and evidence
Can the firm retrieve logs, access reviews, incident files, test results, management reports and other evidence showing that the controls operated?
Assurance
How does the organisation test whether its custody framework remains effective? Are weaknesses documented, challenged and followed through to resolution?
The purpose of this exercise is not simply to collect more documents.
It is to establish whether governance, documentation, systems and operational evidence tell the same story.
Where the framework may break down
A custody framework may appear complete when each document is reviewed separately.
The gaps often become visible only when the documents are compared with the actual process.
For example:
The Custody Policy refers to least-privilege access, but the firm cannot produce evidence of periodic privileged-access reviews.
The Incident Response Plan exists, but it does not address the compromise of a private key or the loss of access to client assets.
The Outsourcing Policy requires exit planning, but the operational feasibility of moving to another custody provider has never been assessed.
A smart contract was audited before deployment, but no governance process exists for subsequent upgrades or emergency intervention.
The Transaction Control Procedure requires dual approval, but emergency overrides are not independently reviewed.
The management body receives general cyber reporting but cannot determine the status of custody incidents, control failures and remediation.
These are not simply drafting issues.
They show that the organisation’s documentation, responsibilities, systems and evidence have not been designed as one connected control framework.
The wider supervisory signal
During authorisation, a CASP is assessed largely through what it presents: its proposed governance, policies, systems, resources and control environment.
Ongoing supervision looks at what happens next.
Has the business model changed? Have new providers been introduced? Do the controls still reflect the technology being used? Were lessons from incidents incorporated into procedures? Can management see where the main weaknesses are?
The ESMA CSA is relevant even to firms that are not selected for the initial risk-based sample.
Common Supervisory Actions are intended to promote convergence between national authorities. The findings may therefore shape future reviews, information requests and wider supervisory expectations across the EU.
Maintaining the documents originally submitted during authorisation will not, by itself, be enough.
The framework must continue to reflect:
the firm’s actual custody architecture;
the services it provides;
its current technology and providers;
operational incidents and control failures;
the risks reported to management;
the controls operating in practice.
Lynsora perspective
The CSA reinforces a wider shift in European crypto-asset supervision.
MiCA authorisation is not the final stage of regulatory readiness. It is the point from which a CASP becomes responsible for showing that its framework remains effective throughout real operations.
For custody providers, that evidence will not sit in one policy.
It will be found across access reviews, transaction records, incident files, recovery tests, provider oversight, governance minutes, management reporting and documented remediation.
The central question is therefore not whether the firm has enough documentation.
It is whether the documented framework, the operating model and the available evidence remain aligned.
Authorisation confirms that a CASP has presented an acceptable framework. Operational supervision tests whether that framework remains controlled, evidenced and effective in practice.
Official sources
ESMA, ESMA launches Common Supervisory Action on CASPs’ digital operational resilience for custody, 8 July 2026.
ESMA, Public Statement: MiCA transitional period ends, June 2026.
Regulation (EU) 2023/1114, Article 68 — Governance arrangements.
Regulation (EU) 2023/1114, Article 70 — Safekeeping of clients’ crypto-assets and funds.
Regulation (EU) 2023/1114, Article 73 — Outsourcing.
Regulation (EU) 2023/1114, Article 75 — Providing custody and administration of crypto-assets on behalf of clients.
European Supervisory Authorities, Report on major ICT-related incidents under DORA, June 2026.
ESMA, Supervisory Briefing on the Authorisation of CASPs under MiCA, January 2025.
Disclaimer
This article is provided for general information purposes only and does not constitute legal, regulatory or professional advice.

Comments