Cyber Resilience Act: 24 hours to report

A manufacturer in Toronto or Austin sells a network appliance or a piece of software in Europe. Since September 11, 2026, if it learns that a vulnerability in its product is being actively exploited, it has twenty-four hours to tell a European CSIRT. Not its customers: an authority. One more clock for a team that already keeps several, and one process for all of them.

What the regulation says

According to the European Commission's page on the reporting obligations of the Cyber Resilience Act (CRA), manufacturers of products with digital elements must, since September 11, 2026, report two things: actively exploited vulnerabilities and severe incidents having an impact on the security of the product. The timeline has three steps: an early warning within 24 hours of becoming aware, a notification within 72 hours, then a final report, no later than 14 days after a corrective measure is available for a vulnerability, or within a month of the 72-hour notification for a severe incident.

The same page describes the route: the manufacturer reports to the CSIRT of the Member State of its main establishment, through the Single Reporting Platform that ENISA launched on September 11, 2026, and the information is made available to ENISA at the same time. According to the launch release, that CSIRT disseminates the information to the CSIRTs of the Member States where the product is also available. Open-source software stewards will be subject to it from December 11, 2027, according to the Commission.

The obligation follows the product, not the head office: selling in the Union makes you a manufacturer within the meaning of the regulation, on the same clock as a competitor in Munich.

Why it matters

On September 22, 2026, the Canadian Centre for Cyber Security published alert AL26-022 on CVE-2026-94127, a heap-based buffer overflow in F5 BIG-IP Access Policy Manager (APM) exploitable without authentication when an APM access policy and an OAuth profile share the same virtual server; the alert states that F5 has indicated the vulnerability is being exploited in the wild. Without saying anything about that manufacturer's status under the CRA, a manufacturer in that situation, with a product sold in the Union, would have faced this clock: 24 hours after learning the vulnerability was exploited, an early warning on ENISA's platform; 72 hours, a notification; 14 days after the fix was released, the final report.

That clock joins the ones the team already keeps.

Five regimes, five triggers (exploitation, materiality, harm, designation) and five recipients. The raw material, though, is identical: who detected what, at what time, on which product or system, with what impact, what measures. A team that rewrites the same thing five times at three in the morning gets it wrong at least once.

What we think at Sentrix

The CRA does not create a discipline: it puts the shortest deadline on the list on one that already exists, the PSIRT (product security incident response team). In order:

1. Fix time zero before the incident. The CRA clock starts when the manufacturer becomes aware of the exploitation. Write down what counts as awareness for you: telemetry, a customer notice, a known-exploited catalog. Name who declares T0.
2. One file, several outputs. The same incident file produces the early warning to the CSIRT, the customer bulletin, the NIS 2 notification your European customers require by contract and the board note for the materiality decision (SEC).
3. Register on ENISA's platform now. Registration, the representative and the competent CSIRT get settled on a Tuesday afternoon, not on the night of a zero-day.
4. Write the three templates (24 hours, 72 hours, final report) with the fields common to all five regimes, then test them on the table: how long from the first internal alert to a signed report?
5. Know in hours who is exposed. In the AL26-022 case, the question is not "do we have BIG-IP" but "which virtual servers have an APM policy and an OAuth profile". Continuous exposure, our CTEM module's job, answers per asset rather than per product.
6. Push the deadline down to your suppliers. The vulnerable component is often a third party's: the notification clause your customers impose on you, impose it upstream.

Our platform collects evidence once and maps it to every framework; our NIS2 page details the neighbouring European clock and our incident response service builds the PSIRT process with you.

The next step

Take your last product security advisory or your last emergency patch. Write down three times: when you knew, when your customers knew, when an authority would have been notified. If the third one does not exist, that is your work plan. If you want to do it with us, contact us.