CRA's 24-hour clock starts when you know, not when it suits you

Reporting rules are full of deadlines, but the hard part is knowing when the clock started. CRA's 24 hours works like when you lose your bank card: the clock starts when you notice it, not when it's convenient.

On 11 September 2026, the Cyber Resilience Act starts applying to manufacturers of products with digital elements. That covers connected hardware and software, though not medical devices or vehicles with type approval. Article 14 sets out what to report and when, in steps with short deadlines ^[1].

The early warning: 24 hours from awareness

When a manufacturer becomes aware that a vulnerability in its product is being actively exploited, it must submit an early warning to ENISA's single reporting platform within 24 hours. The early warning doesn't need to be complete. It needs to be timely.

The phrase "becomes aware" matters, because it puts the burden on the manufacturer to notice and act. It doesn't say "within 24 hours of the exploit", it says within 24 hours of becoming aware of it. That means detection, internal escalation and the first report all need to happen quickly.

What happens next

After the early warning, the manufacturer has 72 hours from becoming aware to submit a more detailed incident notification. If the vulnerability affects other manufacturers' products as well, they must be notified without undue delay.

Within 14 days, a final report is due, unless ENISA agrees to an extension. The final report should include a detailed description, the severity, the affected products and any mitigation measures.

For severe incidents that weren't necessarily tied to an exploited vulnerability, the steps are similar: early warning within 24 hours, incident notification within 72 hours, final report within a month ^[1].

The evidence question

Supervisors will ask when you knew. If the early warning went out after 30 hours instead of 24, the question becomes: when did the detection happen, when was it escalated, and why did it take that long?

A detection note written three hours after the event looks very different from one written the next morning and timestamped to look earlier. The problem is that the people writing the notes are the same people who could change them.

When you knew, and when you reported

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 to ENISA's platform. Sealing takes a fingerprint of the record, not the record itself, so the content stays in your systems.

Anyone you share the record with can later check that it's the one written at the time you say it was. If it's questioned a year later, the sealed fingerprint shows whether the record has changed.

A digital witness doesn't show that the report was complete or that your response was adequate. It shows when each step was recorded, in a way nobody can quietly rewrite afterwards.

You seal through WitniumChain: send a fingerprint of the detection note, the escalation decision or the report through the REST API, the SDK or the MCP server, and get a witness ID back. To check, you calculate the fingerprint again and compare it with the sealed one. The content never leaves your systems. The first 2,000 witnesses a month are free, and the documentation shows you how to get started.

How it would work

1. Your monitoring tool detects that a vulnerability is being exploited and writes a detection note. You seal the note at that moment.
2. The security team decides to escalate. You seal the escalation decision.
3. You send the early warning to ENISA. You seal a copy of what was sent, with the timestamp.

If a supervisor later asks why it took 30 hours, you can show the sealed records and let them see for themselves.

What this means for you

If you manufacture products with digital elements, here are three questions to ask now:

• Do we have a process for detecting when a vulnerability in our product is being actively exploited, and does it run continuously?
• Who decides when we've "become aware", and how quickly can they escalate to the team that files the report?
• Could we show, a year from now, when we first knew about an incident and when each report was sent?

CRA's deadlines are short because exploited vulnerabilities spread quickly. The organisations that will meet them are the ones that have already practised the steps.

What to watch

CRA applies from 11 September 2026. ENISA's single reporting platform is already being built, and manufacturers should get familiar with it before the deadline.

The implementing acts and guidance on what counts as a "severe incident" and an "actively exploited vulnerability" are still being developed. When they arrive, read them carefully, because that's what supervisors will measure you against.