Article partially generated by artificial intelligence.
TL;DR: The Cyber Resilience Act (CRA) has required, since 11 September 2026, manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents. An early warning is due within 24 hours of becoming aware, a full notification within 72 hours and a final report later. Reports go through the ENISA single reporting platform to the national CSIRT. The duty also covers products already on the market. This article explains what must be reported, the deadlines, and how to build a process that can meet a 24-hour clock.
This post is part of our NIS2 and Cyber Resilience Act guide for software owners, which covers every duty that lands on applications and products.
Key facts:
The Cyber Resilience Act places the reporting duty on the manufacturer of a product with digital elements: the company that designs or makes a product and places it on the EU market under its own name. A product with digital elements can be hardware with software inside (a controller, a meter, a camera, an EV charger, a machine with a control panel) or standalone software sold to customers. Open-source software stewards have obligations too, to the extent they support components used commercially.
The CRA excludes products with their own cybersecurity rules, such as medical devices and motor vehicles. SaaS is generally out of scope, unless remote data processing is essential to a product’s function, for example a cloud service without which a smart home device does not work.
The Cyber Resilience Act defines two kinds of report. The first covers an actively exploited vulnerability: a flaw for which there is reliable evidence that someone has exploited it in a system without the owner’s permission. Knowing about a vulnerability, even a critical one, does not trigger the duty; evidence that it is being used in attacks does.
The second covers a severe incident affecting the security of the product. That means an event that undermines the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions, or that led to malicious code running in the product or in users’ systems. One example: an attacker takes over the update server and pushes modified firmware.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | within 24 hours of becoming aware | within 24 hours of becoming aware |
| Notification | within 72 hours: product details, nature of the vulnerability, measures taken | within 72 hours: nature of the incident, initial assessment, corrective measures |
| Final report | no later than 14 days after a fix or mitigation is available | within one month of the notification |
A single report goes at the same time to the CSIRT acting as coordinator in the manufacturer’s main Member State and to ENISA. According to ENISA’s FAQ on the reporting platform, the platform is meant to simplify reporting, especially for products sold in several countries. Manufacturers must also inform affected users about the vulnerability or incident and how to reduce the risk.
The 24-hour clock starts when the manufacturer becomes aware of an exploited vulnerability, not when legal finishes its analysis. In practice, a company needs four things in place before anything happens:
The third point is the most common gap among device makers. We cover how to prepare an SBOM in a separate guide.
The European Commission’s general explanations are on its Cyber Resilience Act policy page.
A manufacturer that is also an essential or important entity under NIS2 can face two separate reporting duties. The Cyber Resilience Act concerns the security of the product the manufacturer sells: a flaw in a controller’s firmware or an incident that hit customers’ devices. NIS2 and the national laws that implement it, such as Poland’s KSC Act, concern incidents in the company’s own systems, for example an attack on its network, production systems or email, reported to the national CSIRT through the national channel.
One event can trigger both. If an attacker breaks into the manufacturer’s network, takes over the update server and pushes modified software to customers, that is both an incident in the company’s systems under NIS2 and a severe incident affecting product security under the CRA. Deadlines are similar, but forms, recipients and the information required differ. That is why an incident procedure needs two paths and a clear rule on who decides which one to trigger, and when to trigger both.
Take a maker of heating controllers with a Wi-Fi module. On Monday at 9:00, a security researcher writes to security@ that a flaw in the networking library is being used to take over devices, with examples from the wild.
Without an SBOM, the first step can take days instead of hours, and the 24-hour deadline passes before anyone knows which devices are affected. That is why the reporting process and the SBOM are best treated as one project.
Many vulnerabilities do not come from the manufacturer’s own code but from components: a radio module, a real-time operating system, a cryptographic library. The Cyber Resilience Act does not excuse a manufacturer from reporting just because someone else made the mistake. If a vulnerable component is in the product and the flaw is actively exploited, the clock runs for the manufacturer. Contracts with component suppliers should therefore require prompt notice of vulnerabilities and delivery of fixes, and monitoring should follow key suppliers’ security advisories. The CRA also requires a manufacturer that finds a vulnerability in a component, including open source, to report it to whoever maintains that component.
Sanddev helps device and software manufacturers build the technical side of the process: component inventories and SBOM generation in the build pipeline, vulnerability monitoring, secure update mechanisms and product code reviews. We have worked with manufacturing and semiconductor companies; see the industries we work with. Legal classification of a product stays with your lawyers.
Cyber Resilience Act reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026. The rest of the CRA, including CE marking and SBOM requirements, applies from 11 December 2027.
A manufacturer has 24 hours to send an early warning and 72 hours to file a full notification after becoming aware of an actively exploited vulnerability. The final report is due no later than 14 days after a fix is available.
Vulnerabilities and severe incidents under the CRA are reported through the ENISA single reporting platform. Each report reaches ENISA and the coordinating CSIRT in the manufacturer’s main Member State at the same time.
Yes, for reporting. The Cyber Resilience Act reporting obligations also cover products with digital elements placed on the market before 11 December 2027, whenever the manufacturer becomes aware of an exploited vulnerability or severe incident.
For breaching its reporting obligations, the Cyber Resilience Act allows administrative fines of up to €15 million or up to 2.5% of the manufacturer’s total worldwide annual turnover, whichever is higher.
No. The CRA reporting duty arises when a vulnerability is actively exploited, meaning there is reliable evidence someone used it without the system owner’s permission. Vulnerabilities without that evidence are fixed through the normal process.
OWASP Top 10 is the list of the most serious risk categories in web applications. AI-built apps, for example in Lovable on a Supabase database, usually fail exactly where it says – above all in access control. Here is a 12-point checklist to run before an auditor asks.
Third-party risk management is now a legal duty for companies covered by NIS2. Supply chain security is one of the minimum risk-management measures in the directive, and it reaches the companies that write, maintain and host your software.
An SBOM (software bill of materials) is a list of the libraries, modules and versions a product is built from. From 11 December 2027, the Cyber Resilience Act requires manufacturers of products with digital elements to draw up an SBOM in a commonly used, machine-readable format covering at least top-level dependencies.
