How many 24-hour reporting clocks are you running?

The EU Cyber Resilience Act reporting requirements took effect on September 11, 2026. Manufacturers now have 24 hours to report an actively exploited vulnerability or a severe incident in one of their products, which they file with their national incident response team and the European Union Agency for Cybersecurity (ENISA) at the same time.

Regulators can fine you up to 15 million euros for missing that window, or 2.5% of worldwide annual turnover, whichever is greater. Those numbers have been doing the rounds since the Cyber Resilience Act (CRA) was published, and they’ve prompted a lot of calls from companies that turn out to have no obligation at all. Far fewer companies are on the hook than that headline suggests.

Who has to report under the Cyber Resilience Act

Any company that sells hardware or software with network connectivity into an EU member state has to report vulnerabilities and incidents affecting that product. The regulation calls these products with digital elements, and it applies to the manufacturer regardless of where the manufacturer is based, so a US firm with no EU presence is covered from the moment its first unit ships into the single market.

What you sell determines whether you report. A breach of your own corporate network isn’t reportable under the CRA, and neither is an incident at one of your vendors, because those hit the company rather than the product it put on the market. Companies with plenty of EU customers and nothing connected in their product line have no obligation at all, and those are the calls I field most.

Open source software supplied outside the course of commercial activity falls outside scope, along with a handful of categories already regulated elsewhere.

The smallest companies still have to file, but they can’t be fined for missing the 24-hour window. It covers microenterprises, meaning fewer than 10 employees and under 2 million euros in turnover, and small enterprises, under 50 employees and 10 million euros.

What starts the 24-hour clock

The 24-hour clock starts when you find an actively exploited vulnerability in one of your products, or a severe security incident affecting the availability, authenticity, integrity, or confidentiality of sensitive data or of the product’s functionality. A supply chain compromise reaching your customers through your product would qualify.

The clock starts from the point you have reasonable indication that one of those has happened, which is earlier than most teams assume and well before you have a confirmed picture. You file an early warning through the Single Reporting Platform that ENISA runs, which routes it to the coordinating team in the member state where you have your main establishment and makes it available to ENISA at the same time. A fuller notification follows within 72 hours, covering severity, impact, and whatever mitigation your users can apply while they wait for a fix. Once a fix exists you have 14 days to file a formal security report, and a month for a final one.

A known vulnerability that nobody is exploiting carries no reporting obligation, however severe it looks on paper, which makes the regulation considerably more permissive than its penalty ceiling implies. It also leaves you to decide which unexploited vulnerabilities are worth fixing first, on your own judgment rather than a deadline. And a coordinating team can delay passing a notification on to other member states on justified cybersecurity grounds, under terms the Commission specified in a delegated act in December 2025, so filing doesn’t automatically mean immediate publication.

How the CRA clock interacts with NIS2 reporting

If your organization is already an in-scope entity under NIS2, the CRA clock is a second one, and a single event can start both. Article 23 of Directive (EU) 2022/2555 requires an early warning to your national computer security incident response team within 24 hours of becoming aware of a significant incident affecting your services, followed by a 72-hour notification and a one-month final report. The CRA runs its own 24-hour, 72-hour, and final-report sequence to ENISA, keyed to your product rather than your services.

The triggers don’t line up. One turns on impact to the services you provide, the other on exploitation or compromise inside something you sold. Say a ransomware event takes down a manufacturing line and also reaches a connected product in the field. That satisfies both, on two clocks, filed to two recipients. And the penalties differ too, up to 10 million euros or 2% of turnover under NIS2 for essential entities, up to 15 million or 2.5% under the CRA. When we wrote about getting ready for NIS2 and DORA compliance, the recurring failure was treating the reporting clock as a documentation exercise, and that gap widens when a second clock lands on the same incident.

What the first 24 hours look like

Twenty-four hours sounds generous until you spend them inside an incident. Across the programs we support, the first day is when a company knows the least it will ever know, forensics has barely started, the scope keeps moving, and someone still has to commit a severity assessment to a regulator in writing. That gap between a clean compliance position and what happens when things break is where the cost sits.

Counsel needs to be engaged early enough to make privilege decisions before anyone writes anything down, and the technical team wants more hours before it characterizes anything, which is reasonable and unavailable. Your own notification obligations to your broker and carrier sit in your policy, not in any regulation. Check them now, not on the day.

The organizations that handle this well have decided in advance who holds the authority to file on incomplete information, and they’ve told that person so.

What to put in place now

Put an inventory in place first, covering what you sell into the EU and which of those products carry network connectivity, because you can’t run a clock on products you haven’t scoped. Check separately whether your organization is also in scope under NIS2, since the two assessments answer different questions.

Then name the person who can authorize a filing at hour 20 with partial information, and give them a pre-drafted early warning template so the first submission isn’t being composed from scratch. Test your incident response plan against the clock instead of running it as an unhurried tabletop, and pull your broker into that conversation so the regulatory timeline and your own notification timing get worked out together.

Frequently asked questions

Does the CRA apply to US companies?

Yes, if they distribute products with digital elements into an EU member state. Physical presence in the EU isn’t required.

Does a breach of our corporate network trigger a CRA report?

No. The obligation attaches to actively exploited vulnerabilities and severe incidents affecting products you’ve placed on the market. Entity-level incidents may be reportable under NIS2 or the General Data Protection Regulation instead.

Do we have to report a critical vulnerability nobody is exploiting?

Not under the CRA reporting obligations. The trigger is active exploitation.

Is the 72-hour notification in addition to the 24-hour one?

No, it’s inclusive. The 72 hours run from the same starting point, not from the end of the first 24.

What happens to the rest of the CRA?

The remaining obligations, including software bills of materials, vulnerability handling processes, and risk assessments, apply from December 11, 2027.

Are CRA fines covered by cyber insurance?

That depends on the policy and the jurisdiction, and regulatory fines are treated differently across markets. Ask your broker to walk you through what your specific policy says.

Nothing here should be taken as legal, financial, or security advice for your specific situation — see the full disclaimer at cyberresilience.com/disclaimer.