CRA reporting obligations for manufacturers: Art. 14 in practice

What does a manufacturer have to report?

Art. 14 has two triggers. An actively exploited vulnerability is one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner” (Art. 3(42)). A severe incident is one that negatively affects or is capable of negatively affecting the ability of the product to protect data or functions, or that has led or is capable of leading to malicious code in the product or in a user's network (Art. 14(5)).

A published CVE on its own does not yet trigger the obligation. According to the BSI's guidance, a published exploit, proof-of-concept code or port scans are not sufficient evidence of exploitation either.

An attack on the manufacturer itself is not automatically an Art. 14 case either. The BSI gives a ransomware incident as an example: it becomes reportable only if it affects the security of the product or can lead to manipulation of software, updates, signing keys or product functions.

Which deadlines apply: 24 hours, 72 hours, 14 days?

24hours

Early warning after you become aware of it, with the Member States in which the product has been made available. For an incident, also whether it is suspected of being caused by unlawful or malicious acts.

72hours

Notification with general information about the product, the nature of the exploit and the corrective or mitigating measures taken or possible.

14days

For a vulnerability: final report no later than 14 days after a fix is available, with description, severity, impact and the security update.

1month

For a severe incident: final report within one month after the 72-hour notification.

What applies to vulnerabilities in bought-in components?

Typical cases in firmware: a vulnerability in a third party's RTOS, TLS stack or network stack. The Commission's guidance of 27 July 2026 is clear here: where your product contains an actively exploited vulnerability originating from a third-party component, you, as manufacturer of the product, notify it (C(2026) 5252, point 218).

If the vulnerability cannot be exploited in your product, for example because the vulnerable code is not reachable, or has not been exploited in your product, it is not reportable for you. You still report it to whoever manufactures or maintains the component (Art. 13(6)) and handle it under Annex I, Part II.

Both cases need the same answer: is the component, in the affected version, in your firmware, and in which releases?

To whom and how is it reported?

The report goes simultaneously to the CSIRT designated as coordinator and to ENISA, via the single reporting platform under Art. 16 (Art. 14(1)). The competent CSIRT is the one of the Member State where the decisions related to the cybersecurity of your products are predominantly taken (Art. 14(7)). For manufacturers based in Germany it is CERT-Bund at the BSI. If you select the wrong CSIRT, ENISA says the notification may be invalidated and has to be submitted again.

ENISA's platform has been in operation since 11 September 2026, in version 1.2.1 since 20 October 2026. To sign in, the reporting representative needs a personal EU Login account with two-factor authentication. According to the BSI, there is no obligation to register before the first case to report, and reports are to be written in English. The platform itself is available in English only.

As soon as you know of the vulnerability or the incident, you inform the impacted users about the vulnerability and the mitigation, where appropriate in a structured, machine-readable format (Art. 14(8)).

What does the ENISA platform ask for in practice?

When is dissemination delayed?

The CSIRT that receives your notification passes it on to the CSIRTs of the Member States where your product has been made available (Art. 16(2)). Delegated Regulation (EU) 2026/881 sets out when it may wait: where the risks of dissemination outweigh its benefits because of the sensitivity of the information, protocols such as the Traffic Light Protocol cannot mitigate them, and one of four conditions is met. One concerns manufacturers directly: you have informed the CSIRT that an effective risk mitigation measure, such as a security update or user guidance, is expected within 72 hours. If it does not come within that time, the CSIRT disseminates the notification (Art. 3(a)).

Only in particularly exceptional circumstances under the third subparagraph of Art. 16(2) does ENISA, too, initially receive partial information only. You state these circumstances in the 72-hour notification.

What do I need to know in the first 24 hours?

The early warning asks for the product and the Member States. You can only answer that if you know which of your shipped firmware versions contain the affected component, and in which version. Without a bill of materials per release, the deadline starts with digging through archives.

1. 1

   A bill of materials for each shipped release, from the file that goes onto the device, with the version of each component.

2. 2

   A mapping of release to product and market: which devices with which version were sold in which countries.

3. 3

   A personal EU Login account with two-factor authentication for the person responsible and a deputy, both reachable at weekends too.

4. 4

   A template for the user information under paragraph 8, with mitigation and update path.

5. 5

   Ongoing monitoring of the catalogues of actively exploited vulnerabilities, such as CISA KEV and EUVD, against your bills of materials.

Does it also apply to devices already sold?

The other CRA requirements apply to a device placed on the market before 11 December 2027 only in case of a substantial modification (Art. 69(2)). The reporting obligation under Art. 14, by contrast, applies to all products in scope, including those in the field (Art. 69(3)). For these versions you need the bill of materials just the same.