The CRA's 24-hour rule: when you knew matters as much as what you did

When the clock starts

The CRA's 24-hour rule works like losing your bank card: the clock starts when you notice it's gone, not when it's convenient to call the bank. Article 14 of Regulation (EU) 2024/2847 says 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 severe incident has occurred ^[1].

That's followed by a second report within 72 hours with more detail, and a final report when the incident is resolved or the mitigation is in place ^[1]. The rule has applied since 11 September 2026, and the fines for missing the deadlines can reach €15 million or 2.5% of global annual turnover, whichever is higher ^[1].

The tricky bit is the phrase "becoming aware". It doesn't mean when you've finished investigating, or when you're ready to tell ENISA. It means when someone in your organisation first had reason to believe something was being exploited or had gone seriously wrong.

Who it covers

The CRA applies to manufacturers of products with digital elements: routers, smart home devices, connected appliances, industrial controllers and standalone software, among others ^[1]. Medical devices and vehicles with type approval are explicitly excluded ^[1].

If you make something that connects, runs code or processes data, and it isn't covered by sectoral rules, the CRA probably applies to you. That includes manufacturers inside and outside the EU, as long as the product reaches the European market.

What counts as becoming aware

Say your security team picks up unusual traffic at 14:00 on a Tuesday and opens a ticket. By 16:00, someone suspects it might be an exploit of a known vulnerability. The early warning is due by 16:00 on Wednesday, not by the time you've confirmed every detail or written a full post-mortem.

The regulation doesn't spell out what "becoming aware" means in every case, but the principle is clear: you can't delay reporting just because the investigation is ongoing. The early warning is meant to be early, and incomplete information at 24 hours is better than complete information at 48.

That creates an evidential problem. If a supervisor or an insurer later asks why the warning went out after 30 hours instead of 24, you need to be able to show when the first detection note was written, when the decision to escalate was made and when each report was actually sent.

The evidential question

Incident timelines get questioned, especially when the outcome is serious or the penalty is steep. A supervisor might ask whether the manufacturer delayed reporting to buy time for a patch. An insurer might want to know whether the incident was contained within the contractual window. And if it goes to court, the timeline becomes evidence.

The organisation keeping the records is the same organisation that could quietly edit them. A log entry that says "first detected 14:00" is easy to challenge if it was written at 15:30, or if there's no way to show it wasn't changed later. Access controls and monitoring help, but they don't answer the question a third party will ask: how do I know nobody rewrote this after the fact?

How a digital witness fits here

Here, the thing to seal is each step of the incident 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 and any personal data never leave your systems.

You send the fingerprint to WitniumChain through the REST API, the SDK or the MCP server, and get a witness ID back. To check later, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. If it matches, the record is unchanged. Change a single character and it won't match. The first 2,000 witnesses a month are free ^[2].

What the witness 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, that the response was adequate or that the vulnerability was actually being exploited. Those are different questions, and the witness doesn't answer them.

How it would work

1. The security team writes a detection note and seals it at 14:00.
2. The escalation decision is sealed at 16:00.
3. The early warning is sealed when it's sent to ENISA at 15:45 the next day.

If the timeline is questioned, you can show that each record existed at the time it says it did, unchanged since.

What this means for you

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

• Can we show, six months after an incident, when our security team first recorded a detection?
• Do we have a record of when each report was sent to ENISA, and can we prove it hasn't been edited?
• If a supervisor asks why the early warning was late, do we have our own evidence, or only our word?

The regulation sets the deadlines. Whether you can prove you met them is a separate question, and one worth answering before the next incident.

What to watch

The CRA's full set of requirements, including security-by-design and conformity assessment, applies from 11 December 2027 ^[1]. The reporting duty is already in force, so the evidential question is live now.

ENISA's platform for vulnerability and incident reporting is the single point of contact ^[1]. How supervisory authorities interpret "becoming aware" in borderline cases will become clearer as enforcement starts, but the burden of proof will be on the manufacturer.