The CRA Reporting Obligation From September 2026: What Manufacturers Must Prepare Now

The Cyber Resilience Act (CRA) has been in force since December 2024, but its full application only follows on 11 December 2027. Between those dates lies a milestone that many product teams still underestimate: on 11 September 2026 the reporting obligation under Article 14 takes effect. From that day, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents to the authorities within tight deadlines. The real hurdle here is not the reporting day itself, but the question of whether a manufacturer even notices an ongoing exploitation of its product in time.

This article deliberately focuses on the reporting obligation and its practical implementation. The broader CRA requirements such as Secure by Design, conformity assessment and CE marking are covered elsewhere.

What Changes on 11 September 2026

The CRA staggers its obligations over time. Most requirements, from the essential security requirements to conformity assessment, only become binding with full application on 11 December 2027. For manufacturers, only the reporting obligation is brought forward: it already applies from 11 September 2026.

With this, the legislator has prioritised exactly the part of the CRA that responds to ongoing threats. The logic behind it is understandable. Authorities and other manufacturers should learn as early as possible when a vulnerability is being actively attacked, so that countermeasures can be coordinated. For manufacturers, however, this means they need a working reporting process more than a year before full application.

Who Is Affected: Manufacturers, Not Operators

The CRA reporting obligation is directed at manufacturers of products with digital elements. This covers both software and connected hardware, from the industrial gateway through the IoT component to application software placed on the EU market. It is a product and manufacturer perspective: whether you are affected depends on whether you place a product on the market, not on how critical your own operations are.

This is precisely where the most common confusion arises, namely with NIS-2. The NIS-2 Directive addresses operators and entities, and thus the organisational perspective. It asks how critical a company is for the economy and society, and ties reporting obligations for incidents in its own operations to that. The CRA, by contrast, asks about the product and obliges its manufacturer to report vulnerabilities and incidents related to that product.

A company may well be covered by both regimes. A manufacturer of network equipment that also qualifies as an essential entity under NIS-2 then operates two separate reporting paths with different triggers and recipients. Documenting this separation cleanly is one of the first tasks in preparation.

What Must Be Reported

Two categories of events are subject to reporting. First, actively exploited vulnerabilities in the product. Second, severe security incidents that have an impact on the security of the product with digital elements.

The decisive and often misunderstood term is "actively exploited". This does not mean the theoretical exploitability of a vulnerability as described by a CVSS score, but evidence that attackers are actually exploiting the flaw. It requires proof of real attacks, for example from telemetry, from an incident analysis or from reliable threat intelligence. A critical but so far only potentially exploitable vulnerability does not, on its own, fall under this reporting obligation. Only when there are indications of real exploitation does the clock start.

This distinction is central for product owners because it defines the trigger for the report. The transition from "it could be exploited" to "it is being exploited" is exactly the moment a manufacturer must be able to detect reliably.

The Deadlines: 24 Hours, 72 Hours, 14 Days

Reporting is multi-stage, and the deadlines are tight.

1. Early warning within 24 hours: As soon as a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, an initial early warning must be submitted within 24 hours.
2. Detailed notification within 72 hours: This is followed by a more detailed notification with the details known by then about the vulnerability or incident and about initial countermeasures.
3. Final report: For vulnerabilities, a final report is due no later than 14 days after a corrective measure, usually a patch, becomes available. For severe incidents, the final report must be submitted within one month of the detailed notification.

The 24-hour clock starts with becoming aware. This anchor point is important, because it shifts the problem from the reporting to the detection. Whoever notices an exploitation only weeks later has not formally breached the deadline, but has in practice missed the chance for a coordinated response.

The Reporting Path: Single Reporting Platform, BSI and ENISA

A central channel has been created for reporting. Through the CRA Single Reporting Platform (SRP), manufacturers report once, instead of having to inform several national authorities individually as before. The report is addressed to the CSIRT of the member state in which the manufacturer has its main establishment, and is forwarded to ENISA at the same time. For manufacturers headquartered in Germany, the BSI with CERT-Bund is the competent body.

The platform is scheduled to be operational by 11 September 2026, in time for the start of the reporting obligation. The European Commission summarises the process and the reporting formats on its page on the CRA reporting obligations. Anyone who knows the technical reporting path in advance and runs through it once loses no time on credentials, responsibilities or format questions when it matters.

The Real Challenge: Detection and Process

In practice, the 24-hour deadline rarely fails at filling in a form. It fails because a manufacturer does not notice the active exploitation of its product at all. A software or device vendor does not directly see the attacks on shipped products in third-party networks. The information comes from outside: from security researchers, from customers, from threat intelligence feeds or from the analysis of a reported incident.

This shifts the task. The reporting obligation is at its core a detection and process requirement. A manufacturer must, firstly, be able to pick up and correctly classify signals of real exploitation, and secondly decide internally fast enough whether an event is reportable and who is responsible for the report. Both require defined structures, not an ad-hoc reaction.

To make matters harder, the 24 hours run from becoming aware, not from the start of a business day. A tip that arrives on a Friday evening cannot be left until Monday. Without a clear on-call arrangement and escalation paths, the deadline is structurally impossible to meet.

What Manufacturers Should Do Now

The remaining time until September 2026 should be used to build the processes, not to wait for the platform. Concretely, we recommend:

• Establish an internal reporting process and a PSIRT. A Product Security Incident Response Team consolidates reports, assesses them and is responsible for timely submission. Responsibilities, deputies and on-call arrangements must be named so that the 24-hour clock is also served at the weekend.
• Build up monitoring and threat intelligence. Sources of indications of active exploitation must be observed systematically, from telemetry of your own products through CVE and exploit feeds to reports from customers and researchers.
• Set up Coordinated Vulnerability Disclosure. A reachable, documented reporting channel for external reporters ensures that critical information reaches the manufacturer instead of getting lost in mailboxes. A security.txt and a clear contact address are the minimum.
• Distinguish the reporting obligation from NIS-2. Anyone covered by both regimes documents separate triggers, deadlines and recipients, so that in an emergency the wrong path, or no path at all, is not chosen.
• Practise the emergency. A tabletop exercise reveals whether the chain from becoming aware to the early warning actually holds within 24 hours. This is exactly where the gaps show that become expensive in a real incident.

The precise wording of the obligations is set out in Article 14 of Regulation (EU) 2024/2847 and should be used as the binding reference when designing the process. The SBOM obligation, by the way, is not part of the September reporting obligation but of the full application from December 2027; in Germany, BSI TR-03183-2 specifies the expected format.

Conclusion

The CRA reporting obligation from 11 September 2026 is not a form problem but a process and detection requirement. What matters is not whether a manufacturer can fill in a reporting form, but whether it notices a real exploitation of its product in time and acts internally fast enough. Whoever sets up a PSIRT, robust monitoring and a rehearsed reporting process now not only meets the obligation formally but becomes genuinely capable of acting. The remaining months are short enough not to wait.