The CRA's 24-hour clock starts when you notice the exploit, not when it suits you

When the clock starts ticking

The Cyber Resilience Act treats incident reporting like reporting a lost bank card. The 24-hour deadline starts the moment you become aware of an actively exploited vulnerability, not when someone has finished investigating, written the report or got approval to send it. Miss the deadline and the penalties are severe: up to €15 million or 2.5% of global annual turnover, whichever is higher ^[1].

ENISA has now published expanded guidance on exactly how manufacturers submit these notifications through the EU Single Reporting platform ^[2]. The platform has been accepting CRA reports since 11 September 2024, the day the regulation's reporting obligations took effect. The deadlines themselves are unforgiving, and the platform doesn't care whether your internal approval process took three days.

Article 14 sets out a three-stage procedure ^[1]. For an actively exploited vulnerability, the manufacturer must submit an early warning within 24 hours of becoming aware. A full notification, including an initial assessment, follows within 72 hours. An intermediate report is due when the manufacturer has new information, and a final report within 14 days of remediation. For serious incidents—those that have actually caused harm or significant disruption—the same staged process applies, with similarly short deadlines.

The point ENISA's guidance hammers home is procedural. You log in to the platform, fill in structured fields and attach supporting evidence. There's no wiggle room for sending an email to a national authority and hoping that counts ^[2].

What you're reporting, and to whom

The CRA's scope is broad but specific. It covers products with digital elements: connected hardware and software, from industrial controllers to mobile apps, with explicit carve-outs for medical devices under the MDR and type-approved vehicles ^[1]. If you make something that connects and it isn't a medical device or a car with type approval, the CRA's reporting rules apply to you.

The regulation distinguishes between actively exploited vulnerabilities and serious incidents. An exploited vulnerability is one that attackers are using in the wild. A serious incident is one that has caused, or risks causing, death, serious injury, significant material or immaterial damage, or widespread service disruption ^[1]. Both trigger the same reporting cascade; the difference is in what you're describing.

Manufacturers report through the Single Reporting platform, which ENISA runs. National authorities and ENISA itself see the reports, and so does the European Commission. The platform is designed to avoid duplication: one report satisfies the CRA, NIS2 and sector-specific obligations where they overlap ^[2].

What ENISA's guidance makes plain is that the platform expects structure. You don't just write a paragraph saying something has gone wrong. You fill in fields: product name and model, vulnerability identifier if there is one, affected versions, how the exploit works, how many users are at risk, what you've done so far. The final report includes remediation measures and, where relevant, a post-incident analysis ^[2].

The practical question nobody asks early enough

Here's the question every manufacturer should be asking now, two years before the product requirements kick in: if we had to file an early warning at 9 a.m. tomorrow, could we show when we first became aware of the issue?

The regulation doesn't just ask for a report; it implicitly asks for a timeline. When did your monitoring system flag the anomaly? When did the security team escalate it? When did someone with authority decide this counted as an actively exploited vulnerability? Those timestamps matter, because the 24-hour clock starts at the first one, and a supervisor reviewing your report six months later will want to see that you didn't sit on it.

Most organisations have logging, monitoring and ticketing systems that record these steps. The harder question is whether those records would hold up if questioned. Internal logs are kept by the same people who could edit them, and an incident report written on day three but backdated to day one is exactly the sort of thing that turns a regulatory review into a penalty.

It's one thing to have a process. It's another to be able to show, convincingly, that the process was followed and the timeline is what you say it is.

Sealing the timeline as it happens

This is a case where a digital witness fits squarely. The thing to seal is each step of the incident timeline: the first detection note, the decision to escalate, and each report as it is sent to the platform. You seal a fingerprint of each record as it is written, not the record itself, so the content stays in your systems. If the timeline is questioned later, anyone you share the records with—auditors, supervisors, insurers—can check that they haven't changed since they were sealed.

What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. Say your detection system logs an anomaly at 14:22 on a Tuesday, and someone with the right access could go back and change that timestamp to 16:30 on Wednesday. Sealing the log entry at 14:22 means a change would show, even if it's made by an administrator.

What it doesn't show is that your response was adequate, that the report was complete, or that you interpreted the regulation correctly. A sealed timeline is a record of what happened and when, not a guarantee that you did the right thing.

You would seal each step through WitniumChain: the REST API if you're integrating it into your incident management system, the SDK if you're building it into your monitoring tools, or the MCP server if you're working with AI agents. The content never leaves your environment. The first 2,000 witnesses a month are free, and the documentation is public.

How it would work

1. Your monitoring system detects an exploit attempt and writes a detection record. Your system sends a fingerprint of that record to WitniumChain and gets a witness ID back.
2. The security team decides to escalate. That decision, with a timestamp, is sealed the same way.
3. You submit the early warning to ENISA's platform. The submitted report, or a copy of it, is sealed as it goes out.

If ENISA or a national authority later questions the timeline, you show them the sealed records and the witness IDs. They can check the fingerprints themselves and see that nothing has changed since sealing.

What this means for you

If you manufacture products with digital elements, the CRA's reporting deadlines apply from 11 September 2024 for anything already on the market, and from 11 December 2027 for new products ^[1]. ENISA's guidance tells you how to file the reports; it doesn't tell you how to prove you filed them on time, or that your internal timeline is accurate.

Before the first incident lands on your desk, it's worth asking:

• Do we have a clear definition of what counts as becoming aware, and does everyone in the chain know it?
• Can we show when each step of an incident was recorded, in a way that would satisfy a sceptical supervisor?
• If someone with administrator access edited a log entry, would we know, and could we prove the original?
• Have we tested the process of submitting to ENISA's platform, so we're not learning it under pressure?

The penalties for late or incomplete reporting are high enough that getting the process right is worth the effort. A sealed timeline doesn't replace a good incident response plan, but it does give you a record that holds up when the plan is tested.

What to watch

The CRA's product requirements, including the obligation to log and monitor security-relevant events, apply from 11 December 2027 ^[3]. Between now and then, manufacturers have time to build logging and incident response processes that meet both the technical requirements in Annex I and the reporting requirements in Article 14. ENISA's guidance is likely to evolve as more manufacturers start using the platform and edge cases come to light.

For now, the practical point is simple: the 24-hour clock is already ticking for some, and it will be ticking for everyone in two years. The question is whether your records will back you up when it does.