A security bug now comes with a 24-hour clock

A researcher emails your small plugin company with evidence that attackers are exploiting a flaw in your code on customer websites. Your developers start investigating. But fixing the problem may not be your only immediate responsibility: under the EU’s Cyber Resilience Act, manufacturers of covered software products have just 24 hours to submit an early warning after becoming aware of an actively exploited vulnerability.

The reporting requirements apply beginning September 11, 2026, to manufacturers that market covered software or connected hardware in the EU under their own name or brand as part of a commercial activity. That can include plugin and theme developers based outside the EU. Simply installing their products on your website does not make you responsible for these manufacturer reports. This article explains how software makers can assess whether they are covered—and what website owners should ask their vendors.

First, work out whether the clock is yours

The Cyber Resilience Act covers software and connected hardware offered on the EU market as part of a commercial activity. The manufacturer—the business marketing the product under its own name or trademark—is responsible for reporting. That can include a company selling plugins or themes, but simply installing those products does not make a website owner their manufacturer.

Standalone software-as-a-service (SaaS) generally falls outside the Act. However, remote processing can be covered when it is necessary for a product to function. General cloud services are addressed by other EU frameworks.

Open source has its own rules. Contributing to or maintaining a project outside commercial activity does not create the manufacturer’s duty, and the Act defines a separate, lighter role for open-source stewards, the foundations and companies that systematically support open-source products intended for commercial use. Businesses near any of these lines should treat classification as a real task for qualified advice. The screen below sorts roles; it cannot settle a hard case.

What happens at 24 hours, 72 hours, and after the fix

Awareness is hour zero. None of the deadlines run on calendar dates; each one counts from the moment the manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the product’s security.

Within 24 hours, the early warning. This first filing flags the problem while investigation continues, and the Commission’s description of the sequence is built around that staging: nobody expects a finished root-cause analysis on the first day.

Within 72 hours comes the full notification, carrying general information about the vulnerability or incident and an initial assessment of severity and impact. By this stage, the filing starts to resemble what the engineers actually know.

After the fix comes the final report. For an actively exploited vulnerability, it is due no later than 14 days after a corrective measure is available. Severe incidents close out on their own track, with a final report within a month.

One filing covers the route. Manufacturers report once through the CRA Single Reporting Platform, which notifies the CSIRT of their main establishment and makes it available to ENISA at the same time. The platform goes operational on the same September 11 date, and ENISA’s guidance is still being refined through rollout, so verify the current fields and registration steps there rather than trusting any summary, including this one.

A serious bug is not automatically an actively exploited one

Every word in “actively exploited vulnerability” is load-bearing. The regulation’s definition requires reliable evidence that a malicious actor used the flaw in a system without the owner’s permission. A CVE with a frightening severity score does not meet that bar on its own. A public proof of concept, a scanner finding, or a researcher’s disclosure alone does not establish active exploitation. The trigger is reliable evidence that an attacker has actually used the flaw.

The distinction is operational as much as legal. Since every deadline hangs on the awareness timestamp, a company’s process for receiving, validating, and logging exploitation evidence must hold up later: when the report arrived, who assessed it, and when the assessment concluded that reliable evidence existed.

Third-party components resist a one-line answer. When the flaw originates in a library your product builds on, whether your own duty fires is a question the Commission’s implementation FAQ treats in product-specific terms, so the useful move is mapping which of your products carry the component and taking advice, rather than assuming the upstream maintainer owns the whole event. Severe incidents, the second trigger, carry their own definitions and deserve their own read.

Build the reporting path before an exploit arrives

Here’ i’s the tabletop exercise worth an hour of any small maker’s time: if you received evidence of an exploit on Saturday, who could make the reporting decision?

Start by naming who will assess the evidence, record when the company became aware of exploitation, and decide whether reporting is required. Assign specific people and backups so the process works outside business hours.

Give them the tools they need: a monitored security contact, access to the reporting platform, and current records of products, versions, markets, and third-party components. Preserve the evidence and decision timestamps. Plan how to develop and distribute a patch, notify customers, and complete the required reports.

Confirm which national CSIRT should receive the report, including any questions about your main establishment or EU representative. Then rehearse the process outside normal working hours. Fixing gaps now is easier than discovering them during an incident.

What a website owner should ask a software vendor

Running a site on commercial plugins and platforms does not hand you the manufacturer’s filing duty. It hands you the fallout when a vendor is unprepared, which is why the useful move is due diligence now, while nothing is on fire.

Ask who owns vulnerability intake and CRA reporting at the vendor, because a named function means the Saturday question has an answer. Ask where advisories get published and how affected versions are described; a patch you cannot map to your installed version is a riddle. Check what the update feature really covers too, since automatic protection rarely covers the whole stack. Ask how urgent notices reach customers, how quickly a tested patch ships, and how long the product’s support window runs. A support period that quietly ended last year answers every other question for you. Ask what the vendor expects customers to do when a version is exposed, and whether they can trace their own dependencies well enough to tell you. Vague answers are an answer too.

The reason to collect all this now is that updates work as part of a connected security system on your side of the fence as well; the fastest vendor patch still needs your tested deployment behind it. And if you ever hold exploitation evidence yourself, the reporting platform accepts voluntary reports from anyone once it opens.

A short deadline needs a long memory

If you’re unsure whether your business is covered, get qualified advice, assign reporting responsibility, and arrange platform access before an incident. Website owners should check how their vendors disclose vulnerabilities, deliver patches, and notify customers. Both should keep records of when they received evidence of a problem and how they responded.

September 11 does not change what good product security looks like. It changes how quickly you have to prove you were doing it. The clock is short. The preparation cannot be.