EU Cyber Resilience Act: The 24-Hour Reporting Rule Is Live

This article summarises the regulation for security and engineering teams. It is not legal advice. Confirm your specific obligations with counsel.

What does the Cyber Resilience Act require, and when?

What must be reported within 24 hours?

Article 14 creates two reportable events, with similar clocks. Both start when the manufacturer becomes aware of the event.

An incident counts as severe when it affects, or can affect, the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or when it leads, or can lead, to malicious code in the product or in users' systems. The coordinator CSIRT can also ask for intermediate reports.

Note the trigger: actively exploited. A vulnerability found in your own penetration test, with no evidence of exploitation, is handled through your normal vulnerability process. Evidence of real-world exploitation, whether from your telemetry, a customer, a researcher, or threat intelligence, starts the clock.

Who receives the reports?

Notifications go through ENISA's Single Reporting Platform (SRP) to the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, meaning where cybersecurity decisions are mainly taken. ENISA receives them at the same time. The receiving CSIRT passes the information to CSIRTs in the other Member States where the product is available, and dissemination can be delayed on justified cybersecurity grounds, for example while coordinated disclosure is under way.

What vulnerability handling does the CRA expect?

Reporting sits on top of the vulnerability-handling requirements in Annex I, Part II, which apply from December 2027. Manufacturers must:

• Identify and document vulnerabilities and components, including a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies.
• Address vulnerabilities without delay, with security updates provided separately from feature updates where technically feasible.
• Regularly test and review the product's security.
• Publicly disclose fixed vulnerabilities once an update is available, with delays allowed in justified cases.
• Put in place and enforce a coordinated vulnerability disclosure (CVD) policy, with a contact address for reporting vulnerabilities.
• Distribute updates securely, automatically where applicable, without delay and free of charge, with advisory messages.

The expected support period, during which security updates must be provided, is at least five years, unless the product is expected to be in use for less time.

Is your PSIRT ready for a 24-hour clock?

A day is very little time if the first question is "who owns this?". A readiness checklist:

• Intake: one monitored address and a published CVD policy (security.txt is a simple start), plus internal routes from support, sales, and telemetry into the PSIRT.
• Triage criteria: a written definition of "actively exploited" and "severe incident" for your products, agreed with legal in advance.
• Product inventory: which products and versions are on the EU market, and their support periods.
• SBOMs: generated at build time and searchable, so that "are we affected?" takes minutes, not days.
• SRP access: accounts, roles, and a named decision-maker who can approve an early warning outside office hours.
• Templates: pre-drafted early warning, notification, and final report content.
• Exercise: a tabletop that runs a real scenario, from customer report to submitted early warning, against the clock.

Where does security testing fit?

The CRA asks manufacturers to test security regularly and to handle vulnerabilities before they become incidents. Independent testing helps in three ways: it finds exploitable issues before attackers do, it exercises your CVD and fix process with real findings, and it produces evidence of due diligence for conformity assessment from December 2027.