The CRA 24-Hour Reporting Duty: What Manufacturers Must Do

The Cyber Resilience Act’s reporting duty is already in force: since 11 September 2026, under Article 14 of Regulation (EU) 2024/2847, manufacturers must report actively exploited vulnerabilities and severe incidents to their coordinating CSIRT and to ENISA. This is the first CRA obligation to bite, more than a year before the main requirements apply on 11 December 2027. If you make a product with digital elements for the EU market, you need the process in place now. This guide covers what triggers the duty, the deadlines, and how to be ready before the clock starts.

What triggers a report

Two situations, and only two, trigger this specific duty:

• An actively exploited vulnerability in your product with digital elements. The key word is exploited: a vulnerability someone is actually using against the product, not merely a vulnerability you discovered and are fixing in the normal course.
• A severe incident that has an impact on the security of your product with digital elements.

A vulnerability you find yourself, or that a researcher discloses, and that is not being exploited, is handled through your coordinated vulnerability disclosure and patching process. It does not by itself trigger the 24-hour clock. Knowing the difference matters, because over-reporting and under-reporting are both problems.

The deadlines

Once you become aware of a reportable event, three or four steps follow, depending on the type. The deadlines run from the moment of awareness.

Step	Deadline	What it contains
Early warning	Within 24 hours	A short notice that the event is happening, with the basics known so far
Notification	Within 72 hours	An update with an initial assessment, including severity and impact, and any corrective or mitigating measures taken
Final report (vulnerability)	Within 14 days of a corrective or mitigating measure becoming available	A description of the vulnerability, its exploitation and the fix
Final report (severe incident)	Within 1 month of the 72-hour notification	Full details, root cause, mitigations and measures

The 24-hour early warning is deliberately light. The authorities do not expect a root-cause analysis in the first day. They expect to be told that something is happening, so that other member states and other manufacturers can be warned if needed.

Where the report goes

All of this goes through the single reporting platform that ENISA operates under Article 16. You file electronically and the notification is routed to a coordinating CSIRT, the national incident response team that takes first receipt, which then forwards it to the CSIRTs in other member states where your product is available. ENISA switched the platform on, on 11 September 2026, the same day the duty began. You do not notify 27 authorities separately: one platform, one submission, routed for you.

How to be ready

The 24-hour deadline is only meetable if the groundwork is done before the incident. After CRA gap analyses and vulnerability-handling work with device makers, this is where we tell people to start.

1. Know who files, and have a backup. A named person, and a deputy, with access to the reporting platform and the authority to submit. An incident at 02:00 on a Sunday still has a 24-hour clock.
2. Be able to detect it. You cannot report what you never notice. That means monitoring of your products and your backend, and a channel for researchers and customers to reach you, which the CRA requires anyway.
3. Pre-draft the early warning. A short template with the fields the platform asks for turns the 24-hour task into filling in blanks, not writing from scratch under pressure.
4. Connect it to your vulnerability process. The report is one output of a working vulnerability-handling process (intake, triage, fix, disclosure). Build that process and the reporting falls out of it.
5. Rehearse once. A tabletop exercise with a realistic scenario shows whether 24 hours is actually achievable with your current setup. It usually is not, the first time.

What Zyberum does here

We run CRA gap analyses, build the vulnerability-handling process that Annex I and Article 13 require, and test the products so you find the serious vulnerabilities before an attacker exploits one. We are not a certification body and issue no CRA certificates or type approvals; we help you build the process and give you the evidence it works. See CRA compliance or book a free CRA check.