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

Most of the public MiCA conversation has been about the licence: who has one, in which member state, and how long it took. That conversation is closing. The transitional period that let legacy providers keep operating has now run out across most of the EU — the longest national windows ended on 1 July 2026, with a handful running to 30 December 2026 — and the question supervisors are asking has shifted from “does MiCA apply to you?” to “can you show the controls working?”

Article 68 is where a large part of that answer lives, and it is a technology question before it is a legal one.

What Article 68 actually asks of the technology function

Article 68 sets the governance arrangements for a crypto-asset service provider. Two of its demands land squarely on engineering rather than on the compliance desk: the firm must run secure ICT systems and access protocols, and it must maintain the continuity and regularity of its services through business continuity arrangements. These are not aspirational statements. The continuity requirement under Article 68(10) has been given detailed form in a regulatory technical standard — Commission Delegated Regulation (EU) 2025/299 — which sets out what a CASP’s continuity and regularity arrangements must contain.

In practice, that means a supervisor can now hold a specific, published standard against your systems and ask where each element is implemented. “We have a business continuity policy” is no longer a sufficient answer. The document has to correspond to a tested capability.

Where Article 68 stops and DORA starts

The reason so many CASPs underestimate the ICT burden is that Article 68 states the resilience obligation at a high level and then points outward. CASPs are named financial entities under the Digital Operational Resilience Act, which has applied to them since 17 January 2025. DORA is the detailed framework that operationalises the security and continuity duties Article 68 describes — its five areas (ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing) are the substance behind Article 68’s headline.

The correct way to read the two together is not as two programmes but as one control set feeding two regimes. A single documented ICT risk framework should satisfy DORA Articles 6–8 and, at the same time, stand as your evidence for Article 68. Firms that build these separately double their cost and, worse, create two versions of the truth that a supervisor will find and question.

The pieces a technology function should be able to produce on request:

• An ICT risk management framework mapped to DORA’s pillars, with named owners for each control.
• A third-party ICT register covering every critical provider — cloud, custody technology, market-data feeds — with the audit rights, sub-outsourcing controls and exit plan DORA Article 30 requires.
• Incident classification and reporting capable of identifying a major incident and reporting it within DORA’s tight windows, not on a next-business-day basis.
• A continuity plan that has been tested, aligned to the 2025/299 RTS, with the test results retained.
• Key-lifecycle controls for custody — generation, storage, HSM or MPC signing, dual control, segregation of duties — mapped to the safekeeping duties under Article 75.

The two things that make crypto harder than the checklist suggests

The obligations read like standard financial-services resilience, but two features of a CASP change how they must be built.

The first is that the market never closes. A 24/7 order book and settlement flow has no banking-hours grace period in which to recover, and no chargeback to fall back on when something goes wrong. Continuity design that assumes an overnight maintenance window does not survive contact with a live exchange.

The second is private keys. They are the irreplaceable asset of the business: lose or leak them and the client assets are gone, irreversibly, with the firm liable under Article 75. This is the point supervisory inspections probe hardest, and it is where a generic ICT policy — written for a firm whose worst case is a database restore — falls apart. Key custody has to be engineered and evidenced as its own control domain.

What to do before the inspection, not during it

A supervisor’s first serious question is rarely “do you have a policy?” It is “show me this control operating, and show me the last time you tested it.” The firms that pass comfortably are the ones whose compliance register maps each MiCA and DORA obligation to an owner, a control, and the evidence that the control ran.

Building that register is the highest-value first move, because it forces a complete read of the firm’s obligations and surfaces the gaps before an inspector does. The common failure points are predictable: outsourcing critical functions without a DORA-compliant written contract, a continuity plan that has never been exercised, key-management controls that exist in a document but not in the signing workflow, and a third-party register that omits the cloud region the whole platform runs in.

None of this is a reason to slow the business down. It is a reason to treat operational resilience as an engineering deliverable with a supervisory deadline attached, rather than a compliance artifact produced after the fact.

Who this is for

This reading is for:

• CTOs and heads of engineering at authorised or in-flight CASPs
• Founders and COOs of Cyprus- and Malta-based crypto firms past the licensing stage
• Compliance leads who own the MiCA obligation register but not the systems behind it
• Boards of exchanges, custodians and brokers preparing for a first supervisory inspection

Sixteen Pillars builds the obligation-to-control-to-evidence register that turns Article 68 and DORA into something a supervisor will accept, and closes the ICT gaps before inspection. Pricing is published at /pricing/. If this is live for your organisation and you would like an independent reading, 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.