Sector · Manufacturing
Rules · 2026-11-02 · 3 min read
The CRA's 24-hour reporting rule came into force in September 2026
Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to ENISA within 24 hours of becoming aware of them. Here's what that means in practice.
When the clock started
On 11 September 2026, manufacturers of products with digital elements picked up a new duty: to report certain vulnerabilities and incidents to ENISA, the EU Agency for Cybersecurity, through its common reporting platform. [2] The product security requirements in Annex I of the Cyber Resilience Act don't apply until 11 December 2027, but the reporting obligations are already here. [1]
The 24-hour deadline works like when you lose your bank card. The clock starts when you notice it's gone, not when it's convenient. If a manufacturer becomes aware of an actively exploited vulnerability at 14:00 on a Tuesday, the early warning is due by 14:00 on Wednesday. Miss that and a supervisor can ask why, and the answers had better be good.
What has to be reported
The regulation sets out three triggers, each with its own deadline. [2]
First, an actively exploited vulnerability: a weakness that someone is actually using in the wild to compromise products. That gets an early warning within 24 hours of the manufacturer becoming aware. If the vulnerability is in a component from someone else, the manufacturer still has to report it.
Second, a severe incident: one that causes or is likely to cause a significant operational disruption or financial loss, or harms users' health, safety or fundamental rights. Again, 24 hours.
Third, updates. Within 72 hours, the manufacturer sends an incident notification with more detail. Within 14 days, a final report or an intermediate one if the investigation is still going. Each step is recorded on the platform.
When you knew
The hard question is often when the manufacturer became aware. Article 14 says the deadlines run from that moment, and in a dispute over a late report, the other side will ask for evidence. [2]
A detection note written three hours after the fact, or a log entry edited the next morning, is easy to challenge. That's the problem with records you can change: people do.
The timeline is the thing to seal. When an engineer first flags something unusual, seal a note of it. When the team decides to escalate, seal that decision. When the report goes out, seal a copy. Each step gets a permanent, checkable timestamp, and if someone later claims you knew on Monday but only reported on Wednesday, the sealed timeline answers the question.
How a sealed timeline works
Here, the thing to seal is each step as it happens: the first detection note, the decision to escalate and each report as it is sent.
Sealing takes a fingerprint of the record, not the record itself, so the content never leaves your systems. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. If the timeline is questioned months later, anyone you share it with can recalculate the fingerprints and check that the records are exactly what they were on the day.
The first 2,000 witnesses a month are free. Read the docs.
What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. What it doesn't show is that the report was complete or that the response was adequate. Those are separate questions.
How it would work
- Seal the first detection note when it's written.
- Seal the escalation decision and the outgoing report.
- If questioned, share the sealed records and let the other side check the fingerprints.
What this means for you
If you make products with digital elements, ask yourself these questions:
- Do we have a process for deciding when we became aware of something?
- Can we show, later, that we detected an issue when we say we did?
- Do we know which products count as having digital elements under the regulation, and which don't?
- Have we tested reporting through ENISA's platform?
The fines for non-compliance go up to €15 million or 2.5% of global annual turnover. [1] A sealed timeline doesn't make you compliant, but it does mean you can show when you knew and when you reported, in a form that's hard to argue with.
What to watch
The product security requirements in Annex I come into force on 11 December 2027. [1] Those requirements include the ability to log and monitor security-relevant events, and vulnerability handling throughout the product's support period. Worth getting the reporting process right now, before the rest lands.