MiCA Compliance Checklist: Security Controls for CASPs
Quick answer. MiCA sends CASPs to DORA for ICT security. Core controls: an ICT risk framework, key and custody controls, yearly independent tests of critical systems, major-incident notices within 4 hours of classification, a third-party register and tested continuity plans.
Video transcript
MiCA sends crypto-asset service providers to DORA for ICT security. Here are the controls, and the evidence to keep.
MiCA sets what a CASP must achieve. For ICT security, it points to DORA, which has applied to authorized CASPs since January 2025.
The checklist runs through five areas: governance, custody and keys, testing, incident reporting, and continuity.
Custody is where MiCA is most specific: a custody policy, key approvals including multisig, client assets segregated onchain, and a way to replace lost or compromised keys.
Under MiCA, a custodian is liable for losses from an incident attributable to it, up to the asset's market value at the time.
Under DORA, critical systems need yearly independent tests, validated fixes, and weekly automated scans. Your application describes any third-party audit, ideally with pentests and, for smart contracts, a code review.
Incidents run on a tight clock. The initial notice is due within 4 hours of classifying one as major. An intermediate report follows within 72 hours, and a final report within a month.
Last, continuity and vendors: a continuity policy reviewed yearly, recovery plans per critical function, cyber-attack exercises, segregated restores, a third-party register, and exit strategies.
Guardian's regulatory assessments map each provision to the control that meets it, the evidence that proves it, and any gap. Read the full article, or talk to Guardian at guardian.security.
MiCA (Regulation (EU) 2023/1114) has applied in full since December 30, 2024. Its transitional period for existing CASPs ended on July 1, 2026 at the latest (Article 143(3)).
DORA (Regulation (EU) 2022/2554) has applied since January 17, 2025. It covers CASPs authorized under MiCA (Article 2(1)(f)).
This checklist covers only the security side: each control, its article, and the evidence to keep.
This article explains the technical and security side of MiCA (Regulation (EU) 2023/1114) and DORA (Regulation (EU) 2022/2554) for crypto-asset service providers. It is not legal advice; confirm how it applies to you with counsel.
How MiCA and DORA Split It
MiCA sets what a CASP must achieve and file. For ICT, it points to DORA.
- Authorization: Article 62(2)(j) and RTS 2025/305 Article 9 require ICT documentation, including how you comply with DORA.
- Continuity: Article 68(7) requires "resilient and secure ICT systems as required by" DORA.
- Data security: Article 68(8) requires data safeguards "pursuant to" DORA.
- Custody: Articles 70 and 75 are MiCA's own safekeeping and custody rules.
- Outsourcing: Article 73 sits alongside DORA's third-party rules.
- Trading platforms: Article 76(7) requires resilient, fully tested trading systems.
Several DORA duties are lighter for microenterprises. The tables below assume a CASP that is not one.
"Critical" in the tables means supporting critical or important functions.
Governance and ICT Risk
Start with who owns ICT risk, and what they can see.
| Control | Source | Evidence to keep |
|---|---|---|
| Management body bears ultimate responsibility for ICT risk | DORA Art. 5(2) | Board approvals and minutes |
| Documented ICT risk framework, reviewed at least yearly | DORA Art. 6(5) | Framework and review report |
| Independent ICT risk control function and internal audit | DORA Art. 6(4), 6(6) | Mandates and audit reports |
| Inventory and map of ICT assets and dependencies | DORA Art. 8 | Asset register and yearly review |
| Least-privilege access rights, updated at least every 6 months on critical systems | RTS 2024/1774 Art. 21 | Access review exports |
| Strong authentication for privileged and remote access | DORA Art. 9(4)(d); RTS 2024/1774 Art. 21 | MFA coverage report |
| Controlled change management and patching | DORA Art. 9(4)(e), (f) | Change approvals, patch records |
Custody and Key Management
Custody is where MiCA is most specific.
| Control | Source | Evidence to keep |
|---|---|---|
| Custody policy minimizing loss from fraud, cyber threats or negligence | MiCA Art. 75(3) | Policy and client summary |
| Approval system and safeguarding for keys, including multisig | RTS 2025/305 Art. 10(1)(b) | Signer inventory and approval flows |
| Client assets held separately from your own onchain | MiCA Art. 75(7) | Wallet and address register |
| Key controls from generation to destruction | RTS 2024/1774 Art. 7(1), (2) | Key ceremony and rotation records |
| A method to replace lost or compromised keys | RTS 2024/1774 Art. 7(3) | A tested key recovery |
| Procedures to return client assets as soon as possible | MiCA Art. 75(6) | Return procedure, exercised |
Liability raises the stakes. A custodian is liable for losses from an incident attributable to it, up to the asset's market value at the time (Article 75(8)).
Testing and Vulnerabilities
The application describes what you have tested. DORA sets the ongoing program.
| Control | Source | Evidence to keep |
|---|---|---|
| Yearly tests of all systems supporting critical or important functions | DORA Art. 24(6) | Test plan and reports |
| Independent testers, internal or external | DORA Art. 24(4) | Independence statement |
| Every finding classified, fixed and validated | DORA Art. 24(5) | Findings register with retests |
| Appropriate tests, such as scans, pentests and source code reviews where feasible | DORA Art. 25(1) | Reports by system |
| Weekly automated scans of critical ICT assets | RTS 2024/1774 Art. 10(2) | Scan history |
| Library tracking and responsible disclosure procedures | RTS 2024/1774 Art. 10(2) | Dependency inventory, disclosure policy |
| Threat-led penetration testing (TLPT) every 3 years, if your authority identifies you | DORA Art. 26 | TLPT attestation |
For authorization, RTS 2025/305 Article 9(b) asks you to describe any third-party cybersecurity audit, if one is available.
It should ideally cover black, grey and white box pentests and, where you use or develop smart contracts, "a cybersecurity source code review of them".
Go deeper: DORA penetration testing requirements and whether smart contract audits count under DORA.
Incident Handling and Reporting
DORA's 4-hour clock starts when you classify an incident as major.
| Control | Source | Evidence to keep |
|---|---|---|
| Detection with alert thresholds and automatic alerts | DORA Art. 10 | Detection coverage map |
| Incident process with early warning indicators and roles | DORA Art. 17 | Incident log and playbooks |
| Classification against the major-incident criteria | RTS 2024/1772 Art. 8 | Dated classification decisions |
| Initial notice within 4 hours of classification, at most 24 after awareness | RTS 2025/301 Art. 5 | Timestamped filings |
| Intermediate report within 72 hours of the initial notice; final within one month | RTS 2025/301 Art. 5 | Filed reports |
| Clients told without undue delay when a major incident affects their financial interests | DORA Art. 19(3) | Client notices |
An incident is major when it affects critical services and either involves malicious unauthorized access that may cause data losses, or meets two other thresholds.
Those include more than 10% of a service's clients, over 2 hours of downtime for services supporting critical functions, and costs and losses above EUR 100,000 (RTS 2024/1772 Article 9).
Classify late, after the first 24 hours, and the 4 hours run from classification (RTS 2025/301 Article 5(2)).
Run a hot wallet compromise through these criteria now, not during the incident.
Continuity and Third Parties
Last, staying up, and the vendors you cannot run without.
| Control | Source | Evidence to keep |
|---|---|---|
| Continuity policy endorsed and reviewed yearly by the management body | RTS 2025/299 Art. 2 | Policy and annual review |
| Plans with recovery deadlines and recovery point objectives | RTS 2025/299 Art. 4(2) | A plan per critical function |
| Client updates when a permissionless ledger is disrupted | RTS 2025/299 Art. 4(3) | Message templates |
| Yearly tests, with cyber-attack and switchover scenarios | DORA Art. 11(6); RTS 2025/299 Art. 5 | Exercise records |
| In-house restores onto physically and logically segregated systems | DORA Art. 12(3) | Timed restore records |
| Register of all ICT third-party contracts | DORA Art. 28(3) | The register of information |
| Outsourcing policy with contingency plans and exit strategies | MiCA Art. 73(2) | Policy and exit plans |
For how these rules compare with GENIUS, NYDFS and VARA, see Crypto Regulatory Compliance.
How Guardian Helps
Guardian's Regulatory & Compliance assessments map your activities to MiCA authorization, then list every technology, security, custody and resilience provision by citation.
Each provision gets the control that meets it, the evidence that proves it, and the gap where neither exists.
Guardian writes the ICT, security, custody and continuity sections of an authorization file from the system as built, and orders the gaps the way an examination will read them.
Guardian's audits, pentests and Managed Security leave dated evidence. An audit with fix review maps to RTS 2025/305 Article 9; key custody and multisig records map to MiCA Article 75(3).
Frequently Asked Questions
Does DORA apply to crypto-asset service providers?
Yes. DORA Article 2(1)(f) covers CASPs authorized under MiCA, and it has applied since January 17, 2025. MiCA Article 68 also requires CASPs' ICT systems and data safeguards to meet DORA.
Does MiCA require a penetration test?
Not directly. RTS 2025/305 Article 9(b) asks applicants to describe any third-party cybersecurity audit, ideally including pentests. The yearly testing duty, which lists penetration testing, comes from DORA Articles 24 and 25.
How fast must a CASP report a major ICT incident?
The initial notice is due within 4 hours of classifying it as major, and within 24 hours of awareness. The intermediate report follows within 72 hours of that notice; the final report, within a month of the latest intermediate report.
What does MiCA require for key management?
Article 75(3) requires a custody policy that minimizes the risk of losing clients' crypto-assets or means of access through fraud, cyber threats or negligence. Applicants also describe their key approval system, including multisig (RTS 2025/305). DORA adds lifecycle key controls.
Sources
- Official Journal of the EU: Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA) (published June 9, 2023)
- Official Journal of the EU: Commission Delegated Regulation (EU) 2025/305, RTS on CASP authorization applications (published March 31, 2025)
- Official Journal of the EU: Commission Delegated Regulation (EU) 2025/299, RTS on continuity and regularity of crypto-asset services (published February 13, 2025)
- Official Journal of the EU: Regulation (EU) 2022/2554, Digital Operational Resilience Act (published December 27, 2022)
- Official Journal of the EU: Commission Delegated Regulation (EU) 2024/1774, RTS on ICT risk management (published June 25, 2024)
- Official Journal of the EU: Commission Delegated Regulation (EU) 2024/1772, RTS on classifying ICT incidents (published June 25, 2024)
- Official Journal of the EU: Commission Delegated Regulation (EU) 2025/301, RTS on major ICT incident reporting (published February 20, 2025)
- Guardian: Regulatory & Compliance Assessments
Map your security controls to MiCA and DORA
Guardian tests your custody, contracts and systems, then maps the evidence to each MiCA and DORA provision.