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

When the clock starts ticking

The Cyber Resilience Act's 24-hour reporting rule works like when you lose your bank card. The clock starts when you notice it is gone, not when you finish your coffee or get home from the trip. For manufacturers of products with digital elements—connected hardware and software, but not medical devices or type-approved vehicles—the same principle applies from 11 September 2026 ^[1].

Article 14 says manufacturers must submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident ^[2]. Awareness is the trigger. It is not when the full picture is clear, or when legal has approved the wording. It is when someone in the organisation knows enough to recognise that a report is needed.

Three reports, three deadlines

The CRA asks for three things, each at a different time ^[3].

First, the early warning: within 24 hours of awareness. It does not need to be complete. It needs to say that something is happening, that the manufacturer knows about it and that more is coming. Think of it as the equivalent of calling the bank the moment you realise the card is missing.

Second, a notification without undue delay, and at the latest 72 hours after becoming aware: a fuller account, with details of the vulnerability or incident, which products are affected, the severity and any mitigating measures.

Third, a final report within 14 days of submitting the notification, or sooner if the details are already available: the complete picture, including root cause, impact, timeline and remediation.

All three go through ENISA's single reporting platform ^[6].

What counts as severe

Not every bug or breach needs reporting. The CRA draws a line. An actively exploited vulnerability is one that an attacker is using in the wild, not one that merely could be exploited ^[2]. A severe incident is one that has caused, or could cause, significant harm: personal injury, major property damage, substantial economic loss or serious disruption to critical services ^[7].

If a flaw is theoretical, or an incident is contained before it causes real harm, the CRA's reporting duty does not apply. If attackers are actively using the vulnerability, or the incident meets the severity threshold, the 24-hour clock is running.

Counting the hours

The phrase "becoming aware" sounds straightforward until you try to pin it to a moment. Say a security monitoring tool flags unusual activity at 2 a.m. on a Tuesday. An engineer looks at the alert on Wednesday morning and suspects it might be serious. A manager confirms on Wednesday afternoon that it is an actively exploited vulnerability. When did the manufacturer become aware?

The CRA does not offer a definition, but the pattern in other rules—DORA, NIS2, the GDPR—is that awareness means the moment when the organisation, as an organisation, knows enough to act ^[8]. That is usually when the information reaches someone with the authority or the duty to escalate it, not when it first appeared in a log file nobody had opened yet.

Still, the gap between detection and awareness is where disputes start. Supervisors can ask why the early warning went out 30 hours after the first alert, not 24. The defence that nobody senior knew about it only works if the first alert really did sit unread, and proving that often means showing a timestamped record of when each person saw each piece of information.

Evidence you can check

The moment of awareness is not always obvious weeks later, especially if several people saw parts of the picture at different times. A sealed record of the detection alert, the first internal note and the decision to escalate gives the manufacturer a timeline that nobody—inside or outside the organisation—can quietly rewrite.

Here, the thing to seal is each step: the first detection alert from the monitoring system, the note from the engineer who looked at it, the manager's decision to treat it as reportable and the early warning as it is sent to ENISA's platform. Sealing takes a fingerprint of each record, not the record itself, so nothing sensitive leaves the manufacturer's systems. When a supervisor later asks why the clock ran to 30 hours, anyone the manufacturer shares the records with can check that they are exactly what was recorded at each step, unchanged since.

A digital witness shows when each step was recorded. It does not show that the report was complete, or that the response was adequate, or that the manufacturer met every duty under the CRA. What it does is give the manufacturer a timeline that holds up, so the question is whether the response was good enough, not whether the timeline itself can be trusted.

WitniumChain does this through a REST API, an SDK or an MCP server. The content stays with you. The first 2,000 witnesses a month are free. Documentation is at witniumchain.com/docs.

How it would work

1. The monitoring system flags an event and writes a detection record. Your system seals the record's fingerprint and gets a witness ID back.
2. An engineer reviews the alert and writes a note. The note is sealed as soon as it is saved.
3. A manager decides the event is reportable and records that decision. That record is sealed, too.

Months later, if the timeline is questioned, you share the records and the witness IDs. Anyone can calculate the fingerprints again and check that they match the sealed ones. If they do, nothing has changed since the moment each record was written.

What this means for you

If you make connected products that will be on the market after 11 September 2026, here are three questions to ask now.

First, who in your organisation will know first when something reportable happens, and how will that information reach the person who decides whether to report? The 24-hour clock does not wait for the weekly meeting.

Second, can you show, weeks or months later, when your organisation first became aware? A monitoring alert with a timestamp is a start, but if nobody looked at it until the next day, you will want a record of that, too.

Third, have you tested a dry run of the three reports? The early warning within 24 hours is the one that trips people up, because it asks you to report before you know everything. Practice makes that easier.

What to watch

ENISA's single reporting platform is expected to go live before the reporting duty starts on 11 September 2026 ^[6]. Manufacturers will need to register.

On 11 December 2027, the essential requirements in Annex I apply to products placed on the market from that date ^[4]. Those requirements include the ability to record and monitor security-relevant events. If your product does not log what it needs to log, it will not meet the CRA's baseline, and fixing that after the product is on the market is harder than building it in from the start.

The Commission is working on detailed technical standards and guidance. When those are published, they will clarify what counts as "without undue delay" for the 72-hour notification, and what level of detail the early warning must contain. Until then, the rule is to report what you know, when you know it, and fill in the gaps later.

Sources

1. Regulation (EU) 2024/2847 of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), Article 14(1), EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
2. Regulation (EU) 2024/2847, Article 14(2) and recital 65, EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
3. Regulation (EU) 2024/2847, Article 14(2), (3) and (4), EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
4. Regulation (EU) 2024/2847, Annex I, Part I, point 2, and Article 66(3), EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
5. Regulation (EU) 2024/2847, Article 63(3)(a), EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
6. Regulation (EU) 2024/2847, Article 14(8) and recital 67, EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
7. Regulation (EU) 2024/2847, Article 3(19), EUR-Lex, 20 November 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj
8. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), Article 19(2) and (3), EUR-Lex, 14 December 2022, https://eur-lex.europa.eu/eli/reg/2022/2554/oj