When is an incident severe under the CRA?

Under Article 14(5), when it negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or when it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems.

What is an example of a severe incident?

Recital 68 gives one: an attacker successfully introducing malicious code into the release channel the manufacturer uses to ship security updates to users.

When is the final report due for a severe incident?

Within one month after the 72-hour incident notification. That is different from actively exploited vulnerabilities, where the final report is due 14 days after a corrective or mitigating measure is available.

Is every breach of our company systems a CRA severe incident?

No. Article 14(3) is about incidents having an impact on the security of the product with digital elements. A breach that does not touch the product's security or your development, production or maintenance processes for it may fall under other rules, such as NIS2 or GDPR, rather than the CRA.

Can the CSIRT make the incident public?

Under Article 17(2), where public awareness is needed to prevent or mitigate a severe incident or handle an ongoing one, or disclosure is otherwise in the public interest, the CSIRT may, after consulting the manufacturer, inform the public or require the manufacturer to do so.

CRA severe incident notification: when and what to report

Is it severe?

Article 14(5) gives two alternative tests. Either is enough:

the incident negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or
it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user.

Note “capable of”: actual harm to users is not required. A compromised build pipeline or signing key can be severe before any user installs a bad update. Recital 68 describes these incidents as ones that affect your development, production or maintenance processes in a way that could raise the cybersecurity risk for users.

Incident or actively exploited vulnerability?

If a malicious actor is using a flaw in the product itself against users, it is usually the vulnerability track. If the attack is on how you build, sign, ship or maintain the product, it is usually the incident track. Record which track you chose and why, because the final report deadline depends on it. Notifying an actively exploited vulnerability.

What each report contains

Early warning (Article 14(4)(a)): whether the incident is suspected of being caused by unlawful or malicious acts, and where applicable the Member States where you know the product has been made available.

Incident notification (Article 14(4)(b)), unless already provided: general information, where available, about the nature of the incident, an initial assessment, corrective or mitigating measures taken and those users can take, and where applicable how sensitive you consider the information.

Final report (Article 14(4)(c)): a detailed description of the incident with its severity and impact, the type of threat or root cause likely to have triggered it, and applied and ongoing mitigation measures.

Copy the report template, or log the case in the free desk and download it filled in.

The one-month final report

The clock runs from the incident notification, not from when the incident is closed. A root cause analysis that is still running at the end of the month does not move the deadline, so plan the investigation around it. ENISA's platform shows a counter one month after the 72-hour notification is submitted; keep your own record as well. CRA Article 14 final report: deadlines and contents.

Telling users, and the public

Article 14(8) requires you to inform impacted users, and where appropriate all users, about the incident and, where necessary, the measures they can take. If you do not do it in time, the CSIRT may inform them itself. Under Article 17(2) the CSIRT may also, after consulting you, inform the public or require you to.

Questions people ask

When is an incident severe under the CRA?: Under Article 14(5), when it negatively affects or is capable of negatively affecting the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or when it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems.
What is an example of a severe incident?: Recital 68 gives one: an attacker successfully introducing malicious code into the release channel the manufacturer uses to ship security updates to users.
When is the final report due for a severe incident?: Within one month after the 72-hour incident notification. That is different from actively exploited vulnerabilities, where the final report is due 14 days after a corrective or mitigating measure is available.
Is every breach of our company systems a CRA severe incident?: No. Article 14(3) is about incidents having an impact on the security of the product with digital elements. A breach that does not touch the product's security or your development, production or maintenance processes for it may fall under other rules, such as NIS2 or GDPR, rather than the CRA.
Can the CSIRT make the incident public?: Under Article 17(2), where public awareness is needed to prevent or mitigate a severe incident or handle an ongoing one, or disclosure is otherwise in the public interest, the CSIRT may, after consulting the manufacturer, inform the public or require the manufacturer to do so.

Notifying a severe incident under the CRA

The short version