Provetry
FRDEGet early access
Free check
Get early access

Provetry opens in November 2026. The free CRA check, the tools and the guides are available now.

CRA reporting: the 24-hour, 72-hour and 14-day clock explained

9 min read

On this page
  1. What starts the clock
  2. The three reports
  3. Who can be fined, and the exception for small companies
  4. How to be ready before it happens
  5. What Provetry does, and what it doesn’t
  6. Sources

Since 11 September 2026, every manufacturer of a product covered by the Cyber Resilience Act must report two kinds of events to the authorities: actively exploited vulnerabilities in its products, and severe incidents that affect their security. The duty applies to every product in scope already on the EU market, not only to new ones. Reports go through ENISA’s Single Reporting Platform, which sends them to the CSIRT designated as coordinator and to ENISA in one filing.

What starts the clock

An actively exploited vulnerability

A vulnerability is actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. A vulnerability that is merely serious, or that a researcher has demonstrated, is not enough. Common signals are an entry in CISA’s Known Exploited Vulnerabilities catalogue or the EU Vulnerability Database, a vendor advisory saying it is exploited in the wild, or your own incident evidence.

The clock starts when you become aware of it, including when a component inside your product, such as an open-source library, is the one being exploited.

A severe incident

An incident is severe when it affects, or can affect, your product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led, or can lead, to malicious code being introduced or run in your product or in your users’ networks. A compromised update server is the textbook case.

The three reports

Step Actively exploited vulnerability Severe incident
Early warning Within 24 hours of becoming aware, saying where in the EU the product is available Within 24 hours, also saying whether the incident is suspected to come from an unlawful or malicious act
Notification Within 72 hours: the product, the nature of the exploit and of the vulnerability, the corrective or mitigating measures taken, the measures users can take, how sensitive the information is Within 72 hours: the nature of the incident, an initial assessment, measures taken and measures users can take, how sensitive the information is
Final report No later than 14 days after a corrective or mitigating measure is available: description, severity and impact, what is known about the malicious actor, details of the security update Within one month after the notification: a detailed description, the likely type of threat or root cause, the mitigating measures applied and ongoing

The CSIRT can ask for an intermediate report in between. You must also inform the users affected, and the measures they can take, in a timely manner; if you don’t, the CSIRT may do it.

Who can be fined, and the exception for small companies

Missing these duties can be fined up to €15 million or 2.5% of worldwide annual turnover, whichever is higher. Micro and small enterprises cannot be fined for missing the 24-hour early warning, but the duty itself, and the 72-hour notification and final report, still apply. Open-source software stewards report too, to the extent they are involved, and cannot be fined.

How to be ready before it happens

The 24 hours are short because the first hours of an incident go on working out what is affected. Most of that work can be done in advance.

  1. Know what is inside each product. A current software bill of materials, release by release, lets you answer “are we affected?” in minutes instead of days. See our SBOM guide.
  2. Watch for exploitation, not just for vulnerabilities. Match your components against the exploited-vulnerability catalogues every day, so that you learn about exploitation from your own tools and not from a customer.
  3. Register on ENISA’s Single Reporting Platform before you need it, and decide who in your company may submit.
  4. Prepare the reports. Keep templates for the three steps with your product data already filled in: name, versions, Member States where it is sold, contact points.
  5. Write the user notice in advance. A short text, with placeholders, that tells users what is affected and what to do.
  6. Rehearse once. Take a real exploited vulnerability from last year and time how long your team takes to fill in the early warning.

What Provetry does, and what it doesn’t

On the paid plans, Provetry watches each component of your products against CISA KEV and the EU Vulnerability Database, alerts you when one of them is reported as exploited, counts down the deadlines from the moment you record that you became aware, and drafts the three reports with your product data. With the Reviewed reports add-on, a certified security expert reads every draft before you send it. Alerts never wait for that review.

Provetry does not submit anything to ENISA for you, and it does not decide for you that a vulnerability is actively exploited: the law gives both to the manufacturer.

This guide is general information, not legal advice.

Sources