DORA for Crypto Companies: What the Regulation Requires

By the Guardian team Updated November 2026 5 min read

Quick answer. Since January 17, 2025, DORA has required MiCA-authorized CASPs and ART issuers to manage ICT risk, report major incidents, test critical systems yearly and manage ICT vendors. Sharing threat intelligence is voluntary.

Watch: DORA for Crypto Companies: What the Regulation Requires 1:49

Video transcript

Since January 17, 2025, DORA has applied to MiCA-authorized crypto firms. Here is what it requires, pillar by pillar.

DORA covers CASPs authorized under MiCA and issuers of asset-referenced tokens. CASPs get the full framework, unless they are microenterprises.

Pillar one is ICT risk management. Our reading: wallets, signers, nodes and contracts are ICT assets. Map them, scan weekly, review access every six months and test recovery yearly.

Pillar two is incident reporting. A drained hot wallet will usually count as major, and the first notification is due within 4 hours of classification.

After the initial notice, an intermediate report follows within 72 hours, and a final report within one month. Affected clients must be told without undue delay.

Pillar three is yearly testing of critical systems. For crypto, that means code review for contracts, pentests for signers and withdrawal APIs, and scenario tests for key compromise.

Pillar four is third-party risk. You stay fully responsible, so custody, RPC and cloud providers go in your ICT register. Pillar five, threat sharing, is voluntary.

Start by naming critical functions, mapping the assets behind them, and dry-running a hot wallet drain against the 4-hour clock.

Guardian's Operational Resilience assessment maps those functions, exercises scenarios like key compromise, and builds your third-party register. Our audits and pentests supply testing evidence.

Read the full article for the pillar-by-pillar checklist, or talk to Guardian at guardian.security.

DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), has applied since January 17, 2025 (Article 64).

It reaches crypto firms through their license. Article 2(1)(f) covers CASPs authorized under MiCA and issuers of asset-referenced tokens (ARTs).

This guide is a pillar-by-pillar DORA checklist for wallets, signers, nodes and smart contracts. For which duties sit in MiCA and which in DORA, see MiCA and DORA.

This article explains the technical and security side of DORA (Regulation (EU) 2022/2554). It is not legal advice; confirm how it applies to you with counsel.

Who Is in Scope

Three facts set how much of DORA applies to a crypto firm:

License: CASPs and ART issuers under Article 2(1)(f); EMT issuers as banks or e-money institutions.
Full framework: CASPs are not on Article 16's simplified list, so Articles 5 to 15 apply.
Size: microenterprises (under 10 staff, at most EUR 2 million turnover or balance sheet) get lighter duties.

Most duties hang on your "critical or important functions" (Article 3(22)). Our reading: for a CASP, custody, signing, withdrawals and trading are likely candidates.

ICT Risk Management

Pillar one, Articles 5 to 16, is the base for the rest. The management body bears "the ultimate responsibility" for ICT risk (Article 5(2)).

Duty	Cadence	Source
Documented ICT risk framework	Reviewed at least yearly and after major incidents	Article 6(5)
Map of functions, ICT assets and dependencies	Reviewed at least yearly	Article 8(1)
Strong authentication and key protection	Ongoing	Article 9(4)(d)
Key lifecycle controls and a way to replace lost keys	Ongoing	RTS 2024/1774, Article 7
Access rights review on critical systems	At least every 6 months	RTS 2024/1774, Article 21
Automated vulnerability scans of critical assets	At least weekly	RTS 2024/1774, Article 10(2)
Continuity and recovery plans tested	At least yearly	Article 11(6)

DORA defines an ICT asset as "a software or hardware asset in the network and information systems used by the financial entity" (Article 3(7)).

Our reading: that includes hot and cold wallets, MPC or HSM signing, nodes, RPC endpoints and the smart contracts your services run on. Give each one an owner in the asset map.

Incident Reporting

Pillar two, Articles 17 to 23, starts with classification. A major incident hits critical services and meets one of two tests.

Access: successful, malicious, unauthorized access that may cause data losses.
Thresholds: two or more of the other materiality thresholds (RTS 2024/1772, Article 8).

Those thresholds include more than 10% of a service's clients, over 2 hours of downtime on critical systems and losses above EUR 100,000 (Article 9).

Our reading: a drained hot wallet or a compromised signer will usually meet the access test, and often the EUR 100,000 one.

Report	Deadline (RTS 2025/301, Article 5)
Initial notification	Within 4 hours of classification, and 24 hours of awareness
Intermediate report	Within 72 hours of the initial notification
Final report	Within one month of the latest intermediate report

If a deadline falls on a weekend or bank holiday, most firms may file by noon the next working day (Article 5(4)).

That relief does not cover initial and intermediate reports from banks, NIS2 essential or important entities, or firms your authority names as significant (Article 5(5) and (6)).

Affected clients must be told "without undue delay" (DORA Article 19(3)). Significant cyber threats may be reported voluntarily (Article 19(2)).

Resilience Testing

Pillar three, Articles 24 to 27, needs a risk-based testing program run by independent testers.

Yearly: appropriate tests on all systems supporting critical or important functions (Article 24(6)).
Fixes: every issue classified, remedied and confirmed fully addressed (Article 24(5)).
Methods: scans, scenario tests, "source code reviews where feasible" and penetration testing (Article 25(1)).
TLPT: at least every 3 years, only for firms their authority identifies (Article 26(1)).

On a crypto stack: code review for contracts, pentests for signing services and withdrawal APIs, and scenario tests for key compromise.

For depth, see DORA penetration testing requirements and whether smart contract audits count.

Pillar four: third-party risk

Outsourcing moves work, not accountability. You stay "fully responsible" for compliance (Article 28(1)(a)).

A third-party risk strategy, unless you are a microenterprise (Article 28(2)).
A register of every ICT contract, in the ITS 2024/2956 templates (Article 28(3)).
Due diligence before signing, Article 30 contract terms and exit plans for critical services.

Our reading: custody and MPC providers, node and RPC providers, cloud, blockchain analytics and KYC vendors all belong in the register.

For how these duties stack with MiCA's outsourcing rules, and the ESAs' list of critical providers, see MiCA and DORA.

Financial entities may share threat intelligence, such as indicators of compromise and attacker tactics, within trusted communities (Article 45(1)).

It is voluntary. Notify your authority when you join or leave an arrangement (Article 45(3)).

Where to Start

Check whether you are a microenterprise, and whether your authority has identified you for TLPT.
Name critical or important functions and map the wallets, signers, nodes and contracts behind them.
Turn on weekly automated scans and six-monthly access reviews for those systems.
Test key replacement and your recovery plans, and time the restore.
Dry-run a hot wallet drain against the RTS 2024/1772 thresholds and the 4-hour clock.
Schedule yearly tests of every critical system, with each fix retested.

For the control-by-control list, see the MiCA compliance checklist. For the MiCA basics, see What Is MiCA?

How Guardian Helps

Guardian's Operational Resilience assessment names your critical or important functions the way DORA does.

It maps the people, systems and third parties behind each, including RPC endpoints, oracles, bridges and custodians.

It exercises severe but plausible scenarios, such as key compromise, an unreachable signer quorum and a chain halt, as tabletops and technical tests.

It also produces your register of ICT third parties and rehearses the path to file incident reports on time.

Guardian's audits and pentests supply testing evidence. Managed Security monitors contracts on every block, with a Guardian engineer responding around the clock.

Frequently Asked Questions

Does DORA apply to crypto companies?

Yes, to CASPs authorized under MiCA and issuers of asset-referenced tokens (Article 2(1)(f)), since January 17, 2025. E-money token issuers are covered as credit or e-money institutions.

Do crypto firms have to run TLPT under DORA?

Only if their competent authority identifies them (Article 26(8)). Every CASP that is not a microenterprise still needs appropriate tests, at least yearly, of all systems supporting critical or important functions (Article 24(6)).

How fast must a CASP report a major ICT incident?

Within 4 hours of classifying it as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours, and a final report within a month (RTS 2025/301, Article 5).

Does DORA cover our custody or RPC provider?

Directly, only if the ESAs designate it as a critical ICT provider (Article 31). Your contract with it is covered either way: record it in the register, assess it before signing and include the Article 30 terms.

Sources

Build a DORA program that fits a crypto stack

Guardian maps your functions, vendors and chains, exercises the scenarios that matter and tests the systems behind them.

Talk to Guardian Explore regulatory compliance