The Report Is Not the Remedy

The CRA treats a notification as an intervention point in a product’s life, not as the end of a compliance task. This chapter connects the reporting duty to the manufacturer’s risk assessment, component knowledge, support period, user communication, security updates, voluntary reporting, open-source stewardship, and downstream supervision. The practical question is whether the information sent through the reporting chain can actually reduce exposure and remain useful after the first warning.

The product knowledge that makes a fast report possible

A 24-hour reporting obligation exposes the quality of the work done before an incident. Article 13 requires a manufacturer to assess the cybersecurity risks associated with a product with digital elements and use the result across planning, design, development, production, delivery, and maintenance. The assessment must be documented and updated as appropriate during the support period. It considers the product’s intended purpose and reasonably foreseeable use, its operating environment, the assets to be protected, and the length of time it is expected to be used.

This information is not merely design history. When an active vulnerability appears, it helps the manufacturer identify what the product is supposed to protect, how it is connected, which functions may be affected, and which users may need advice. The assessment also explains how the product and its vulnerability-handling requirements are implemented. Without that context, the reporting team may know that a flaw exists but struggle to say why it matters to the product or what a useful user measure would be.

Component knowledge is just as important. Manufacturers must exercise due diligence when integrating third-party components, including free and open-source components, so that those components do not compromise the cybersecurity of the finished product. When a manufacturer identifies a vulnerability in an integrated component, it must report the vulnerability to the person or entity manufacturing or maintaining that component and address and remediate it under the vulnerability-handling requirements. If the manufacturer developed a software or hardware modification to address the component weakness, the Regulation says the relevant code or documentation should be shared with the component maintainer where appropriate and, where appropriate, in a machine-readable form.

Annex I supports that relationship by requiring manufacturers to identify and document vulnerabilities and components, including a software bill of materials in a commonly used and machine-readable format covering at least the product’s top-level dependencies. The present legal text does not specify every format detail; later implementing acts may do that. The stable point is that a manufacturer cannot treat the component boundary as a blind spot. The finished product’s reporting duty depends on knowing enough about the dependencies that shape its security.

The same pre-incident work supports coordinated vulnerability disclosure. Manufacturers must put in place and enforce a policy for receiving and handling potential vulnerabilities and must provide a contact address that facilitates sharing information about vulnerabilities in the product and its third-party components. They must also apply effective and regular tests and reviews of product security, address and remediate vulnerabilities without delay, and provide mechanisms for secure update distribution.

These obligations do not prescribe one organizational chart or one software tool. They establish observable capabilities: a product can be identified, its important components can be related to it, a report can reach a responsible team, and a possible fix can be connected to users and the product’s support period. Those capabilities reduce the time spent reconstructing ownership while the statutory clock is already running.

The report must reach users as usable action

The authority-facing notification is only one part of the response. After becoming aware of an actively exploited vulnerability or a severe incident affecting the security of a product, the manufacturer must inform impacted users, and where appropriate all users, about the vulnerability or incident and the risk-mitigation and corrective measures they can deploy. Where appropriate, that information should be provided in a structured, machine-readable format that is easily processed automatically.

This obligation changes the meaning of “available information” in an early notification.