MiCA technology compliance

The Markets in Crypto-Assets Regulation introduces a comprehensive regulatory framework for crypto-asset service providers in the EU. The technology obligations are specific, structural, and not optional.

MiCA — Markets in Crypto-Assets Regulation, the EU regulatory framework for crypto-asset service providers. Four technology compliance pillars: ICT Risk Management (identify and document ICT assets, assess and manage ICT risks, information security controls, incident detection and response, business continuity and disaster recovery); Operational Resilience (recovery capability measured by RTO/RPO, tested business continuity plans, resilient architecture, secure custody and key management); Governance & Internal Controls (senior management oversight, clear roles and accountability, separation of duties, audit trails and evidence of oversight); and Outsourcing & Third-Party Risk (governed outsourcing agreements, rights of access and audit, dependency mapping, with the crypto-asset service provider remaining responsible). These apply across the technology estate — systems, data, APIs and services, custody and keys, and third parties. The outcome is authorisation and ongoing compliance: demonstrating that controls are in place, operational and effective, reviewed by the competent authority — with MiCA and DORA treated as overlapping responsibilities under one integrated approach.

What MiCA is

The Markets in Crypto-Assets Regulation (MiCA) is the EU’s regulatory framework for crypto-assets and crypto-asset service providers. It establishes authorisation requirements, operational standards, and consumer protection obligations across the EU.

MiCA applies to issuers of crypto-assets and to crypto-asset service providers (CASPs) — entities providing services including exchange, custody, transfer, portfolio management, and advice in relation to crypto-assets.

For technology functions, MiCA establishes requirements in four main areas: ICT risk management, operational resilience, governance and internal controls, and outsourcing and third-party risk. These are not aspirational standards. They are authorisation and ongoing compliance requirements.

ICT risk management under MiCA

MiCA requires crypto-asset service providers to implement a comprehensive ICT risk management framework. The framework must:

– Identify and document ICT assets, including systems, data, and third-party services – Assess and manage ICT risks on a continuous basis – Maintain an ICT business continuity policy and disaster recovery plans with defined and tested recovery objectives – Implement information security controls appropriate to the risk profile of the organisation – Establish processes for monitoring, detecting, and responding to ICT incidents

The framework must be documented, reviewed regularly, and demonstrably operational. Documentation that describes controls that do not exist is a compliance liability, not a defence.

Operational resilience

MiCA requires CASPs to maintain operational resilience sufficient to meet their service obligations to clients and to manage the risks inherent in the assets and services they provide.

This translates to specific architectural requirements.

Recovery capability. Systems must be able to recover from disruption within timeframes that reflect the nature of the services provided. Recovery Time Objectives and Recovery Point Objectives must be defined, documented, and tested against the actual architecture.

Continuity planning. A tested business continuity plan must exist for ICT systems. Not a plan that was written and filed. A plan that is regularly reviewed, updated to reflect changes in the architecture, and tested to verify that it works.

Custody and key management. For CASPs providing custody services, the security and resilience of private key management infrastructure is a direct regulatory requirement. Architecture that holds client assets must be designed and governed accordingly.

Governance and internal controls

MiCA requires governance arrangements that ensure effective oversight of the ICT function. This includes:

– Clear allocation of responsibility for ICT risk and information security at senior management level – Adequate separation between operational and oversight functions – Audit trails that support accountability and regulatory review

The governance requirement is not satisfied by an organisation chart that names a responsible person. It requires demonstrable oversight — evidence that the governance function is active, that decisions are made with appropriate information, and that accountability is exercised.

Third-party and outsourcing requirements

MiCA includes specific requirements for outsourcing arrangements and the use of third-party services in connection with regulated activities.

Where a CASP outsources material functions — including ICT functions — the arrangement must be governed by a contract that meets regulatory requirements, including rights of access and audit. The CASP remains responsible for compliance. Outsourcing does not transfer the regulatory obligation.

Cloud providers, custodians, and technology vendors that support regulated functions are in scope for this requirement. A dependency map that identifies all material third-party arrangements is a prerequisite for demonstrating compliance.

The relationship between MiCA and DORA

Financial entities that fall within both the MiCA and DORA scopes — which includes many CASPs — face overlapping but not identical requirements from both regulations.

DORA applies primarily to entities in the traditional financial sector and their ICT third-party service providers. MiCA applies to entities in the crypto-asset sector. Where an entity operates in both sectors, or where a traditional financial institution is expanding into crypto-asset services, both frameworks apply.

The ICT risk management requirements in MiCA are broadly consistent with those in DORA, but the specific provisions differ. Managing both requires an architecture and governance approach designed with both frameworks in mind.

What this means in practice

MiCA authorisation requires demonstrating, to the satisfaction of the relevant national competent authority, that the ICT function meets the regulation’s requirements before authorisation is granted.

This is not a documentation exercise. Competent authorities review whether controls described in applications are actually in place and operational. An architecture designed to meet MiCA requirements will support authorisation. An architecture described as meeting them that does not will not.

The practical starting point is an honest assessment of the current state: what the architecture is, what the data model is, what the third-party dependencies are, and where the gaps between current state and regulatory requirement actually lie.

How we can help

MiCA technology compliance is a consultancy and fractional CTO engagement area at Sixteen Pillars, with particular focus on CASPs and regulated financial entities operating in Cyprus and across the EU.

Start a Conversation

Frequently asked questions

When did MiCA come into force? MiCA has been phased in. Requirements for asset-referenced tokens and e-money tokens applied from June 2024. Requirements for crypto-asset service providers applied from December 2024.

Does MiCA apply to businesses operating from Cyprus? Yes. CySEC is the competent authority for MiCA authorisation in Cyprus. CASPs operating from Cyprus — including the significant number of firms that hold or are applying for CySEC authorisation — are subject to MiCA’s requirements.

Is MiCA compliance the same as CySEC registration? MiCA is the EU regulatory framework. CySEC is the national competent authority through which Cyprus-based entities apply for MiCA authorisation and demonstrate ongoing compliance. They are related but not the same.

What is the technology requirement for crypto-asset custody under MiCA? Custody of crypto-assets requires secure and resilient infrastructure for private key management, with appropriate segregation of client assets, access controls, and recovery capability. The specific requirements are set out in MiCA and its technical standards.

What happens if an existing CASP does not meet MiCA’s ICT requirements? Entities that were providing crypto-asset services before MiCA’s application date may benefit from transitional provisions that vary by member state. Cyprus has implemented a transition period. However, full compliance is required within the applicable transition window, and authorisation under MiCA requires demonstrating that requirements are met.

Free interactive tool

Interactive deadline calculator

Check which regulations apply to you and when

Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.

Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.