The most immediate requirement is a 24-hour early warning. When a manufacturer becomes aware of an actively exploited vulnerability in one of its products, it must submit an early warning within 24 hours. Severe incidents affecting the security of a product are also subject to the CRA's reporting requirements.
For manufacturers selling software or hardware in the EU, this changes the operational requirements around vulnerability detection, incident response, and reporting.
In this article, we will discuss what happens on September 11, 2026, what Article 14 requires, which products and organizations are subject to the deadline, and how the CRA reporting process works.
The Cyber Resilience Act (CRA) is an EU regulation establishing cybersecurity requirements for products with digital elements placed on the European market.It covers a broad range of connected hardware and software, from consumer devices and industrial equipment to operating systems, applications, and other software products.
The CRA introduces cybersecurity requirements throughout the product lifecycle. These include requirements relating to vulnerability handling, security updates, risk assessment, technical documentation, conformity assessment, and reporting of certain vulnerabilities and incidents.
The regulation entered into force on December 10, 2024. Its requirements do not all become applicable at the same time. Different obligations take effect on different dates, making it important to distinguish the September 2026 reporting deadline from the broader CRA compliance deadline.
September 11, 2026 is the date when the CRA's Article 14 reporting obligations become applicable.
From this date, manufacturers must report:
The reporting process is based on a staged timeline. The first notification must be submitted quickly, followed by more detailed information and, where applicable, a final report.
This is separate from the CRA's broader requirements, most of which become applicable on December 11, 2027.
In other words, September 11, 2026 is not the full CRA compliance deadline. It is the start of the CRA's mandatory vulnerability and incident reporting obligations.
The CRA requires manufacturers to submit an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident covered by the regulation. The 24-hour period is therefore not necessarily active from the moment an attack begins. It starts when the manufacturer becomes aware of the relevant vulnerability or incident.
This distinction makes detection and internal escalation particularly important. A manufacturer cannot respond within the required reporting window if it does not have adequate visibility into the security of its products or an established process for escalating security events. The reporting process then continues beyond the initial warning.
For actively exploited vulnerabilities, manufacturers must provide a more detailed notification within 72 hours of becoming aware. A final report is required within 14 days after a corrective or mitigating measure becomes available.
For severe incidents, the detailed notification is also due within 72 hours, while the final report is due within one month after the incident notification.
Article 14 of the Cyber Resilience Act establishes the requirements for reporting vulnerabilities and incidents.
It covers two main categories:
An actively exploited vulnerability is a vulnerability for which there is evidence that malicious actors are exploiting it in real-world attacks. This is an important distinction from simply discovering a vulnerability. The CRA does not require manufacturers to submit the same type of report for every vulnerability they discover. Article 14 specifically addresses vulnerabilities that are being actively exploited.
Article 14 also covers severe incidents that affect the security of a product with digital elements. The assessment of whether an incident is severe depends on the CRA criteria and its supporting implementation framework. For manufacturers, this means that vulnerability management and incident response processes need to do more than identify technical problems. They also need to support the assessment of whether an event falls within the CRA's reporting obligations.
The CRA establishes a staged reporting process.
The manufacturer submits an early warning after becoming aware of an actively exploited vulnerability or severe incident. The purpose of this first notification is to provide the relevant authorities with an initial indication that a reportable event has occurred.
A more detailed notification follows within 72 hours. This provides additional information about the vulnerability or incident and allows authorities to better understand the nature and potential impact of the event.
The final reporting deadline depends on the type of event.
For an actively exploited vulnerability, the final report is due within 14 days after a corrective or mitigating measure becomes available.
For a severe incident, the final report is due within one month after the incident notification.
Reports are submitted through the reporting mechanism designated for CRA notifications, including the European Union Agency for Cybersecurity (ENISA) and its Single Reporting Platform.
Failing to meet the CRA's reporting obligations can result in penalties set by the relevant EU Member State.
For certain serious infringements, fines can reach €15 million or 2.5% of the company's total worldwide annual turnover from the preceding financial year, whichever is higher. The maximum fine does not apply automatically to every missed reporting deadline. The actual penalty depends on the nature of the infringement and the applicable national enforcement rules.
Microenterprises and small enterprises cannot be fined specifically for failing to meet the 24-hour reporting deadline, but they are still required to comply with the CRA's reporting obligations. For manufacturers of all sizes, the takeaway is simple: the 24-hour deadline makes timely detection and a clear incident response process essential.
The information required depends on the type of event and the stage of the reporting process.
At a practical level, manufacturers need to be able to establish:
This makes accurate asset and product inventories particularly important. If security teams cannot quickly determine which products are affected, which versions are deployed, or whether an issue is occurring in the field, meeting a 24-hour reporting requirement becomes significantly more difficult.
Yes, the CRA reporting obligations can apply to products that are already present on the EU market.
This is particularly important for manufacturers with long product lifecycles or large installed bases.
A product does not become irrelevant to the CRA simply because it was developed or released before the regulation entered into force. Where the CRA's transitional provisions apply, products already on the market can remain subject to relevant obligations. For organizations with products deployed across customer environments, this means CRA preparation should not focus exclusively on upcoming releases. Existing products, older software versions, firmware, and long-running deployments should also be a part of assessing vulnerability detection and reporting capabilities.
The CRA places the reporting obligation primarily on manufacturers of products with digital elements.
This is an important distinction from other EU cybersecurity legislation.
For example, NIS2 establishes cybersecurity and incident reporting obligations for covered essential and important entities. The CRA, by contrast, focuses specifically on cybersecurity requirements for products with digital elements and places particular obligations on manufacturers.
An organization can potentially be affected by both frameworks, but the obligations are not interchangeable. The reporting timelines may look similar, particularly the 24-hour early warning and 72-hour notification, but the regulatory scope and trigger are different.
Organizations already preparing for NIS2 may notice similarities between the two reporting frameworks. Both regulations introduce strict reporting timelines and require organizations to detect, assess, escalate, and report certain cybersecurity events quickly.
However, they address different responsibilities.
NIS2 focuses on significant incidents affecting covered entities and their network and information systems.
The CRA focuses on vulnerabilities and severe incidents affecting products with digital elements, with reporting obligations placed on manufacturers.
This means organizations should not assume that a process designed for NIS2 automatically satisfies CRA requirements. At the same time, the operational capabilities behind both frameworks overlap. Effective monitoring, vulnerability management, incident detection, internal escalation, documentation, and response processes can support compliance with multiple regulatory requirements.
The CRA's 24-hour reporting requirement creates a practical challenge for manufacturers: they need to know when something is happening in products that may already be deployed across thousands or millions of customer environments.
Traditional security processes often depend on vulnerability reports by researchers, customers, security teams, or external sources. While these channels remain important, they do not necessarily provide immediate visibility into what is happening in deployed products. For manufacturers of digital products, runtime security monitoring can provide an additional source of information about attacks occurring in the field.
For example, mobile applications can be subject to tampering, hooking, reverse engineering, and other attacks after deployment. Security controls that detect these activities can help security teams gain visibility into potential attacks and investigate whether an event represents a reportable vulnerability or incident. The technology does not replace the CRA reporting process. It can, however, contribute to the detection and awareness capabilities that make a timely response possible.
With the reporting obligations taking effect on September 11, manufacturers should focus on their ability to detect, assess, and escalate relevant security events.
A practical preparation checklist includes:
Create an up-to-date inventory of products with digital elements placed on the EU market, including existing products and deployed versions.
Establish how vulnerabilities are identified, assessed, prioritized, and escalated, particularly when there is evidence of active exploitation.
Determine exactly how your organization establishes that it has become aware of a vulnerability or incident. This is critical because the reporting clock starts from this point.
Define who receives security alerts, who determines whether an event is reportable, and who is responsible for submitting the required notifications.
A documented process is not enough. Teams should test whether they can move from detection to assessment and escalation within the required timeframe.
Review legacy products and deployed versions rather than limiting CRA preparation to new product development.
The September 11, 2026 deadline is more than a new reporting date on the compliance calendar. It introduces a tighter connection between product security monitoring and regulatory response.
Manufacturers need to understand what is happening across their products, determine when an event becomes relevant from a regulatory perspective, and have the processes in place to respond within hours rather than days.
For cybersecurity teams, this reinforces the importance of visibility beyond the development environment. Security does not end with product release. Manufacturers need appropriate capabilities to understand how products behave and how they are being attacked in real-world environments throughout their lifecycle.
The organizations best positioned to meet the CRA's reporting requirements will be those that can connect security detection with clear internal decision-making and response processes.
