Reporting a vulnerability within 24 hours: who, to whom and what

Full application of the Cyber Resilience Act falls in December 2027, and most implementation plans take that date as their reference point. The reporting duty, however, applies from 11 September 2026, more than a year earlier, and demands organisational readiness that cannot be assembled in the final week.

What gets reported

The regulation provides two separate paths:

• an actively exploited vulnerability in the product;
• a severe incident affecting product security.

The decisive term is actively exploited. A vulnerability found during testing and fixed before launch is not reportable. The obligation arises where there are indications that it is being exploited in practice.

Recipients

The notification goes to two bodies in parallel:

• the CSIRT designated as coordinator, in Poland the relevant national team;
• ENISA.

Submission runs through a single platform, with no need to send separate notices.

Deadlines

The clock runs from becoming aware, not from confirming the event. This is fundamental to how the internal procedure is written. A clause providing for notification only after the technical team confirms the issue is non-compliant, because confirmation alone can take several days.

Required organisational readiness

The deadlines themselves are not the difficulty. The challenge is ensuring that somebody outside working hours holds the authority to decide.

Minimum preparation covers five elements.

1. An intake channel. A security@ address on your own domain, monitored, with the reporting path described on the product page.
2. Out of hours availability. Somebody reachable outside working hours. Without it, a twenty four hour deadline can elapse over a weekend.
3. Classification criteria. A single page setting out what constitutes an indication of active exploitation: an entry in the CISA KEV catalog, a publicly available exploit, traces in customer logs or a report from a CERT team.
4. A person with decision making authority. Named individually, with a deputy. Naming a team rather than individuals does not satisfy this.
5. A notification template. Prepared in advance and completable in a quarter of an hour.

Contents of the notification

The early warning is a signal rather than a report and covers:

• identification of the product together with its version;
• whether the vulnerability is being exploited and the basis for that assessment;
• a preliminary impact assessment;
• contact details for the person handling the case.

The notification submitted within 72 hours adds a technical description, the scope expressed in numbers of devices and affected markets, and the corrective measures taken. The final report covers the full description of the vulnerability, the fix applied and the measures preventing recurrence of that class of defect.

Verifying readiness

Ahead of September 2026 it is worth running an exercise: send the team a simulated report on a Friday after hours and measure the time until a classification decision is made.

A result measured in working days means the procedure needs rebuilding. The remaining time is entirely sufficient for that.

Implementation order

Ordered by effort:

1. A security@ address together with a public vulnerability disclosure policy.
2. Classification criteria and a named person with decision making authority.
3. Notification templates for all three stages.
4. Out of hours availability and a verification exercise, the only element that generates meaningful cost.

The wider regulatory context is covered in what the CRA requires from manufacturers, and establishing whether the regulation applies to you at all is made easier by the five question test.

I support manufacturers in building this process and in testing it before the first real notification. Get in touch to discuss the details.

This text is informational and does not replace legal analysis.