Security · Deadline Sep 11
In Ten Days, Silence Becomes a Reportable Event
On September 11 the EU's Cyber Resilience Act starts demanding that manufacturers tell a regulator within 24 hours when a vulnerability in their product is being actively exploited. Crypto's habit of patching quietly and explaining later was not designed with that clock in mind.
Ten days from now, a rule takes effect that nobody in crypto asked for and few in crypto have publicly prepared for. From September 11, 2026, Article 14 of the EU's Cyber Resilience Act requires manufacturers of products with digital elements to notify the European Union Agency for Cybersecurity and a national CSIRT within 24 hours of becoming aware that a vulnerability in their product is being actively exploited.
Twenty-four hours for an early warning. Seventy-two for a substantive notification. Fourteen days for a final report once a fix exists, or a month for a severe incident. Reports go through ENISA's Single Reporting Platform, and affected users — plus upstream component manufacturers — must be told as well. Fines run to €15 million or 2.5% of global annual turnover for breaching the reporting duty, with lower tiers for other obligations and for supplying false information. Authorities can also order corrective action, restrict sales, or recall a product from the EU market.
One point deserves emphasis before anyone in San Francisco or Singapore stops reading: this is not a rule for European companies. As Crowell & Moring puts it, manufacturers based inside or outside the EU that market connected products there are "equally fully subject to the regulation." The trigger is selling into the market, not being headquartered in it.
This is not the CRA's main event. Most of the substantive obligations — secure-by-design, conformity assessment, the CE marking that will gate market access — arrive on December 11, 2027. September 11 is the reporting clause arriving early, on its own, ahead of everything that would have made complying with it routine.
Whether this reaches crypto at all
The scope language is deliberately broad. Per the Commission's own summary, the CRA covers any "software or hardware product" with a "direct or indirect logical or physical data connection to a device or network," including components sold separately. Products not supplied commercially are excluded.
Read that against what this sector ships. A hardware signing device sold to European customers is a hardware product with a data connection. A wallet application distributed commercially is a software product. Node clients, custody platforms and exchange infrastructure sold as products sit inside that definition on its face. The duty applies regardless of when the product first launched, and importers and distributors carry notification duties of their own.
We should be careful here, because scope questions get decided by regulators rather than by inference. We found no published guidance from ENISA or the Commission addressing crypto wallets or node software specifically, and no public CRA compliance statement from any major hardware wallet manufacturer. That absence is worth reporting; it is not evidence either way about how the rule will land. What can be said plainly is that nothing in the scope language carves this industry out.
The open-source seam
The category that matters most for blockchain infrastructure is the one the CRA invented to solve a problem it created. Open-source developers spent two years arguing that a product-safety regime written for manufacturers would land on volunteers maintaining libraries for free. The compromise is the "open-source software steward" — as Red Hat's summary describes it, a legal person other than a manufacturer whose purpose is systematically providing sustained support for specific free and open-source products intended for commercial activities. Only a legal person can be one; a natural person cannot, which was drafted deliberately to keep individual volunteers out of the regime.
Stewards get lighter duties: document a cybersecurity policy, foster vulnerability reporting, handle what comes in. And from September 11 they carry the reporting obligation too — though the Commission's summary notes that stewards face no CRA penalties for non-compliance. The fines attach to manufacturers.
The exclusion has a hard edge that matters more than the steward carve-out. Open-source software is outside the CRA only when it is not supplied in the course of a commercial activity. Crowell's alert makes the consequence explicit: once open-source code is integrated into a product supplied commercially, that product's manufacturer must carry out appropriate due diligence on it. The library stays free; the obligation lands on whoever ships it in a box or a paid app.
Now apply that to how this industry is organised. A great deal of blockchain infrastructure is maintained by exactly the entity the steward category describes: a foundation providing sustained support for open-source software that commercial products are built on. Whether a given foundation is a steward, a manufacturer, or outside scope entirely is a question with a €15 million spread between the answers, and most have not said publicly which one they think they are.
What starts when, under Regulation (EU) 2024/2847
| Date | What applies |
|---|---|
| 10 Dec 2024 | Regulation enters into force |
| 11 Jun 2026 | Conformity assessment body rules |
| 11 Sep 2026 | Article 14 reporting — 24h / 72h / 14d |
| 11 Dec 2027 | Full application, incl. secure-by-design |
What the clock actually starts on
The most consequential detail is the trigger, and it is narrower than the headline suggests. The obligation is not to report every vulnerability. It attaches to vulnerabilities being actively exploited, and to severe incidents. Per Jones Day's reading, the clock starts when a manufacturer has "a reasonable degree of certainty" following initial assessment that exploitation or compromise has occurred.
There is also a limit that has been widely misread: there is no retroactive reporting duty for active exploitation a manufacturer already knew about before September 11. The rule catches what you learn from that date forward.
"Reasonable degree of certainty" is doing enormous work there. Anyone who has sat inside an incident in this sector knows the first hours are not a period of certainty about anything: you have anomalous transactions, a theory, and a team arguing about whether the theory explains them. The honest answer to "is this being exploited?" at hour three is frequently "we think so, and we are not sure how." The CRA does not require you to be sure. It requires you to start a clock once you reasonably are, and it puts the assessment of when that moment arrived in the hands of a regulator reading your timeline afterwards.
DLA Piper's guidance makes the same point from the compliance side — awareness turns on how quickly a team establishes the facts — and flags the case this sector should think hardest about: the first signal often arrives from someone else entirely, a distributor, an integrator, or a researcher who found it before you did.
Where this collides with how crypto works
This desk has spent the past week on the disclosure practices this rule intersects. When Cosmos EVM chains shipped a quiet backport and told operators afterwards, the defence — a reasonable one — was that a public advisory before validators had upgraded would have handed a live exploit to everyone watching. Embargo is not evasion. It is the technique the whole field converged on because loudly announcing an unpatched hole in software holding other people's money gets people robbed.
The CRA does not outlaw that technique, and it is important to be precise about this rather than dramatic. A report to ENISA and a CSIRT is a confidential regulatory notification, not a public advisory. A manufacturer can, in principle, notify the regulator inside 24 hours and still hold public disclosure until operators have patched.
What changes is that the embargo period now has a mandatory participant in it. The judgment about when to tell whom — until now made by maintainers weighing exploitation risk against patch readiness — acquires a fixed external deadline and an audience with enforcement powers. For an organisation with counsel and an incident process, that is paperwork. For a five-person team running a bridge at three in the morning, the early warning is a task that has to happen while the emergency is still on fire, and the fine for getting the timing wrong is scaled to global turnover.
There is a second-order effect worth watching. Notification duties create records, and records establish in a regulator's file precisely when a manufacturer knew what. In an industry where post-incident accounts have often been assembled generously after the fact, a timestamped statement to a government agency is a different artefact from a blog post written a week later.
What we do not know
Quite a lot, ten days out. How ENISA will interpret scope for products whose "manufacturer" is a foundation, a DAO, or a pseudonymous team. Whether any blockchain foundation has sought a determination on steward status. We know of no crypto-sector manufacturer that has published its CRA reporting procedure — though absence of a public statement is not absence of preparation. What is certain is the date, the trigger, the timelines and the fines, and none of those require anyone's interpretation to take effect on September 11.
The Take
The instinct here will be to read the CRA as Brussels misunderstanding how security works, and on the 24-hour clock that instinct has a point: the first day of an incident is the worst possible time to require an accurate account of it, and "reasonable degree of certainty" will be graded by people who were not in the room. But the deeper objection is harder to make with a straight face. Crypto's argument for controlling its own disclosure timing rests on the claim that maintainers are best placed to judge when telling the truth becomes safe. That claim is sound in principle and has been abused often enough in practice — quiet patches that stayed quiet after the risk had passed, incident reports that arrived when the narrative was ready rather than when the facts were. A confidential 24-hour notification does not break embargo. It removes the option of an embargo that never ends. An industry that has spent a decade telling people not to trust and to verify is about to find out how it likes being on the other side of that instruction, and it should be careful about which parts of this it calls unworkable — because the part that genuinely is hard, reporting under uncertainty at hour one, is not the part most of it has been quietly enjoying.