Cyber Resilience Act Response Center Request a demoDemo

Guide Last updated 13 min read

Severe incident under the CRA: where the line is drawn, with examples

The second trigger of the reporting obligation usually hits not the product at the customer's site but the manufacturer itself: update servers, signing keys, the development environment. This page explains when an incident is severe and draws the line with examples.

Under Article 14(5) of Regulation (EU) 2024/2847, a severe incident is an incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect sensitive or important data or functions. An incident is also severe if 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. Under Article 14(3), the manufacturer must report such incidents once it becomes aware of them. Unlike an actively exploited vulnerability, an incident is an event, not a state: something has happened, typically in the manufacturer's infrastructure, that puts the security of the product at the user's end at risk.

Key points

  • Incidents must be reported if they have an impact on the security of the product and are severe (Article 14(3) and (5)). Not every IT disruption at the manufacturer qualifies.
  • Severe means: sensitive or important data or functions of the product are at risk, or malicious code can reach the product or the user.
  • Recital 68 gives the example of malicious code in the release channel for security updates.
  • Deadlines: early warning notification within 24 hours, incident notification within 72 hours, final report within one month of the 72-hour notification (Article 14(4)).
  • A NIS2 notification for your own organisation and a GDPR notification run in parallel and do not replace the CRA notification.

What do Article 14(3) and (5) say?

The Regulation builds the concept in three steps. Under Article 3, point (43), an incident is what Article 6, point (6) of the NIS2 Directive (the EU directive on network and information security) defines as such. Under Article 3, point (44), an incident having an impact on the security of the product with digital elements is an incident that negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of data or functions. The word severe does not appear in Article 3 but in Article 14(5). Under that provision, an incident is severe where

  • Point (a): 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
  • Point (b): it has led or is capable of leading to the introduction or execution of malicious code in a product with digital elements or in the network and information systems of a user of the product.

Two things stand out. First, the possibility is enough: "is capable of negatively affecting", "is capable of leading". The damage does not have to have occurred. Second, what matters is the security of the product, not that of the manufacturer as an organisation. An incident in the manufacturer's accounting department is not covered by Article 14 as long as it does not affect the product.

Recital 68 illustrates this: a severe incident is one that affects the manufacturer's development, production or maintenance processes in such a way that the risk to users increases, for example malicious code in the release channel for security updates. The same recital gives the example for the actively exploited vulnerability: a security breach affecting users that results from a weakness in the product's identification or authentication functions. Both examples show where the Regulation is looking: at protective functions and at the route by which code reaches the user.

How does an incident differ from a vulnerability?

An actively exploited vulnerability is a state of the product: there is a flaw in the product, and someone is exploiting it in a customer's system. A severe incident is an event: something has happened, usually at the manufacturer, and as a result the security of the product is at risk. In practice, incidents occur in build pipelines (the systems that turn source code into deliverable software), on update servers, with signing keys, in support access or in backends that are part of the product as remote data processing.

FeatureActively exploited vulnerabilitySevere incident
Legal basisArticle 14(1), Article 3, point (42)Article 14(3) and (5), Article 3, point (44)
What it isA state: a flaw in the product that is being exploitedAn event that puts the security of the product at risk
Where it typically happensIn users' systemsIn the manufacturer's infrastructure or in the product itself
ThresholdReliable evidence of exploitation by a malicious actorSensitive data or functions at risk, or malicious code possible
Early warning24 hours from becoming aware (paragraph 2, point (a))24 hours from becoming aware, stating whether the incident is suspected of being caused by unlawful or malicious acts (paragraph 4, point (a))
Final reportNo later than 14 days after a corrective or mitigating measure is availableWithin one month of the 72-hour notification

Both triggers can coincide, for example when an update server is attacked through a vulnerability in software that is also part of the product at the customer's site. In that case, both triggers have to be examined.

Which deadlines apply to an incident?

Article 14(4) sets out the same three stages as for a vulnerability. All deadlines run from the moment the manufacturer becomes aware, not from the event. According to the Commission guidance (C(2026) 5252, paragraph 213), the manufacturer becomes aware when, after an immediate initial assessment, it has a reasonable degree of certainty that a severe incident has occurred and has compromised the security of its product.

  1. Early warning, 24 hoursThat a severe incident has occurred, and whether it is suspected of being caused by unlawful or malicious acts (Article 14(4), point (a)). The platform also asks for the date and time of detection.
  2. Incident notification, 72 hoursGeneral information about the incident, the date and time it occurred, and an initial assessment. Under Article 14(6), the CSIRT may also request an intermediate report.
  3. Final report, one monthWithin one month of the 72-hour notification: applied and ongoing mitigation measures, severity, impact, and the type of threat or root cause. Unlike with a vulnerability, this deadline does not depend on whether a corrective measure is available.

The route is the same as for a vulnerability: ENISA's single reporting platform, and from there to the CSIRT designated as coordinator, which in Germany is CERT-Bund at the BSI. The guide ENISA Single Reporting Platform: registration and notification explains this step by step.

Examples: what is severe and what is not?

The following cases are fictitious. They show how the assessment under Article 14(5) works. The "CRA" column says whether the incident must be reported under Article 14; the last column shows which other obligations may apply as well.

CaseCRAReasonAlso
A manufacturer of controllers discovers malicious code on the server used to deliver signed firmware updates to customers.YesMalicious code can reach users through the update channel (paragraph 5, point (b)); this is the example from recital 68.NIS2, if the manufacturer is an in-scope entity.
An attacker encrypts a machine builder's accounting and e-mail systems. Development, update servers and remote maintenance are not affected.NoThe incident does not affect the security of the product (Article 3, point (44)). The reasoning is documented.NIS2 and GDPR, depending on what is affected.
An attacker gains access to a plant manufacturer's remote maintenance portal, through which technicians access customer installations.YesThe access allows interference with the functions and data of the products at the user's site and can lead to malicious code in the user's network (points (a) and (b)).NIS2, GDPR, informing customers under Article 14(8).
Employees of a software manufacturer receive a targeted phishing e-mail. Nobody clicks, nothing is compromised.NoA near miss (Article 3, point (45)), not an incident that has occurred. Voluntary reporting under Article 15(2) is possible.No obligation.
The cloud backend without which a connected measuring device cannot work is compromised; customers' measurement data was visible to third parties.YesAs remote data processing, the backend is part of the product; the confidentiality of data is affected (point (a)).GDPR for personal data, NIS2 depending on the entity.

The guide SaaS, cloud and remote data processing explains whether a backend is part of the product. If the manufacturer operates the backend itself and is also a NIS2 entity, the same incident may also have to be reported under NIS2, in that case as an incident in its own organisation. It then reports it twice, as the next section shows.

How does the NIS2 notification for your own organisation fit in?

Many manufacturers are also important or essential entities under NIS2, which Germany has transposed in the BSI Act (BSIG). Two reporting obligations then meet, and they ask different questions:

  • NIS2 asks about the entity: has the incident caused, or is it capable of causing, severe operational disruption of the services or financial loss for the entity, or has it affected other persons by causing considerable material or non-material damage (section 2, point 11 BSIG)? The notification goes to the BSI under Article 23 NIS2 or section 32 BSIG, with the stages 24 hours, 72 hours and one month.
  • The CRA asks about the product: is the security of the product at the user's end at risk? The notification goes via the single reporting platform to CERT-Bund and ENISA under Article 14(3).

In Germany, both notifications end up at the BSI, but by different routes and on different forms. In its FAQ on the CRA platform, the BSI says: if an incident must be reported under both sets of rules, it is reported twice, via the BSI portal (NIS2, section 32 BSIG) and via the CRA platform; each notification can include a reference to the other. Whether both obligations apply at all depends on different thresholds: severe for the product (Article 14(5)) and significant for the entity's services (section 2, point 11 BSIG). Recital 72 expressly mentions NIS2, the GDPR and DORA as complementary obligations. If personal data is affected, Article 33 GDPR adds a 72-hour notification to the data protection supervisory authority. On the plus side, the Commission guidance has aligned the concept of awareness with NIS2 and the GDPR (paragraph 212), so the timestamp only has to be determined once. The guide CRA and NIS2 compared sets the two regimes side by side.

When and how must users be informed?

Article 14(8) requires the manufacturer, after becoming aware of a severe incident, to inform the impacted users and, where appropriate, all users, including about any risk mitigation measures they can take. The paragraph sets no deadline in hours; the information must be provided in a timely manner, otherwise the CSIRTs designated as coordinators may inform users themselves. With an incident, this is often more urgent than with a vulnerability: a manufacturer that may have shipped malicious code through the update channel must tell customers which updates they should not install, or should remove. The guide Informing users under Article 14(8) explains what such information should contain.

What this means in practice

The severe incident is the case where the manufacturer's IT security and product security meet. Three preparations help. First, the list of systems that underpin product security must be in place beforehand: build servers, update servers, signing keys, support access, backends. If one of them is attacked, the assessment under Article 14(5) is due immediately. Second, the people who are alerted to any IT incident anyway (head of IT, management, data protection) must have the question "Is a product affected?" on their checklist. Otherwise the NIS2 notification goes out and the CRA notification is forgotten. Third, every timestamp belongs in the record, because in its current release the platform only asks for the time of detection, and according to the ENISA FAQ of 3 October 2026 its 72-hour counter runs from the early warning rather than from awareness. In these cases, CRA Response Center alerts the people responsible and, once awareness has been confirmed, shows the deadlines for both triggers, with the history as evidence; assessment and submission remain with the manufacturer.

Free templatesCRA Reporting KitReporting playbook, awareness record, notification templates for the ENISA platform, call chain and deadline calculator. Six Word templates, two Excel workbooks and a handbook, free by e-mail.Request the kit

Frequently asked questions

Is every cyber attack on our company a severe incident under the CRA?

No. Article 14(3) only covers incidents that have an impact on the security of the product, and paragraph 5 additionally requires that sensitive data or functions are at risk or that malicious code can reach the product or the user. An attack on administrative systems with no connection to the product is not covered, but may have to be reported under NIS2 or the GDPR.

When does the 24-hour deadline start for an incident?

From awareness, meaning when the manufacturer, after an immediate initial assessment, has a reasonable degree of certainty that a severe incident has occurred and has compromised the security of the product (guidance, paragraph 213). Not from the attack itself, and not from the completion of the root cause analysis.

What must the early warning for an incident contain?

That a severe incident has occurred, and whether it is suspected of being caused by unlawful or malicious acts (Article 14(4), point (a)). The platform also asks for the date and time of detection.

We have reported to the BSI under NIS2. Does that take care of the CRA notification?

No. The two obligations run in parallel, with their own forms and routes. Recital 72 mentions NIS2 as a complementary reporting obligation, and in its FAQ on the CRA platform the BSI makes clear that an incident falling under both sets of rules must be reported under both; each notification can include a reference to the other.

Does an attack that was fended off count?

An attack without compromise is a near miss under Article 3, point (45). It does not have to be reported under Article 14, but can be reported voluntarily under Article 15(2), without giving rise to any obligations (paragraph 5).

Further reading

Sources

The reporting obligation already applies. Who answers at night at your company?

CRA Response Center monitors your security mailbox, recognises important reports using AI hosted in Germany (your e-mails never go to OpenAI, Anthropic or Google) and alerts your people by SMS and e-mail. EUR 190 per month including VAT. Try it free for 30 days.

Try it free for 30 days