MiCA Article 68 Operational Resilience: A Technology Function’s Reading

A reading of what MiCA Article 68 actually demands of a Crypto-Asset Service Provider’s technology function, and how it interacts with DORA.

Of all the articles in MiCA, Article 68 is the one a CASP’s technology function has to actually live with. It is where governance arrangements meet operational resilience, where the link to DORA is made explicit, and where the Commission’s Delegated Regulation (EU) 2025/299 — the technical standards published in early 2025 — adds the concrete specifications.

This is a reading of what Article 68 substantively requires, written for the people who have to commission, own, and evidence the arrangements to a competent authority.

Where Article 68 sits in MiCA

MiCA’s Title V covers authorisation and operating conditions for Crypto-Asset Service Providers. Articles 59 to 85 set out the regime. Article 68 is the governance article — the one that requires a CASP to maintain robust governance arrangements, including clear organisational structure, sound administrative and accounting procedures, internal control mechanisms, effective risk procedures, and — at paragraph 7 — appropriate ICT systems and security protocols.

Paragraph 10 is the one that matters most to a tech function. It requires CASPs to ensure that the ICT systems supporting crypto-asset services are resilient and secure, and to put in place business continuity policies. Crucially, it cross-refers to DORA (Regulation EU 2022/2554) — CASPs are financial entities for DORA purposes, which means the full DORA framework applies to them in addition to the MiCA-specific governance requirements.

The Commission Delegated Regulation (EU) 2025/299, which came into force in March 2025, provides the regulatory technical standards (RTS) that specify what “continuity and regularity in the performance of crypto-asset services” means in concrete terms. If you are operating a CASP today, the RTS is the document your tech function needs to be able to evidence against.

Who this is for

• The CTO or CIO of an authorised or applicant CASP — exchange, custodian, broker, advisor, portfolio manager — who has to map MiCA Article 68 and DORA onto an actual operating architecture.
• The board member at a CASP whose committee has been asked to approve the operational resilience arrangements and who wants to know whether what is in front of them is sufficient.
• The compliance lead at a financial entity that has acquired or is acquiring a CASP and is integrating the operational resilience requirements into the group framework.

It is not a legal interpretation. It is a reading of what the tech function will be asked to evidence to the competent authority — CySEC, MFSA, BaFin, CSSF, AMF, depending on the jurisdiction of authorisation.

What Article 68 actually requires of the tech function

Read with the RTS, the technology obligations split into six clusters:

1. ICT systems that are appropriate to the scale and complexity of the service. This sounds vague. In practice, it means a documented systems architecture, traceability between the services offered and the systems supporting them, capacity planning, and evidence that the architecture has been reviewed and approved at the right level.

2. Security protocols that protect the integrity, confidentiality, and availability of data. The classic information security triad, translated to crypto-specific concerns. Custody key management is the most regulated subset — but the RTS extends to client data, transaction data, and order book integrity for trading venues.

3. Business continuity arrangements covering critical functions. Not just “we have a DR site.” A documented business continuity policy, identification of critical functions, recovery time objectives appropriate to each, tested at least annually, and reviewed in light of incidents.

4. ICT third-party arrangements documented and managed. Cloud providers, market data vendors, custody sub-providers, KYC vendors — all of them. The RTS requires a register of all ICT third parties, with risk classification, contract review, exit plans for critical providers, and ongoing monitoring. This is where DORA Articles 28 to 30 substantively bite.

5. Incident detection, response, and reporting. DORA Article 17 establishes a uniform incident classification and reporting framework. CASPs must be able to detect material ICT-related incidents, classify them, and report to the competent authority within DORA’s timelines. The reporting is non-trivial.

6. Resilience testing. DORA Chapter IV establishes a digital operational resilience testing programme. For most CASPs, this means annual basic testing — vulnerability scans, scenario-based tests, source code reviews. For those identified as significant by their competent authority, it extends to threat-led penetration testing under Article 26.

Where CASPs get this wrong

From the first eighteen months of CASP authorisations under MiCA, the recurring deficiencies the competent authorities have flagged:

Treating MiCA and DORA as separate compliance programmes. They are not separate. Article 68(10) makes DORA part of MiCA compliance. A CASP that has built a MiCA programme without DORA, or a DORA programme without MiCA-specific custody and crypto-service considerations, has half a programme.

Custody architecture not documented to the level the RTS expects. Cold-warm-hot wallet split is the standard pattern. What the RTS expects is the documentation of access control to each, key ceremony procedures, segregation of duties, and the relationship between custody operations and the rest of the business. A diagram on a slide deck is not enough.

Third-party registers that miss the long tail. The cloud provider and the KYC vendor are usually on the register. The block explorer, the price oracle, the chain analytics provider, the staking infrastructure, the custody sub-provider’s sub-provider — these are routinely missed and routinely flagged in supervisory visits.

Incident reporting capability untested before the first real incident. Under DORA, the major-incident clock starts when the incident is classified. If your team cannot classify quickly, you miss the reporting window. Several CASPs have had supervisory action triggered by reporting delays in 2025.

What “good” looks like, evidentially

A competent authority engaging with a CASP on Article 68 expects to see:

• A systems architecture document mapping services to underlying ICT systems.
• An ICT risk management framework approved by the board, satisfying DORA Article 6.
• A documented custody architecture with the cold-warm-hot split, key ceremony procedures, and access controls.
• A business continuity policy with tested recovery procedures and an annual exercise report.
• A complete register of ICT third parties, with classification, contracts, and exit plans for critical providers.
• An incident management procedure with classification criteria and reporting playbooks.
• A digital operational resilience testing programme, with the last year’s test reports and remediation tracking.

If you have all seven and they tell a coherent story, you are in a defensible position. Crucially, the documents must be consistent with each other — the architecture diagram must match what the third-party register says, the BCP must reference the same custody architecture, the incident playbook must reference the same critical functions. Inconsistency between documents is what supervisors notice first.

How we engage with this

We read CASP operational resilience arrangements. As part of a Technology Control Review or an Architecture Review scoped to MiCA and DORA, we identify the gaps between what is documented and what Article 68 read with DORA expects, and write it down with specific recommendations.

We do not implement custody arrangements. We do not run penetration tests. We do not sell GRC software. We read what is there, identify what is missing, and write it down for the board and the competent authority engagement team.

Pricing is published at /pricing/. If you are an applicant CASP or an authorised CASP preparing for a supervisory engagement, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.