The Cyber Resilience Act’s 24-Hour Clock: What Changed on 11 September 2026

Since 11 September 2026, the reporting obligations in Article 14 of the EU Cyber Resilience Act (CRA) apply. Most of the CRA's product requirements only apply from December 2027, but reporting started early, and it covers products that are already on the market.

If your organisation makes hardware or software with digital elements and sells it in the EU, your security team is now on a regulatory clock.

What must be reported

Manufacturers must report two kinds of event:

• Actively exploited vulnerabilities in their products.
• Severe incidents that affect the security of their products.

Reports go through ENISA's Single Reporting Platform, which is now live. The manufacturer reports once, to the CSIRT of the member state where it has its main establishment, and ENISA receives the information at the same time.

The deadlines

Stage	Exploited vulnerability	Severe incident
Early warning	Within 24 hours of becoming aware	Within 24 hours of becoming aware
Notification	Within 72 hours	Within 72 hours
Final report	Within 14 days of a corrective measure being available	Within one month of the notification

The clock starts when you become aware, not when you have finished investigating. That puts the pressure on detection and triage.

How the CRA fits with NIS2 and DORA

Many organisations now face three overlapping reporting regimes:

• NIS2 covers incidents affecting essential and important entities, with a 24-hour early warning. See our NIS2 and DORA guide.
• DORA covers major ICT incidents at financial entities, with an initial notification within 4 hours of classification.
• The CRA covers vulnerabilities and incidents in the products you make.

A manufacturer that is also an essential entity can face more than one report for the same event. Mapping these obligations in advance avoids confusion when the clock is running.

What this means for SOC teams

The CRA is aimed at manufacturers, but the work lands on whoever spots exploitation first. In practice that is often the SOC: telemetry from your own products running in your own estate, threat intelligence mentioning your products, or customer reports routed through support.

To meet a 24-hour early warning, a team needs:

1. A clear trigger. Agree what counts as becoming aware, and who decides.
2. Fast triage. Separate real exploitation from noise quickly enough to report on time.
3. Evidence as you go. Keep a timeline of what was seen, when, and what was done. The 72-hour notification and the final report depend on it.
4. A route to product security. The SOC must be able to reach the team that can ship a fix.

Where Claire Security fits

Claire Security monitors connected systems around the clock and records the full reasoning behind every alert it investigates. That gives a reporting team a time-stamped trail from first signal to verdict, which is exactly what the early warning and the follow-up reports need. Because it runs on-premise or hybrid, the investigation data stays under your control.

No tool makes you compliant on its own. But a 24-hour clock is much easier to meet when triage takes minutes rather than hours.