Cyber Resilience Act Reporting Obligations for Crypto Teams
Quick answer. Since September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents via ENISA's Single Reporting Platform. Both get 24-hour and 72-hour notices; final reports follow 14 days after a fix, or one month for incidents.
Video transcript
Since September 11, 2026, wallet, node and SDK makers selling in the EU must report active exploitation within 24 hours. That covers products already on the market.
Breaching Article 14 can draw fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher.
Two triggers apply: an actively exploited vulnerability, or a severe incident, like malicious code in your update channel. Audit and bug bounty findings need no mandatory report.
Both need an early warning within 24 hours of awareness and a notification within 72. Final reports follow 14 days after a fix, or one month after notification for incidents.
Per the Commission's guidance, wallet apps, browser extension wallets and hardware wallets are products. Free open source counts only when monetized.
Detection decides how much of those 24 hours you keep, because the clock starts at awareness.
Set up access to ENISA's reporting platform now. Name who decides you are aware, and log evidence. Then file on time, ship a fix, tell impacted users, and file the final report.
Guardian's Managed Security monitors contracts on every block, Sentry watches domains and DNS, and an engineer responds with a 15-minute SLA on Critical alerts. Notification packs gather the facts for you to file.
This is a technical guide, not legal advice. Read the full article, or talk to Guardian at guardian.security.
The EU's Cyber Resilience Act (Regulation (EU) 2024/2847) has been in force since December 10, 2024. Most of it applies from December 11, 2027.
Its reporting duty, Article 14, has applied since September 11, 2026.
It can reach wallet apps, hardware wallets, node clients and SDKs supplied commercially in the EU, including products already on the market.
So an in-scope wallet maker that becomes aware of active exploitation tonight already has a 24-hour clock.
This article explains the technical and security side of the Cyber Resilience Act's reporting obligations (Article 14 of Regulation (EU) 2024/2847). It is not legal advice; confirm how it applies to you with counsel.
What Applies and When
| Date | What applies |
|---|---|
| December 10, 2024 | The regulation enters into force |
| September 11, 2026 | Article 14 reporting, through ENISA's platform |
| December 11, 2027 | Everything else, including vulnerability handling and steward reporting |
Article 69(3) applies Article 14 to every in-scope product placed on the market before December 11, 2027. Per the Commission, reporting also continues after a product's support period ends.
It is not retroactive. Exploitation you knew of before September 11, 2026 need not be reported; exploitation you learn of later must be, even for a known bug.
Breaching Annex I, Article 13 or Article 14 can draw fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)).
Two Triggers
Actively exploited vulnerabilities
There must be "reliable evidence that a malicious actor has exploited it in a system without permission of the system owner" (Article 3(42)).
Flaws found in good-faith testing, such as an audit or a bounty report, are not subject to mandatory notification (recital 68). You may still report them voluntarily (Article 15).
Exploited flaws in third-party components inside your product count. Per the Commission, a library flaw that cannot be, or has not been, exploited in your product does not.
Severe incidents
An incident affecting the product's security is severe where it (Article 14(5)):
- harms, or could harm, the product's protection of sensitive or important data or functions; or
- has led, or could lead, to malicious code running in the product or on a user's systems.
Recital 68 gives an example: an attacker who introduces malicious code into the channel that ships your security updates.
When the clock starts
The Commission says you become aware when an initial assessment gives you "a reasonable degree of certainty" of exploitation or a severe incident. You should start that assessment immediately.
The Three Reports
| Report | Exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of awareness | Within 24 hours, saying if unlawful or malicious acts are suspected |
| Notification | Within 72 hours: the product, exploit and mitigations | Within 72 hours: an initial assessment and mitigations |
| Final report | 14 days after a fix or mitigation is available | One month after the 72-hour notification |
Final reports cover severity, impact and the fix, or for incidents the likely root cause and mitigations (Article 14(2)(c) and 14(4)(c)). The CSIRT may also request an intermediate report.
Where to file
Every report goes through ENISA's Single Reporting Platform, operational since September 11, 2026.
It reaches the CSIRT designated as coordinator where your main EU establishment is, and ENISA at the same time (Article 14(7)).
Manufacturers with no main EU establishment follow an order that starts with their authorized representative's Member State.
Flag sensitive details. In exceptional circumstances, in particular on your request, the CSIRT may delay sharing your notice on justified cybersecurity grounds, for no longer than strictly necessary (Article 16(2)).
Tell users
Article 14(8) requires you to inform impacted users, and where appropriate all users, including, where necessary, mitigations they can deploy.
The Commission reads this as risk-based: details can go to affected users first. If you are too slow, the CSIRT may inform users itself.
Who Is the Manufacturer
Neither the CRA nor the Commission's guidance mentions blockchains or smart contracts. Scope turns on the product, the commerce and who markets it.
The CRA covers "a software or hardware product and its remote data processing solutions" (Article 3(1)).
It must connect to a device or network and be supplied in the course of a commercial activity (Articles 2(1), 3(22)).
| Software | Reading in the Commission's guidance |
|---|---|
| Mobile or desktop wallet | A product: it runs on the user's device |
| Browser extension wallet | A product: the guidance names browser extensions |
| Hardware wallet | A product: hardware with embedded software |
| Backend your app calls | Part of the product, if built by or for you and the app needs it |
| Web wallet used only in a browser | Not a product on its own |
| Third-party API or SaaS | Not remote data processing; treat it as a third-party component |
Node clients, SDKs and open source
Recital 18 says free and open-source software that its manufacturer does not monetize is not supplied commercially. The guidance draws the lines:
- Contributors to a project they do not control are outside the CRA.
- A project funded only by donations is unlikely to be placed on the market.
- Charging for binaries or a supported edition makes you the manufacturer of what you sell.
- A free app that monetizes other services through it is placed on the market.
- Optional paid support alone does not place free software on the market.
The guidance's example of a monetizing free app is a marketplace earning commission fees. Wallets with built-in swap fees should test themselves against it with counsel.
Open-source stewards
A steward is a legal person, other than a manufacturer, that supports free software intended for commercial activities on a sustained basis, such as certain foundations (Article 3(14), recital 19).
Stewards owe a documented cybersecurity policy and cooperation with authorities (Article 24).
Per the Commission, their reporting starts December 11, 2027, and covers only development they take part in or infrastructure they provide.
Detection and the Runbook
The clock starts at awareness, so detection decides how much of the 24 hours you keep. Signals that can start it:
- Users report transactions they did not sign.
- Funds flow from many users' addresses to one destination.
- A malicious build appears in an app store, extension store or package registry.
- A CSIRT tells you someone else reported exploitation of your product (Article 15(4)).
- An integrator reports exploitation of your SDK.
The runbook
- Set up Single Reporting Platform access and early-warning templates now.
- Name who decides "aware", and log the time and evidence.
- File the early warning within 24 hours and the notification within 72.
- Ship a fix or mitigation; a vulnerability's 14-day clock starts then.
- Tell impacted users, with steps they can take now.
- File the final report, then plan disclosure of the fixed flaw.
Keep the evidence each report asks for: the timeline to awareness, affected versions and build hashes, exploit transactions, attacker indicators and user notices.
See also writing an incident response plan and what a wallet pentest should cover.
How Guardian Helps
Guardian's Managed Security monitors contracts on every block, and Sentry watches domains, DNS, certificates, cloud and code host. A Guardian engineer responds, with a 15-minute SLA on Critical alerts.
Guardian also matches new vulnerability disclosures to what you run, and runs your bug bounty with every report triaged.
Managed Security's incident timelines and regulator notification packs gather the facts a first notice asks for, ready for you to file.
For wallet and SDK teams, browser extension pentests and SDK audits test signing flows, key storage and release control.
Frequently Asked Questions
Does the Cyber Resilience Act apply to crypto wallets?
Wallet apps, browser extensions and hardware wallets are products with digital elements, covered when supplied commercially in the EU. The Commission's guidance says a web app used only in a browser is not a product on its own.
Do open-source projects have to report under the CRA?
Only manufacturers report from September 2026, and free software is supplied commercially only when monetized. Contributors are outside the CRA. Stewards' limited reporting under Article 24(3) starts December 11, 2027, per the Commission.
Does CRA reporting cover products sold before December 2027?
Yes. Article 69(3) applies Article 14 to in-scope products placed on the market before December 11, 2027, and the Commission says reporting continues after support ends.
Sources
- Official Journal of the EU: Regulation (EU) 2024/2847, Cyber Resilience Act (November 20, 2024)
- European Commission: Commission guidance on the application of the Cyber Resilience Act, C(2026) 5252 (July 27, 2026)
- European Commission: Cyber Resilience Act, reporting obligations (updated September 11, 2026)
- European Commission: Cyber Resilience Act, implementation timeline (updated July 27, 2026)
- ENISA: CRA Single Reporting Platform (SRP)
- Guardian: Managed Security
- Guardian: Regulatory & Compliance Assessments
- Guardian: Audits & Pentests
- Guardian: Guardian Announces Managed Security
Be ready for the 24-hour clock
Guardian watches your contracts and offchain infrastructure around the clock, and an engineer responds when something fires, so your first report starts from facts.