MiCA Compliance: What Crypto-Asset Service Providers Must Demonstrate to Operate in the EU

The Grandfathering Period Has Ended

The Markets in Crypto-Assets Regulation (MiCA) became fully applicable on 30 December 2024. Firms providing crypto-asset services within the EU without authorisation are in breach. The grandfathering provisions, which allowed firms operating under national licences to continue temporarily, expired on 1 July 2026 at the latest. That window is closed.

If your organisation provides any regulated crypto-asset service to EU clients, or issues crypto-assets publicly in the EU, and has not obtained MiCA authorisation, the question now is not whether authorisation is required. It is how far behind you already are and what the regulators will find when they look.

This post sets out what MiCA actually requires. It covers who must be authorised, what the authorisation obligations demand in practice, what the cybersecurity and security obligations specifically are, and how MiCA interacts with DORA and the FATF Travel Rule. It is written for traditional financial institutions entering EU digital asset markets and for blockchain-native businesses scaling toward MiCA compliance.

What MiCA Is

MiCA is Regulation (EU) 2023/1114 on markets in crypto-assets, the first comprehensive EU-level legislative framework covering crypto-assets that do not qualify as MiFID financial instruments. It creates a single, harmonised regime for the EU's 27 member states, replacing the patchwork of national frameworks that previously applied. A firm authorised as a CASP under MiCA can passport that authorisation cross-border across all EU jurisdictions, eliminating the need to obtain separate licences in each member state.

MiCA is administered at EU level by ESMA in close coordination with EBA and EIOPA, and at national level by each member state's competent authority (NCA). ESMA maintains a public register of authorised CASPs, firms operating under transitional provisions, and non-compliant entities. The non-compliant register is publicly accessible. Appearing on it is a material reputational event.

MiCA covers three categories of activity:

• Issuance of crypto-assets (other than asset-referenced tokens and e-money tokens) for public offer or admission to trading
• Issuance of stablecoins, meaning asset-referenced tokens (ARTs) and electronic money tokens (EMTs), which have been regulated since 30 June 2024
• Provision of crypto-asset services as a CASP, fully regulated since 30 December 2024

Who Must Obtain MiCA Authorisation

Any legal person providing crypto-asset services to EU clients requires CASP authorisation under MiCA. The regulated service categories are:

• Custody and administration of crypto-assets on behalf of clients
• Operation of a trading platform for crypto-assets
• Exchange of crypto-assets for fiat currency or for other crypto-assets
• Execution of orders for crypto-assets on behalf of clients
• Placement of crypto-assets
• Reception and transmission of orders for crypto-assets on behalf of clients
• Providing advice on crypto-assets
• Portfolio management in crypto-assets
• Transfer services for crypto-assets on behalf of clients

MiCA applies to EU-established firms and to non-EU firms targeting EU clients. There is no third-country passporting regime. A UK-headquartered exchange, a US custody provider, or a Dubai-licensed VASP that actively solicits EU clients, advertises services into the EU, or promotes offerings to EU persons cannot rely on reverse solicitation as a general exemption. Reverse solicitation under MiCA is interpreted very narrowly. It applies only where the client has approached the firm on their own initiative without any prior solicitation or promotion. Firms relying on this exemption broadly are doing so incorrectly.

Existing financial institutions that are already authorised in Europe, including credit institutions, investment firms, e-money institutions, and alternative investment fund managers, are not required to obtain separate CASP authorisation to provide crypto-asset services. They must, however, notify their home NCA before commencing those services and comply with certain MiCA-specific conduct and organisational requirements.

What the Authorisation Application Requires

A MiCA CASP authorisation application is a substantive exercise. It is not a notification. Regulators are reviewing the quality of the documentation, not just its existence. The application must demonstrate, across detailed written submissions, that the organisation can satisfy MiCA's requirements before it begins providing services.

The core documentation requirements include:

• Programme of operations: A detailed description of the planned services, including the types of crypto-assets covered, the markets the firm intends to serve, and the operating model
• Governance arrangements: Documented policies, organisational charts, reporting lines, internal control structures, and evidence that management body members have the experience and standing required under MiCA
• Own funds: Evidence of compliance with MiCA's capital requirements, which vary by service type, from EUR 50,000 for advisory and order reception firms to EUR 150,000 for custody operators and EUR 150,000 for trading platform operators (plus additional requirements based on operating costs)
• Prudential insurance: Where own funds do not fully satisfy the prudential requirement, a professional indemnity insurance policy covering the EU territory where services are provided
• Client asset safeguarding: Policies and procedures governing the segregation and custody of client crypto-assets and fiat funds, including arrangements with custodians where applicable
• Complaints handling: Documented complaints procedures accessible to clients, with defined escalation paths and resolution timelines
• Outsourcing arrangements: Documentation of all material outsourcing, including ICT services, and evidence that oversight of those arrangements is maintained
• Business continuity plan: A documented BCP demonstrating that critical services can continue through disruption and that client assets are protected throughout
• Security policies: Documented systems and security access protocols satisfying MiCA's technical requirements under ESMA's guidelines on maintenance of systems and security access protocols
• AML/CFT policies: Evidence of compliance with the EU Anti-Money Laundering framework, including KYC procedures, transaction monitoring, and Travel Rule compliance
• White paper: Where the CASP also issues crypto-assets, a compliant white paper in the ESMA-prescribed format

Preparation time is substantial. For a firm with no existing European regulatory presence, six to twelve months of internal preparation before submission is realistic. NCAs in major jurisdictions are receiving high volumes of applications. Processing time runs to several months post-submission. Firms that have delayed the process are already at a material disadvantage relative to those that began early.

MiCA's Cybersecurity and Security Obligations

MiCA establishes specific requirements for the security of systems, data, and access controls that CASPs must satisfy as an ongoing condition of authorisation. ESMA has published guidelines specifically on the maintenance of systems and security access protocols for crypto-asset issuers and service providers. These are not generic IT security expectations. They set out technical requirements that must be implemented, documented, and evidenced to a standard regulators can verify.

Systems Security and Access Controls

CASPs must implement and maintain security access protocols covering authentication, authorisation, and access rights management for all systems that support the provision of crypto-asset services. Access to systems handling client assets, order management, or key management infrastructure must be subject to defined controls, with documented evidence of who has access, at what privilege level, and under what approval process. Access rights must be reviewed and updated when personnel change. Single points of access to critical systems are a regulatory concern, not just an operational one.

Network and Infrastructure Security

Network security controls must be documented and maintained. This includes network segmentation to limit the blast radius of a compromise, intrusion detection capability, and defined procedures for isolating and responding to anomalous activity. Infrastructure that supports critical CASP functions must be hardened and subject to documented configuration review. Reliance on default configurations, undocumented network architecture, or untested segregation controls does not satisfy MiCA's requirements in practice.

Cryptographic Key Management

For CASPs providing custody services, the security of cryptographic key management is at the centre of the MiCA regime. Key generation, storage, access, rotation, and backup must be documented and controlled. Multisignature governance structures must reflect genuine separation of duties, not nominal decentralisation with de facto single-key control. Key management procedures must be auditable, with evidence of testing against the documented procedures rather than policy documents that exist only on paper.

The regulatory expectation here is not new to those who follow on-chain security events closely. The pattern across the majority of significant CASP losses in the past two years, from the Bybit compromise in February 2025 to the StablR key governance failure in May 2026, is not smart contract vulnerability. It is operational security failure at the key management and signing workflow level. MiCA's custody security requirements exist because regulators understand this pattern. Custodians that cannot demonstrate documented, tested, independently reviewed key management will not satisfy the authorisation requirements.

Incident Response and Reporting

CASPs must have documented incident response procedures covering detection, classification, escalation, and resolution of security incidents. For incidents affecting client assets or personal data, reporting to the competent authority is required. Given MiCA's interaction with DORA for CASPs in scope of both regulations, the incident management framework must also satisfy DORA's phased reporting requirements, including initial notification within four hours of major incident classification and a final report within one month. A CASP that has built its incident response for MiCA but has not mapped it to DORA's timeline requirements has an incomplete programme.

Ongoing Security Testing

MiCA requires CASPs to conduct regular security testing of systems supporting the provision of crypto-asset services. This is an ongoing obligation, not a pre-authorisation exercise. Independent security reviews, penetration testing, and vulnerability assessments must be conducted at regular intervals and the results must be documented. Findings and remediation status must be retained. For CASPs also subject to DORA's TLPT requirement, threat-led penetration testing of production systems is a separate, higher-standard obligation on top of regular penetration testing.

Stablecoins: ARTs and EMTs

Asset-referenced tokens and electronic money tokens have been regulated under MiCA since 30 June 2024. The requirements for issuers are substantially more demanding than those for general crypto-asset issuers or CASPs.

ART issuers must obtain prior NCA authorisation, publish an NCA-approved white paper, maintain own funds of at least 3% of the average reserve assets (or 2% for EMT issuers), hold reserve assets under strict custody and investment rules, have wind-down plans that protect holders throughout an orderly cessation, and comply with restrictions on the use of ARTs and EMTs as means of exchange if transaction thresholds are exceeded.

Issuers designated as significant, on the basis of the number of users, transaction volumes, or other criteria specified in the regulation, face additional requirements including supervision by EBA rather than the home NCA and heightened capital and liquidity buffers.

Stablecoin issuers seeking MiCA compliance often underestimate the security programme that sits beneath the financial requirements. The reserve asset custody arrangements, the key management infrastructure for issuance and redemption controls, and the incident response procedures for mint and burn operations all require the same documented, independently reviewed security posture as any other regulated CASP. The financial authorisation and the security programme are not sequential. They are parallel requirements that both feed the application.

The FATF Travel Rule Under MiCA

The EU Transfer of Funds Regulation, implementing FATF's Travel Rule for crypto-assets, became applicable on 30 December 2024, aligned with MiCA's full application date. CASPs are now legally required to collect, verify, and transmit originator and beneficiary information for all crypto-asset transfers, with no threshold below which the obligation disappears. This applies to transfers between CASPs and to transfers between CASPs and unhosted wallets, subject to specific requirements for the latter.

Compliance requires a technical solution that integrates with the CASP's transaction workflow and can exchange Travel Rule data with counterpart CASPs. Several Travel Rule compliance protocols are in use across the industry. Selecting and implementing one, testing it against counterpart systems, and documenting the process as part of the AML/CFT evidence package is a programme of work in its own right. CASPs that have not completed this should treat it as a current compliance gap, not a future planning item.

MiCA and DORA: The Dual Compliance Requirement

CASPs authorised under MiCA are in-scope entities under DORA. Both regulations apply simultaneously. The interaction is deliberate. MiCA provides the market conduct and financial authorisation framework for crypto-asset service providers. DORA provides the digital operational resilience and ICT risk management framework that sits beneath it. Between them, they cover governance, capital, client asset protection, cybersecurity, incident management, third-party risk, and resilience testing.

The practical consequence is that a CASP preparing a MiCA authorisation application must also build a DORA-compliant programme. The two evidence trails overlap significantly. The ICT risk management framework required by DORA supports the security and governance documentation required by MiCA. The incident response procedures required by both frameworks must be designed as a single, coherent system, not two separate documents. Independent security reviews that evidence compliance with MiCA's technical security requirements also generate evidence relevant to DORA's resilience testing pillar.

Treating MiCA and DORA as separate compliance tracks creates duplication, gaps, and unnecessary cost. Designing the programme to address both simultaneously, with documentation structured for both regulatory audiences, is the more efficient and more defensible approach.

Third-Country Firms: The No-Passporting Problem

MiCA does not provide a third-country equivalence regime for crypto-asset service providers. A firm headquartered in the United Kingdom, United States, UAE, or any non-EU jurisdiction cannot passport its home authorisation into the EU. To provide crypto-asset services to EU clients, it must establish a legal entity within the EU and obtain CASP authorisation from a member state NCA.

The reverse solicitation exemption, which allows a firm to provide services without authorisation where the client initiated contact on their own initiative, is explicitly intended to be interpreted narrowly under MiCA. Firms that rely on it broadly risk being placed on ESMA's non-compliant register. The exemption covers genuine own-initiative contact. It does not cover clients who found the firm through advertising, social media presence, or any promotional activity directed at EU persons.

For UK firms in particular, the absence of a UK-EU equivalence decision means that providing crypto-asset services into the EU market after MiCA's application requires a separate EU authorisation, regardless of FCA authorisation status. This is a structural issue that has no workaround other than obtaining the required authorisation.

What Regulators Look for in a MiCA Application

NCAs across the EU have been public about the reasons MiCA CASP applications are returned or refused at the preliminary review stage. The most common failure modes are not complex legal questions. They are documentation problems.

Applications are refused or returned for business continuity plans that are too generic to be verifiable, governance structures that name roles without documenting responsibilities or accountability structures, security policies that reference frameworks without demonstrating how those frameworks have been implemented and tested in the specific operational environment, and AML/CFT programmes that describe processes without evidencing that those processes work in practice.

Regulators reviewing a MiCA application are asking: can this organisation demonstrate, through specific documented evidence, that it has the governance, operational security, financial soundness, and client protection infrastructure to be authorised? A strong underlying security programme that is not documented to the required standard fails on the same basis as an inadequate one. The evidence trail is part of the requirement, not supplementary to it.

Where Blockchain-Native Firms Typically Fall Short

Blockchain-native CASPs seeking MiCA authorisation typically arrive with strong technical security practices and weak governance documentation. They have smart contract audits, they have on-chain monitoring, and in many cases they have solid key management practices operationally. What they frequently lack is the written documentation layer that MiCA requires.

The governance gap is the most common blocker. MiCA requires documented evidence that the management body has defined and taken responsibility for the risk appetite, that reporting lines are clear, that conflicts of interest have been identified and managed, and that decisions about material operational changes go through documented approval processes. These are institutional governance disciplines. They are not inherently foreign to well-run blockchain-native firms, but they are almost never documented at the level MiCA regulators expect to see.

The security documentation gap compounds this. An independent security review, even a high-quality one, does not automatically produce documentation in the format an NCA expects to review. The scope, methodology, findings, and remediation status must be structured for a regulatory audience. A report written for an internal technical team is a different document from a report written for a competent authority reviewer. Both the review and the regulatory documentation are required.

What We Provide

Security4Web3 provides the independent security reviews and regulatory-grade documentation that CASP applicants need to satisfy MiCA's technical security requirements. Our work covers both the on-chain infrastructure layer, which most blockchain security firms address, and the operational security layer, which most do not. That combination reflects where MiCA's security obligations actually sit.

For MiCA compliance specifically, we cover:

• Systems and security access protocol review covering authentication, access rights, privilege management, and network security controls against ESMA's guidelines on MiCA security requirements
• Smart contract and on-chain infrastructure audit structured as an independent third-party review suitable for inclusion in the authorisation application
• Cryptographic key management review for CASP custody operations, covering key generation, storage, access controls, multisig governance, rotation procedures, and single-point-of-failure analysis
• Incident response design producing documented, tested procedures that satisfy both MiCA's reporting requirements and DORA's phased incident classification and notification timelines
• Business continuity and wind-down plan support for the security architecture elements that must be documented to satisfy both MiCA and DORA obligations
• Third-party ICT risk assessment covering the on-chain dependencies, including oracle networks, bridge infrastructure, RPC providers, and custody technology, that constitute ICT third-party arrangements under DORA and outsourcing arrangements under MiCA

Our reports are written for regulatory audiences. Scope, methodology, findings, and remediation status are structured to satisfy NCA review, not only internal sign-off. Where a regulator asks for evidence of specific MiCA or DORA security requirements, our report is the document you provide.

Where to Begin

For firms that have not yet started the MiCA authorisation process, the immediate priority is a gap analysis that maps your current operational and documentation posture against MiCA's requirements. This identifies what you have, what you are missing, and what the timeline for remediation looks like. Given processing times at major NCAs, time is already a constraint.

For firms that are mid-application or have had an application returned, the gap is typically in the documentation layer rather than the underlying security programme. A targeted review of the specific requirements the NCA has identified, producing regulatory-grade documentation to close those gaps, is usually faster than a full restart.

For non-EU firms assessing whether EU market access justifies the investment in MiCA authorisation, the analysis is straightforward. There is no compliant alternative for actively providing services to EU clients. The reverse solicitation exemption does not substitute for authorisation. The question is when to begin the process and which member state offers the most efficient authorisation route for your specific business model.