For organizations, this is more than another regulatory milestone. It introduces a new operational responsibility that connects product security, vulnerability management, incident response and regulatory reporting, with tight deadlines when something goes wrong. The reporting process follows a staged timeline similar to the approach businesses may already recognize from NIS2, with an initial early notification within 24 hours, a more detailed one within 72 hours, and a full report within 1 month from the first notification. For organizations already operating NIS2 incident-reporting processes, this provides a useful starting point, although the CRA introduces its own reporting triggers, scope and product-specific requirements. 

This makes internal escalation particularly important. Organizations cannot wait until a technical investigation is complete before considering their regulatory obligations. Security teams need a clear route for escalating potentially reportable events and determining quickly whether the CRA criteria have been met. 

Importantly, the requirements are not limited to products launched after September. Existing and legacy products can also fall within the reporting regime, meaning organizations need visibility across their broader product portfolio. 

What Needs To Be Reported?

Article 14 establishes two main reporting obligations for manufacturers. 

The first concerns actively exploited vulnerabilities. When a manufacturer becomes aware of reliable evidence that a vulnerability affecting its product has been exploited by a malicious actor, this may trigger a reporting obligation. A vulnerability being discovered or rated as critical does not, on its own, necessarily make it reportable under this requirement; the key factor is evidence of active exploitation. 

The second concerns severe incidents affecting the security of a product. This can include incidents that negatively affect, or are capable of negatively affecting, the product’s ability to protect important or sensitive data or functions. It can also include incidents that result, or could result, in malicious code being introduced or executed through the product or connected systems. 

Existing Products Are Also in Scope

One of the most important aspects of the September deadline is that it does not only apply to new products. 

Under the CRA’s transitional provisions, the Article 14 reporting obligations also apply to products with digital elements that were placed on the EU market before the CRA becomes fully applicable in December 2027. 

This matters for organizations with established product portfolios. Businesses may naturally be focusing their broader CRA compliance programs on new products and upcoming releases. For reporting, however, the scope needs to be wider. 

Consider a connected device that was first placed on the EU market in 2022. If the manufacturer becomes aware after 11 September 2026 that attackers are actively exploiting a vulnerability affecting that product, its age does not, by itself, exclude it from the reporting requirements. 

The same issue can arise with older software versions, routers and network equipment, IoT devices, connected industrial products, firmware and other products with digital elements that remain in use. 

This makes understanding the existing product landscape an important part of reporting readiness. 

What About Third-Party Components?

The reporting challenge also extends into the software and hardware supply chain. 

Modern digital products typically depend on a combination of proprietary code, open-source software, libraries, firmware and third-party components. A vulnerability does not necessarily have to originate in code developed by the manufacturer itself to become relevant under the CRA. 

If an actively exploited vulnerability in a third-party component affects a manufacturer’s product, the manufacturer needs to understand the impact on its own product and assess its reporting responsibilities accordingly. 

In practice, this puts greater emphasis on product and component visibility. Organizations need to be able to determine which products and versions contain an affected component, whether those products have been placed on the EU market and whether exploitation creates a reportable event. 

Preparing for September & for the Wider CRA

The immediate priority is ensuring that the organization can meet the reporting requirements from 11 September 2026. That means understanding the relevant product portfolio and having a clear process for identifying, assessing, escalating and reporting potentially relevant vulnerabilities and incidents. 

As the December 2027 deadline approaches, organizations will need to address requirements across the product lifecycle, including cybersecurity risk management, vulnerability handling, secure development, documentation and governance. 

Our approach reflects these two deadlines. We can initially support organizations to enable their reporting capabilities by focusing on putting the processes, responsibilities and practical capability in place to meet the September reporting requirements. 

From there, the activities can develop into a broader CRA compliance program, covering areas such as secure product development, vulnerability management, technical and organizational controls, governance and strategic CRA readiness. The aim is to integrate CRA requirements into the way products are developed, secured and managed over time, rather than treating compliance as a one-off exercise ahead of a regulatory deadline. 

With 11 September approaching, the immediate question for manufacturers is therefore relatively simple: if a reportable event happened tomorrow, would the organization know what to do, and could it do it within the timeframe? 

Ready to Prepare for the Cyber Resilience Act?

Whether you’re assessing your current readiness or working toward compliance, our specialists can help you identify gaps, strengthen product security, and prepare for CRA requirements.