CRA reporting: one month in practice

Yes, it can. Since 11 September 2026, manufacturers selling products on the EU market must report actively exploited vulnerabilities in their products. That is what Article 14 of the Cyber Resilience Act (CRA) requires. The deadline starts when you become aware. Not when the bug was written. A bug in a device you shipped years ago can start your 24 hours tomorrow morning.

One month later, ENISA’s reporting platform is up and the clocks are running. Most companies I talk to have not heard them tick yet. Or they are sure the clocks only tick for somebody else’s developments. Here is what the first month looks like in practice. Not the brochure version.

Which deadlines apply?

For an actively exploited vulnerability there are three steps:

24 hours for the early warning.
72 hours for the notification with a first assessment.
14 days after a fix or mitigation is available for the final report.

Severe incidents follow the same pattern with 24 and 72 hours. There, the final report is due one month after the 72-hour notification.

Not every vulnerability is reportable. The duty covers vulnerabilities that are actually being exploited, and severe incidents. That sounds like a small set. But whether a vulnerability is exploited is not your decision. The attackers make it.

The Article 14 reporting deadlines for an actively exploited vulnerability. The first two run from awareness, the final report from the moment a fix is available.

When does the clock start?

The moment you become aware. Not when the CVE was published. And “I swear I only found out this morning” is not evidence.

To me, awareness is a timestamp in your system, not a feeling. If someone later asks when you knew, you need an answer that does not come from memory. An email to support, a ticket, a call from a customer: any of these can be the start, once it holds reliable evidence of exploitation.

Why does a bug from 2021 count?

Because the age of the bug does not matter. On 8 October 2026, the US agency CISA added five vulnerabilities to its catalogue of actively exploited vulnerabilities. None of them is new. The oldest is from 2015, one is from 2021, the most recent from 2023. They include ISC BIND, ProFTPD and Apache Struts. These are building blocks found in many devices and systems.

At the end of September, GreyNoise also observed a wave of attack attempts on Hikvision cameras in Ukraine. The flaw behind it is also from 2021. The vendor closed it back then with a firmware update. The cameras without the update are still online.

For a manufacturer this means: a development you shipped years ago can start your 24 hours tomorrow morning. All it takes is a building block inside it whose flaw is exploited today, and a message about it. Whether it is exploited in your product too is a call you then have to make fast and justify later. The reporting duty also covers products that were already on the market before 11 September.

Do I have to report old cases?

No, and that is the good news. Active exploitation you already knew about before 11 September 2026 is not reportable retroactively. ENISA’s FAQ says so.

The bad news sits right next to it. If you become aware after that date, the duty applies. Even if the bug is from 2021.

Who files the report?

A person. Your software cannot send the report automatically. ENISA’s platform has no API in its first version. A real person types the report in by hand. That person needs an EU Login with multi-factor authentication and must be registered on the platform as your company’s representative. The accounts are personal.

In parallel, the competent national CSIRT checks that this person really acts for your company. Before that check you can file up to 20 notifications. So the check does not hold you up. How long it takes depends on the CSIRT. In the first public account I know of, the Belgian CSIRT took three working days.

That is not an obstacle. But nobody wants to create an EU account at 23:40 on a Friday while the 24 hours are running.

The choice of CSIRT matters. As a rule, it is the CSIRT of the member state where your company has its main establishment in the EU. Pick the wrong one and the notification may be invalid and has to be filed again. That costs exactly the hours you do not have.

Are there harmonised standards yet?

Drafts exist. The horizontal standards are being written at CEN and CENELEC, the standards for specific product groups mostly at ETSI. But not one CRA harmonised standard has been cited in the Official Journal of the EU yet. Only once a standard is listed there can a manufacturer assume that meeting it meets the requirements. The Annex I requirements apply from 11 December 2027. The standards are meant to be ready by then.

For the reporting duty this is secondary. The deadlines are in the regulation itself. Waiting for a standard does not move them.

What was the hard part for us?

We went through this for our own developments. The process was not the hard part. The hard part was one question: who picks up the phone at 23:40 on a Friday, and does that person know it is them?

We have an answer now. It is not a PDF.

What would I check now?

Four questions that take little effort:

Who in your company learns first about an exploited vulnerability? Support, sales, engineering, or a customer?
Who files on the platform, does that person already have an EU Login, and who covers for them at the weekend?
Which national CSIRT is responsible for your company?
Where is it recorded when you learned what?

With these answered, 24 hours are workable. Without them, they are very short.

What is my question to you?

In your company, who is the person who becomes “aware” first? And does that person know it?

A bug from 2021 can start your 24-hour clock