CRA reporting obligations: early warning in 24 hours, full report in 72

The reporting timeline

When a manufacturer of a product with digital elements becomes aware of an actively exploited vulnerability in one of its products, or of a severe incident, the clock starts ^[1]. Article 14 of the Cyber Resilience Act sets three deadlines.

First, an early warning goes to ENISA within 24 hours of becoming aware ^[1]. That warning contains what is known at the time: a short description of the incident or vulnerability, whether it is being actively exploited, the severity and the products affected.

Second, a notification follows within 72 hours ^[1]. That notification adds detail: the type of threat or root cause, whether the incident is ongoing, which measures the manufacturer has taken and which mitigation the manufacturer recommends to users.

Third, a final report is due no later than 14 days after the notification, or when the incident handling is finished, whichever comes first ^[1]. The final report includes the severity assessment, the number of affected products and users in the Union, and any further technical details.

The obligation applies from 11 September 2026, a year before the main security requirements in Annex I come into force ^[2].

What triggers the duty

Two categories of event start the timeline: actively exploited vulnerabilities and severe incidents ^[1].

An actively exploited vulnerability is one where there is evidence that an attacker is using it. The manufacturer does not have to wait until an incident happens in its own systems. If the same flaw is being exploited in another manufacturer's product, or if a proof of concept is published, the duty can arise.

A severe incident is one that causes or is likely to cause significant disruption, harm to health or safety, substantial material or immaterial damage, or financial loss ^[1]. The threshold is high, but it catches incidents that could affect users beyond the manufacturer's own operations.

The duty lies with the manufacturer, defined as the organisation that develops or has a product developed, and that places it on the market or puts it into service under its own name or trademark ^[3]. For open-source software stewards who do not act in a commercial capacity, the duty does not apply ^[3].

The platform and the scope

Reports go to ENISA's single reporting platform, a system being built for the entire cybersecurity regulatory framework ^[1]. ENISA will forward relevant information to national authorities, CERT-EU and the competent product contact points under the CRA.

The reporting duty covers products that fall under the CRA, meaning hardware and software with digital elements, but excluding certain categories ^[2]. Medical devices and in-vitro diagnostic medical devices are out, because they have their own rules ^[2]. Vehicles covered by type-approval and their components are also excluded ^[2].

Software explicitly counts ^[3]. That includes operating systems, applications, software as a service offerings and firmware. It also includes AI systems, where the AI Act does not take precedence.

What this means for you

If your organisation manufactures products with digital elements and plans to place them on the Union market, four questions are worth asking now.

First, do you have a process for becoming aware? The deadlines count from the moment you become aware, so detection and escalation matter. Internal monitoring, customer reports, third-party disclosures and threat intelligence all feed into that.

Second, can you say when you became aware? The 24-hour and 72-hour clocks start when awareness begins, not when someone decides it is worth reporting. That means the first detection note, the first escalation and the decision to notify should be recorded at the time, in a way that can be shown later.

Third, who will write the reports, and who will approve them? The early warning is short, but it needs to go out on the right day. The notification and final report need technical detail and a severity assessment. ENISA has not yet published the template or the interface, but deciding now who will handle the process, and testing it with a tabletop exercise, beats doing it under the 24-hour deadline.

Fourth, how will you show a supervisor or an auditor that you met the deadlines? The timelines are strict, and the penalties are high: up to 15 million euro or 2.5 per cent of global annual turnover, whichever is higher ^[4]. A record of when you detected, escalated and reported, sealed at each step so it cannot be quietly rewritten, gives you something to point to.

Sealing the timeline as it happens

In cases where timing matters, a sealed record is worth more than a claim. Under the CRA, the question is not just whether you reported, but when you became aware and when you sent each notification.

Here, what you seal is the incident timeline: the first detection note, the decision to escalate, the early warning as it is sent, the notification and the final report. Each step is sealed at the time it happens, not afterwards.

Sealing takes a fingerprint of the record, not the record itself, so the content stays in your systems. The fingerprint is posted to WitniumChain, which returns a witness ID. If a supervisor later asks when you became aware, you share the timestamped detection note. Anyone can check that the note is the one recorded on that day by calculating the fingerprint again and comparing it with the sealed one. Change a single character in the note and it will not match.

It does not replace your incident response or your reporting process. It does not show that the report was complete, timely or adequate. What it shows is when each step was recorded, in a way nobody, including you, can quietly rewrite afterwards.

You integrate the sealing into your incident workflow through the REST API, the SDK or the MCP server. The content never leaves your systems. The first 2,000 witnesses a month are free. Documentation is at witniumchain.com/docs.

How it would work

1. When the first engineer notes the suspected incident, your system seals the detection note.
2. When the team escalates it and decides to notify, the escalation decision is sealed.
3. When the early warning, the notification and the final report are sent, each is sealed as it goes out.

Each seal gives you a timestamped, unchangeable record that you can point to when someone asks whether you met the deadlines.

What to watch

11 September 2026: reporting obligations under Article 14 apply.

11 December 2027: the main security requirements in Annex I, including logging and monitoring, apply to products placed on the market from that date ^[2].

ENISA is expected to publish the template for incident and vulnerability reports and the interface to the single reporting platform before September 2026. The first draft delegated acts on technical documentation and conformity assessment are expected by mid-2026.