CRA Operations

Severe incidents

Is a service outage a severe security incident under the CRA?

The CRA threshold concerns the product’s security effects, including its ability to protect important data or functions and the introduction of malicious code. An outage label alone is insufficient.

Prepared by CRA Operations · Updated 2026-09-13 · Hypothetical worked examples

The situation

A connected product experiences an interruption. One investigation documents no qualifying security effect or malicious-code capability. Another establishes that the event could negatively affect the product’s protection of important functions. Record the relevant capability as well as observed harm.

Facts that change the answer

  • Did the event affect or have the capability to affect protection of important data or functions?
  • Did it introduce or enable the introduction of malicious code?
  • Who established the facts and when did the manufacturer become aware?

Compare the worked results

These examples use the published assessment with the assumptions shown below. Change the facts in your own assessment before relying on its result.

No qualifying security effect identified

Hypothetical example 1

Assessment resultsevere incident threshold not met
Key facts in this example
Timestamp when the organisation became aware of the incident
2026-09-11T09:00:00Z
Effect on the product’s ability to protect sensitive or important data or functions
no negative effect or capability identified
The early warning records whether unlawful or malicious acts are suspected
Yes
The early warning identifies relevant Member States where the product is known to have been made available
Yes
Actual timestamp when the incident notification was submitted
2026-09-12T10:00:00Z
The notification records available product information and the nature and initial assessment of the incident
Yes
Corrective or mitigating measures taken and measures users can take are recorded
Yes
The notification records how sensitive the submitted information is, where applicable
Yes
Final-report status within one month after the incident notification
submitted within one month
The final report gives a detailed incident description, including severity and impact
Yes
The likely threat type or root cause that triggered the incident is recorded
Yes
Applied and ongoing mitigation measures are recorded
Yes
Submission through the coordinating CSIRT endpoint, with simultaneous ENISA access, is confirmed
Yes
All recorded assumptions (16)
Affected product with digital elements
Hypothetical example product
Reporting role
manufacturer
Timestamp when the organisation became aware of the incident
2026-09-11T09:00:00Z
Effect on the product’s ability to protect sensitive or important data or functions
no negative effect or capability identified
Introduction or execution of malicious code caused or enabled by the incident
no malicious code effect or capability identified
The early warning records whether unlawful or malicious acts are suspected
Yes
The early warning identifies relevant Member States where the product is known to have been made available
Yes
Actual timestamp when the incident notification was submitted
2026-09-12T10:00:00Z
The notification records available product information and the nature and initial assessment of the incident
Yes
Corrective or mitigating measures taken and measures users can take are recorded
Yes
The notification records how sensitive the submitted information is, where applicable
Yes
Final-report status within one month after the incident notification
submitted within one month
The final report gives a detailed incident description, including severity and impact
Yes
The likely threat type or root cause that triggered the incident is recorded
Yes
Applied and ongoing mitigation measures are recorded
Yes
Submission through the coordinating CSIRT endpoint, with simultaneous ENISA access, is confirmed
Yes

Qualifying security effect; notifications in progress

Hypothetical example 2

Assessment resultnotification sequence in progress
Key facts in this example
Timestamp when the organisation became aware of the incident
2026-09-13T09:00:00Z
Effect on the product’s ability to protect sensitive or important data or functions
negatively affected or capable of negative effect
24-hour early-warning status
deadline not yet reached
72-hour incident-notification status
deadline not yet reached
Impacted users were informed without undue delay, including necessary risk-mitigation or corrective measures
Yes
All recorded assumptions (8)
Affected product with digital elements
Hypothetical example product
Reporting role
manufacturer
Timestamp when the organisation became aware of the incident
2026-09-13T09:00:00Z
Effect on the product’s ability to protect sensitive or important data or functions
negatively affected or capable of negative effect
Introduction or execution of malicious code caused or enabled by the incident
no malicious code effect or capability identified
24-hour early-warning status
deadline not yet reached
72-hour incident-notification status
deadline not yet reached
Impacted users were informed without undue delay, including necessary risk-mitigation or corrective measures
Yes

Evaluated on 2026-09-13 using EU Cyber Resilience Act severe security incident notification record, version 2026.09.04. A completed example is not a customer Record or a declaration of conformity.

Evidence to keep

  • Incident timeline and security-impact assessment
  • Malicious-code findings and supporting investigation
  • Awareness timestamp and reporting-role record

Keep source artifacts in their controlled systems and record their references, responsible owner and review date with the decision.

Your next step

Assess the Article 14(5) threshold and document uncertainty. When reporting applies, prepare the notifications without waiting for a complete root-cause investigation.

Start this assessmentSign in to your workspace

Choose your real product or vulnerability case in the workspace. The selected assessment will be highlighted; example answers are not copied into your record.

Sources and application dates

Manufacturer reporting applies from 11 September 2026. Broader product requirements apply from 11 December 2027; these product-readiness examples support preparation. Open-source-steward obligations have their own application date.

These examples structure a decision and do not replace the Regulation, official guidance or product-specific professional advice. Not lawyer-reviewed.

Related situations

What should the CRA severe-incident final report establish?

The final report needs the incident’s severity and impact, threat type or likely root cause, and mitigation details. Its one-month limit runs from the actual incident notification.

Does a CVE alone trigger CRA vulnerability reporting?

A CVE identifies a vulnerability; it does not alone establish active exploitation. Preserve evidence of whether a malicious actor is exploiting the weakness without the owner’s permission.

When does the CRA vulnerability final-report clock start?

The vulnerability final report is tied to availability of a corrective or mitigating measure. It should not be calculated as a fixed interval from the initial awareness timestamp.

What can be missing from a CRA vulnerability final report?

Submission status and content completeness must be checked separately. A receipt cannot establish that severity, impact, exploitation information and measure details were included.