Cyber Resilience Act: what the new reporting duty asks

If you make a software product or a connected device for the EU market, the Cyber Resilience Act now puts you on a short clock. When you learn that a vulnerability in one of your products is being actively exploited, or that a severe incident has hit its security, you have 24 hours to warn the authorities and 72 hours to send them a fuller notification, with a final report to follow. The duty applies now, and it covers products already on the market as well as new ones.

What changed on 11 September 2026

On 11 September 2026, the reporting duty in Article 14 of the Cyber Resilience Act began to apply.¹ It requires manufacturers to report two kinds of event: actively exploited vulnerabilities in their products, and severe incidents that have an impact on the security of those products.

It isn’t limited to new products. It also covers products in scope that were already on the market, whenever they were placed there. Most of the rest of the Act applies from 11 December 2027.

Does it apply to you

The Act covers products with digital elements made available on the EU market: software or hardware whose intended purpose, or reasonably foreseeable use, includes a direct or indirect data connection to a device or network.¹ Components sold on their own count too.

You’re the manufacturer if you develop or make a product, or have it developed or made, and market it under your own name or trademark, whether you charge for it or not. “Made available” means supplied in the course of a commercial activity. A free product can still qualify, for example if you charge for support beyond its cost or use it to sell other services.

Free and open-source software isn’t covered when its maker doesn’t monetise it.¹ Open-source software stewards, such as foundations that support projects intended for commercial use, have a lighter regime, and their reporting duty starts on 11 December 2027.²

Some products sit under their own rules instead: medical devices, type-approved vehicles, certified aviation products and marine equipment. Products made only for national security or defence are outside the Act too.¹

On 27 July 2026 the Commission published guidance that covers scope, including remote data processing and open source, as well as the reporting duty. It includes 67 practical examples.³ It isn’t binding.

The clock: 24 hours, 72 hours, then the final report

Two kinds of event start the clock. An actively exploited vulnerability is one where there’s reliable evidence that a malicious actor has exploited it in a system without the owner’s permission.¹ A flaw found in good-faith testing or research doesn’t have to be reported.

A severe incident is one that affects, or could affect, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. It also covers an incident that has led, or could lead, to malicious code in the product or on a user’s systems. The Act’s example is an attacker slipping malicious code into the channel a manufacturer uses to release security updates.

For both, the clock starts when you become aware. The Act asks for the first two steps without undue delay, and the times below are the latest they can arrive.

You must also inform the users affected, and all users where that’s appropriate, about the vulnerability or incident and, if needed, the steps they can take. Where appropriate, that information should be structured and machine-readable.¹

The early warning itself asks for very little. What’s hard is having the answers inside a day: whether the exploitation is real, which of your products and versions contain the flaw, and where they’re sold. That’s a test of your records and your on-call process more than of your paperwork.

Member States set the penalties. For breaches of the reporting duty, the Act sets maximum fines of €15 million or, for a company, 2.5% of worldwide annual turnover, whichever is higher.¹ Micro and small enterprises can’t be fined for missing a 24-hour deadline, though the duty itself and the later deadlines still apply to them.⁴

The Act also says that notifying doesn’t, on its own, increase your liability.¹

One place to report

Reports go through the Single Reporting Platform, run by ENISA, the EU’s cybersecurity agency.⁵ You report once, and the platform passes the information to the authorities that need it.

Each report is addressed to the CSIRT, the national computer security incident response team, of the Member State where your main establishment in the EU is. Except in a few exceptional cases the Act sets out, it reaches ENISA at the same time.¹ That CSIRT passes it on to the CSIRTs of the other EU countries where the product is available.²

If you have no main establishment in the EU, the Act sets an order instead: the country of the authorised representative, importer or distributor handling the most of your products, in that order, and failing all three, the country where most of your users are.¹

Manufacturers submit reports through assigned representatives they register on the platform.⁵ It went live on 11 September 2026 in what ENISA calls its initial operating capability, and ENISA says its guidance will be updated as the platform develops.

The CSIRTs that receive reports must also offer helpdesk support on the duty, particularly to micro, small and medium-sized companies.¹

Register before you need to. The first hours of an exploit are the wrong time to find out who holds the account.

What comes next

On 11 December 2027, most of the rest of the Act applies.¹ A product placed on the market before that date falls under its other requirements only if it’s substantially modified from then on.

The requirements for handling vulnerabilities include a software bill of materials covering at least each product’s top-level dependencies, in a commonly used machine-readable format. They also include a policy on coordinated vulnerability disclosure and a contact address for reporting vulnerabilities.

Open-source software stewards start reporting on the same date.²

One proposal is worth knowing about, though as proposed it wouldn’t change this duty. In its Digital Omnibus of November 2025, the Commission proposed a single entry point, run by ENISA and building on its experience with this platform, for incident reports under other EU laws, including NIS2, the GDPR and DORA.⁶ The Commission says it wouldn’t change existing reporting obligations or who receives the reports. It was still a proposal when we checked on 28 September 2026, with no agreement recorded between the Parliament and the Council.⁷

What to have in place now

The duty applies today, and it’s only as reliable as three things behind it.

A way to hear about vulnerabilities

The clock starts when you become aware, so the route by which you become aware matters. Publish one address for vulnerability reports, send what arrives to people who can act on it, and write down what happens next. From December 2027 the Act requires a contact address and a coordinated disclosure policy anyway.¹ The reporting duty depends on them now.

Someone who can make the call

Someone has to decide quickly whether there’s reliable evidence of exploitation, and send the early warning. Name an owner and a deputy, register them on the platform, and give them the authority to report without waiting for a meeting. Agree with your legal team in advance on what counts as becoming aware, because that’s when the 24 hours start.

They’ll need records to decide from: logs of what happened that an attacker couldn’t alter. For AI features, that means a record of what an agent read and which tools it called, kept where the agent can’t change it, as we explain in how to limit what a fooled AI agent can do.

A list of what each product contains

The early warning for a vulnerability asks, where applicable, which EU countries the product is available in, and the notification asks about the product and the vulnerability. Both are quick to answer if you know which products and versions contain which components, and where each version is sold. The software bill of materials that the Act requires from December 2027 is the core of that list, and building it now saves time in the first hours of any incident. It’s far easier to keep current when your build pipeline produces it for every release than when someone maintains it by hand.

What to ask your team

The deadline isn’t the hard part. Knowing enough to meet it is.

For each product you sell in the EU, three answers show where you stand:

• who decides that a vulnerability is being exploited, who sends the early warning, and whether they’re registered on the platform
• how long it takes to list every version that contains a given component, and the EU countries where each is available
• how you’d tell affected users what to do, and how quickly

Then the question that matters: if a customer told us today that one of our products was being exploited, could we send an accurate early warning by this time tomorrow, and who would send it?