Written by Tommy Jamet, Head of Product at CoinCover
On 1 July 2026, the EU-wide ceiling of the transitional regime under the Markets in Crypto-Assets Regulation (MiCA) closes (several Member States have shortened it under Article 143(3)). After that date, the question every crypto-asset service provider (CASP) gets from a regulator changes shape. It stops being “do you have a plan?” It becomes “show me the last time you ran it.”
That shift is not a documentation problem. It’s a product problem.
Article 68(7) to (9) of MiCA and Articles 11, 25 and 26 of the Digital Operational Resilience Act (DORA) do not ask for a business-continuity policy. They ask for evidence of operation. Almost every architectural decision a custody product team is about to ship hangs off that distinction.
This piece sets out the architecture MiCA Article 68 and DORA force on custody product teams. Coincover is not itself a CASP and is not in scope of MiCA in its own right; what follows describes how the product enables our CASP customers to meet their obligations. Coincover Control already ships much of it: an access control list (ACL) quorum governing every recovery, ID-verified approvals, encrypted delivery, and audit logs streamed in real time to customer security information and event management (SIEM) systems. The packaged Recovery Evidence Pack, customer-set drill cadence, and decomposed recovery time objective (RTO) commitments sit on the current roadmap. What follows is the frame, not a product datasheet.
The bottom line
• The July 2026 cliff isn’t a documentation deadline. It’s a deadline for product features that produce regulator-grade evidence.
• “Tested recovery” stops being a document and becomes a continuously produced evidence stream.
• The RTO you publish only survives audit if every architectural component that adds latency is decomposed and backed by service-level agreements (SLAs).
Pillar 01 / Tested recovery
Tested recovery is a product feature, not a document
MiCA Article 68 and DORA Articles 11, 25 and 26 both ask for the same thing in different language: evidence the business-continuity plan (BCP) operates, not that it exists.
That distinction collapses the entire genre of BCP-as-document. The plan on the shelf is not what gets audited any more. The artifact the plan produces every time it runs is.
The recovery flow already produces that artifact every time a customer triggers it. The ACL quorum approval records, ID-verified identity timestamps, encrypted delivery records to the customer key, and the audit trail per operation are evidence objects. They survive an auditor’s inspection independent of any narrative the engineering team writes around them.
“The output is the evidence object, not the test.”
A SOC 2 (System and Organization Controls) Type I checks the plan exists. Type II checks it ran during the audit window. Neither gives you the live, customer-triggered evidence stream MiCA and DORA expect. The architectural shift July forces is from “happens when an auditor asks” to “happens on a schedule the customer sets, output the auditor can verify independently.”
Recent discovery calls with institutional operators flag interactive disaster recovery (DR) drill capability, with rehearsals on a customer-set cadence, as a procurement requirement. The buyer pressure is moving with the regulation.
The packaged evidence artifact, bundling incident declaration, approval logs, execution logs, and reconciliation into a single auditor-facing object, is the near-term direction. The components exist today in the recovery flow; the packaging is roadmap.
Pillar 02 / Decomposed RTO
The published RTO is the marketing number. The architectural RTO is what survives audit.
DORA Article 11 requires recovery objectives that are realistic and tested. Every custody product page on the internet has an RTO on it. Very few of those pages can decompose the number under questioning.
Decomposition is the engineering work the regulation actually forces.
A published RTO is a single number. The architectural RTO is at least four:
1. Multi-party reconstruction time. Set by the ACL threshold and signer reachability. A 2-of-3 quorum with three members reachable inside a short window is a different number than a 2-of-3 where one sits in a timezone you don’t cover. Threshold parameter, on-call rotation, and legal-letter override windows set it together.
2. Attestation latency. Every step in the recovery chain that produces an auditable attestation adds time. Encrypted delivery to the customer key is one. Hardware-rooted operations moving toward cryptographic enforcement inside an AWS Nitro Enclave will add bounded latency once that path lands. The honest number includes them.
3. Cold-vault retrieval. Federal Information Processing Standard (FIPS) 140-3 Level 3 devices in secure vaults inherit the vault’s physical access window. Legacy onboarding flows for cold material inherit the same. Both are measured in hours under normal operation, not minutes.
4. Signer availability windows. Timezone coverage, on-call rotations, jurisdictional reach. An ACL member with Persona-verified identity who cannot legally approve a recovery outside their home jurisdiction is a constraint on the published number, not a footnote.
Illustrative composition. Actual values vary by architecture and operational posture.
The four combine. The combination is the architectural RTO. The marketing RTO is whichever of the four is fastest, or the assumption that all four happen in parallel, which is not how any of them actually work.
“Your published RTO has to survive contact with the slowest signer in the chain.”
What a product team can safely commit to in public is the number that survives that contact. The regulator conversation receives the decomposed stack itself.
Pillar 03 / Continuous evidence
On-demand evidence is the drill. Continuous evidence is the product.
MiCA Article 75 requires CASPs to retain records of their services for at least five years. DORA Article 12 covers backup, restoration and recovery methods for information and communication technology (ICT) operational data, with retention periods set by sectoral rules and the relevant Level 2 RTS. Neither asks for an evidence package on demand. Both require it available continuously.
That is a different architecture from the one most custody teams have today.
The on-demand model is: regulator gives notice, engineering and compliance teams spend the week before the meeting pulling logs, normalising formats, and writing the narrative. The output is fresh every time. The cost is high every time. The moment a regulator visits unannounced the model fails.
The continuous model produces the same evidence as a side effect of normal operation. The audit feed already streams into customer-side SIEM systems in real time for select partner integrations. The transport is push over HTTPS, JSON payloads, with full event coverage that now includes key backup download events alongside every operation on the recovery flow. Each event carries the operation, the timestamp, the ACL members who approved it, and the cryptographic attestation that the operation completed inside the controlled boundary.
Illustrative. Under unannounced supervision the on-demand model fails entirely; the continuous model is unchanged.
The retention precedent exists today. Three-year operational retention ships for adjacent product surfaces. The roadmap direction is a versioned customer-readable feed across all customers, with five-year retention aligned to the longer end of the DORA bar.
“If the audit team has to ask the engineering team to generate the evidence, the regulator hasn’t met you yet.”
The architectural decision a custody team makes in May is the audit conversation it has in October.
Sources
Regulation (EU) 2023/1114 (MiCA), Article 68. Operational resilience requirements for crypto-asset service providers, including the business-continuity policy.
eur-lex.europa.eu/eli/reg/2023/1114/oj
Regulation (EU) 2023/1114 (MiCA), Article 143(3). Transitional regime allowing prior-law service providers to continue operating until 1 July 2026.
eur-lex.europa.eu/eli/reg/2023/1114/oj
Regulation (EU) 2023/1114 (MiCA), Article 75. Record-keeping by CASPs; minimum five-year retention of records of services, activities, orders and transactions. eur-lex.europa.eu/eli/reg/2023/1114/oj
Regulation (EU) 2022/2554 (DORA), Article 11. ICT business-continuity policy, response and recovery objectives.
eur-lex.europa.eu/eli/reg/2022/2554/oj
Regulation (EU) 2022/2554 (DORA), Article 12. Backup policies, procedures, restoration and recovery procedures and methods.
eur-lex.europa.eu/eli/reg/2022/2554/oj
Regulation (EU) 2022/2554 (DORA), Articles 25 and 26. ICT testing of tools and systems; advanced testing based on threat-led penetration testing (TLPT).
eur-lex.europa.eu/eli/reg/2022/2554/oj
Disclaimer. This article is provided for general information only and does not constitute legal, regulatory or compliance advice. Coincover is operated by Digital Asset Services Ltd, a UK-based non-custodial service provider. It is not a crypto-asset service provider and is not authorised under MiCA. References to MiCA and DORA describe obligations on our customers, not on Coincover itself.
About the author
Tommy Jamet is Head of Product at CoinCover, where he leads the development of secure, scalable digital asset protection solutions for institutions and crypto businesses. He is particularly passionate about AI-powered product intelligence, graph databases, and modern product infrastructure built on technologies such as Next.js, Supabase, and Vercel.