CRA's 24-hour rule: when the clock starts, and what to seal

When 24 hours means 24 hours

CRA's 24 hours work like when you lose your bank card: the clock starts when you notice it, not when it suits you. Under Article 14 of Regulation (EU) 2024/2847, manufacturers of products with digital elements must send an early warning within 24 hours of becoming aware that a vulnerability is being actively exploited, or that a serious incident has occurred.^[1] Two more reports follow: one within 72 hours with a fuller picture, and a final one within 14 days.^[1]

The rule applies from 11 September 2026, and it covers connected hardware and software, except medical devices and vehicles with type approval.^[1] Manufacturers report through ENISA's common reporting platform, and the penalties for getting it wrong can reach 15 million euro or 2.5 per cent of global annual turnover, whichever is higher.^[1]

The short deadlines turn incident handling into a question of evidence. When a supervisor asks why the early warning went out after 30 hours, "we didn't notice" is one answer and "we noticed on Tuesday at 14:23" is another.

What 'becoming aware' means in practice

The 24 hours don't start when the vulnerability first existed or when the incident happened. They start when the manufacturer became aware.^[1] That sounds simple until you think about how awareness happens in a real organisation.

Say a monitoring tool flags something unusual on a Friday evening. Someone on the operations team sees it, decides it can wait until Monday, and logs it in a ticket system. On Monday morning, an engineer escalates it to the security team. They investigate and realise by Tuesday afternoon that it's a serious incident. When did the manufacturer become aware? Friday, Monday or Tuesday?

The regulation doesn't say, and the answer will turn on what the organisation can show about who knew what, and when. A ticket marked "investigate Monday" suggests awareness on Friday. A record showing that the first person to see it didn't have enough information to recognise it as serious might suggest Monday. Either way, the question is evidential, and the evidence is the log.

What to log, and how to protect it

CRA says what must be logged: security-relevant events, for monitoring and post-incident analysis.^[2] It doesn't say in Article 14 how to protect those logs, but the foundation is access control and monitoring. The risk is straightforward: the people who keep the logs are also the people who could edit them.

That matters when an incident is being questioned, because a log that can be quietly rewritten is easy to challenge. It doesn't help that the person doing the challenging often has their own record of when they told you about the problem. An email saying "reported this on Friday" is hard to argue with if your own log says Monday.

The practical question for anyone handling incidents is whether you can show a supervisor or an auditor when each step was recorded, in a way nobody can quietly rewrite afterwards.

Sealing each step as it happens

Here, a digital witness fits well. The thing to seal is each step of the incident: 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 content, so nothing about the incident or the vulnerability leaves your systems.

You seal at each step. When the monitoring tool flags the event, seal a record of the alert with the time. When someone escalates it, seal the escalation note. When the early warning goes out, seal a copy of what was sent and when. If it comes to a dispute, anyone you share those records with can check that they're exactly what was recorded at the time, unchanged since.

What it shows is when each step was recorded. What it doesn't show is that the response was adequate, that the report was complete, or that the organisation did everything it should have done. Those are separate questions. A witness answers one question only: has this record changed since it was sealed?

You seal through the REST API, the SDK or the MCP server. Your system sends a fingerprint, gets a witness ID back, and stores the ID with the record. To check later, you calculate the fingerprint again and compare it with the sealed one. The record itself never leaves your systems. The first 2,000 witnesses a month are free, and WitniumChain runs in production and has done since 2018. You can read the documentation and start sealing within an hour.

How it would work

1. Detection alert logged and sealed at 14:23 on Friday.
2. Escalation decision logged and sealed at 09:47 on Monday.
3. Early warning sent and sealed at 13:15 on Tuesday, 22 hours and 52 minutes after escalation.

What this means for you

If you manufacture connected products, here are three questions worth asking before 11 September 2026:

• When an incident happens, who decides that it's serious enough to report, and how is that decision recorded?
• Could you show a supervisor when you first became aware of a problem, and when you sent the early warning, in a way that doesn't rely on trusting the person who keeps the log?
• Does your incident response plan say what to seal and when, so that the timeline can be checked later?

The CRA deadlines are short, and the fines are high. The reporting itself goes through ENISA's platform, but the question of when you knew what is answered by your own records. A log you can prove hasn't changed is easier to defend than one you can't.

What to watch

The Cyber Resilience Act's reporting obligation comes into force on 11 September 2026. The security requirements in Annex I, which include logging and monitoring, apply from 11 December 2027.^[2] ENISA's common reporting platform is being built now, and manufacturers will need to register and set up access before the first deadline.

If your products fall under CRA, decide now who handles incident detection, who decides when awareness happened, and how each step is logged. The 24 hours start when you notice, and the clock doesn't stop for weekends.