The CRA severe-incident test is broader than confirmed catastrophic damage. Article 14 also captures incidents capable of producing the specified security effects. Manufacturers therefore need a legal severity assessment alongside normal technical incident severity scoring.
Article 14 Contains a Specific Severe-Incident Test
Article 14 does not make every security event reportable as a severe incident. Paragraph 5 establishes two tests for deciding when an incident having an impact on the security of a product with digital elements is severe. The first concerns the product's ability to protect important security properties of sensitive or important data or functions. The second concerns the introduction or execution of malicious code. A manufacturer should therefore make the Article 14 determination against these statutory criteria rather than relying only on an internal severity label such as critical, high or priority one. Internal incident ratings can support escalation, but they do not replace the CRA test.
- Start with Article 14(5), not only the organisation's internal incident score.
- Assess the affected product and relevant security properties.
- Assess whether malicious code has been or could be introduced or executed.
- Record why the Article 14 severe-incident threshold is or is not met.
The First Test Covers Core Security Properties
The first Article 14(5) test applies where an incident 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. These concepts reach different failure modes. Availability concerns whether relevant information or functions remain accessible when required. Authenticity concerns whether identity, source or origin can be trusted. Integrity concerns protection against unauthorised alteration or destruction. Confidentiality concerns protection against unauthorised access or disclosure. Incident triage should examine each relevant security property rather than asking only whether the product stopped working.
- Availability can be affected even without a confidentiality breach.
- Authenticity problems can involve forged identities, sources or trusted artefacts.
- Integrity problems can involve unauthorised modification.
- Confidentiality problems can involve unauthorised access or disclosure.
- The analysis also considers sensitive or important functions.
Actual Harm Is Not Always Required
Article 14(5) repeatedly uses both actual-effect and capability language. An incident can therefore satisfy the severe-incident test where the specified negative effect has occurred, but it can also qualify where the incident is capable of producing that effect. The same structure applies to malicious code. This means a manufacturer should not automatically classify an incident as non-reportable merely because containment occurred before confirmed downstream damage. The analysis should identify what the incident enabled, what security boundary was lost, which product functions or data were exposed to risk and whether the incident had the technical capability to produce one of the outcomes described in Article 14(5).
- Assess confirmed consequences.
- Assess credible technical capability for the specified consequences.
- Do not equate successful containment with automatic non-reportability.
- Document the facts supporting the capability assessment.
The Second Test Covers Malicious Code
An incident is also considered severe where 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. This test is important because the relevant impact can extend beyond the product itself. A compromised update mechanism, installer, plugin path, privileged service, management interface or other trusted product function may create a route for malicious code into a customer's environment. Manufacturers should therefore investigate whether the product acted, or could act, as the mechanism through which malicious code entered or executed in either the product or the user's systems.
- Assess malicious code within the product.
- Assess malicious code affecting the user's network and information systems.
- Review trusted update and distribution mechanisms.
- Review privileged interfaces and execution paths.
- Preserve evidence about the product's role in the attack chain.
A Severe Incident Is Different From an Actively Exploited Vulnerability
Article 14 contains separate reporting triggers for actively exploited vulnerabilities and severe incidents. A vulnerability report concerns reliable evidence that a malicious actor has exploited a vulnerability without the system owner's permission. A severe-incident report concerns an incident meeting the Article 14(5) impact criteria. The same underlying cyberattack can raise both questions, but the legal tests remain different. For example, exploitation of a product vulnerability may create evidence of an actively exploited vulnerability, while the resulting compromise may also satisfy the severe-incident criteria. Product-security teams should classify each trigger separately instead of assuming one automatically substitutes for the other.
- Assess active exploitation separately.
- Assess severe-incident effects separately.
- One event can require analysis under both Article 14 tracks.
- Keep the evidence for each reporting determination traceable.
Manufacturer Awareness Starts the Reporting Timeline
Once a manufacturer becomes aware of a severe incident having an impact on the security of its product with digital elements, the Article 14 reporting timeline applies. The early warning must be submitted without undue delay and in any event within 24 hours of awareness. The fuller incident notification follows without undue delay and in any event within 72 hours. Organisations therefore need an escalation path that can move an event from technical investigation to regulatory assessment quickly. Waiting for a full forensic report or definitive root-cause conclusion can consume the reporting window. The first stages are designed to accept information that is still developing.
- Record the manufacturer awareness timestamp.
- Escalate potential Article 14 incidents immediately.
- Do not wait for final root-cause analysis before beginning the reporting process.
- Track the 24-hour and 72-hour deadlines from awareness.
The 24-Hour Warning Includes a Malicious-Acts Assessment
For severe incidents, the early warning must include at least whether the incident is suspected of being caused by unlawful or malicious acts. The manufacturer may not yet know the definitive cause. ENISA's current SRP field guidance recognises this by allowing the reporter to indicate whether the available evidence suggests unlawful or malicious activity and to use an unresolved status while the cause remains unknown. The objective is therefore an evidence-based preliminary assessment rather than premature attribution. Incident responders should preserve the facts supporting the assessment and update the reporting record as the investigation develops.
- Assess whether unlawful or malicious acts are suspected.
- Do not confuse suspicion with final attribution.
- Record the evidence available during the early-warning stage.
- Update the regulatory record as stronger evidence becomes available.
Use a CRA-Specific Severe-Incident Decision Record
A practical decision record should identify the affected product and versions, the incident, the relevant data and functions, the security properties affected, actual consequences, potential consequences, any malicious-code pathway, the awareness time and the reporting determination. It should also identify the owner responsible for the SRP submission and the status of mitigation and user communication. This gives the manufacturer an evidence trail showing how the Article 14(5) criteria were applied. It also reduces dependence on informal descriptions such as major incident or critical event, which may have different meanings across engineering, security, legal and customer-support teams.
- Identify affected products and versions.
- Map the Article 14(5) criteria to the known facts.
- Record actual and potential security effects.
- Record malicious-code evidence where relevant.
- Record the manufacturer awareness timestamp.
- Document the reporting conclusion and responsible owner.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.