A severe incident under the Cyber Resilience Act (CRA) is not simply any outage, security alert, compromise, or high-severity internal ticket. For Article 14 reporting, the incident must affect the security of a product with digital elements and meet at least one of two statutory severity tests. Manufacturers therefore need a fast, evidence-based decision process that separates ordinary product-security incidents from incidents that trigger mandatory CRA reporting.
Article 14 reporting obligations apply from 11 September 2026. From that date, manufacturers that become aware of a severe incident having an impact on the security of a product with digital elements must report it through the CRA Single Reporting Platform.
Start with the CRA definition of a product-security incident
The CRA defines an “incident having an impact on the security of the product with digital elements” as an incident that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions.
That definition is the first gate. An operational problem that has no product-security impact is not automatically within this category merely because it is serious for the business. Conversely, an event does not need to have caused the maximum possible damage before it can fall within the definition: the Regulation also covers an incident that is capable of negatively affecting those security properties.
For practical triage, ask first:
- Which exact product, variant or release is affected?
- What data or functions does that product protect?
- Has availability, authenticity, integrity or confidentiality been affected, or could it be affected by the incident?
- What evidence supports that assessment?
Only after establishing that product-security connection should the team apply the severe-incident test in Article 14(5).
The two Article 14 severity tests
Article 14(5) provides two alternative conditions. Meeting either one is sufficient for the incident to be considered severe for the reporting obligation.
Test 1: sensitive or important data or functions
An incident is severe where it 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.
This test is broader than confirmed data loss. A manufacturer should assess the security property involved and the importance or sensitivity of the affected data or function. Relevant questions include:
- Can users still rely on an important function being available when required?
- Can the product still establish that data, commands, identities or software are authentic?
- Can data, configuration, software or critical state be altered without authorisation?
- Can sensitive or important information be accessed or disclosed to an unauthorised party?
- Is the incident capable of producing one of those effects even if investigation is still determining the full impact?
The legal test is product-specific. A temporary interruption of a peripheral convenience feature and loss of availability of a safety- or security-relevant function are not equivalent merely because both can be described as “downtime”. Teams need to document why the affected data or function is, or is not, sensitive or important in the context of the product.
Test 2: malicious code in the product or user systems
An incident is also severe where it has led, or is capable of leading, to the introduction or execution of malicious code in either:
- the product with digital elements itself; or
- the network and information systems of a user of that product.
This is a separate route to the severe-incident threshold. It means teams should not limit incident classification to confidentiality, integrity or availability impact already observed in the product. If the incident creates a credible path for malicious code to be introduced or executed in the product or in connected user systems, Article 14(5)(b) becomes directly relevant.
Examples that merit immediate assessment include a compromised update path, malicious package or component delivery, unauthorised code execution through a product interface, or a compromise that can propagate from the product into a user's network. These examples are engineering prompts, not automatic legal conclusions: the manufacturer still needs to establish the actual product context and whether the statutory condition is met.
“Capable of” matters during early triage
Both severity tests include prospective language. The CRA does not require manufacturers to wait for complete forensic confirmation of every consequence before considering whether an incident is severe.
That matters because the first reporting deadline is short. The early warning is due without undue delay and in any event within 24 hours of the manufacturer becoming aware of the severe incident. A team that waits for a final root-cause analysis before opening the regulatory decision path may lose the time needed to meet the reporting timetable.
A more robust process separates three questions:
- What do we know? Confirmed facts, affected products, observed indicators, known user impact and available telemetry.
- What is reasonably possible? Credible impact supported by technical evidence, architecture, exploit path or incident behaviour.
- What remains unknown? Investigation gaps that need to be resolved and explicitly tracked.
This allows the manufacturer to make a defensible severity decision with the information available at the time and then update that assessment as new evidence arrives.
The reporting sequence after the threshold is met
Once a manufacturer becomes aware of a severe incident meeting the Article 14 threshold, the CRA sets a staged reporting process.
Within 24 hours: early warning
The manufacturer must submit an early warning without undue delay and in any event within 24 hours of becoming aware of the severe incident. At minimum, it must indicate whether the incident is suspected of being caused by unlawful or malicious acts. Where applicable, it must also identify the Member States where the manufacturer is aware that the affected product has been made available.
Within 72 hours: incident notification
Unless the relevant information has already been provided, the manufacturer must submit an incident notification without undue delay and in any event within 72 hours of becoming aware. Where available, this includes:
- general information about the nature of the incident;
- an initial assessment;
- corrective or mitigating measures already taken;
- corrective or mitigating measures users can take; and
- where applicable, an indication of how sensitive the manufacturer considers the notified information to be.
The 72-hour submission is therefore not expected to be a finished post-incident report. It is an initial assessment supported by the best information available at that stage.
Within one month after the 72-hour notification: final report
For a severe incident, the final report is due within one month after the incident notification. It must include at least:
- a detailed description of the incident, including severity and impact;
- the type of threat or likely root cause; and
- mitigation measures that have been applied and those still ongoing.
The CSIRT designated as coordinator may also request an intermediate report where relevant status updates are needed.
Report through the Single Reporting Platform
The CRA Single Reporting Platform (SRP), established under Article 16 and operated by ENISA, is the reporting channel for these notifications. ENISA states that the platform is scheduled to be operational by 11 September 2026, when the Article 14 reporting obligations begin to apply.
Manufacturers submit the notification once through the platform. It is addressed to the CSIRT designated as coordinator and, subject to the exceptional dissemination provisions in the CRA, the information is made available to ENISA and routed through the relevant cooperation framework.
A practical preparation step before September is to define who in the organisation owns SRP access, who can approve the regulatory classification, and who is responsible for submitting each stage of the report. The short statutory deadlines make unclear ownership a material operational risk.
Severe incident is not the same as an actively exploited vulnerability
Article 14 contains separate reporting triggers for actively exploited vulnerabilities and severe incidents. They can be related, but they are not interchangeable.
An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. A severe incident, by contrast, is classified using the two incident-impact tests in Article 14(5).
A single event can potentially involve both concepts. For example, exploitation of a vulnerability may result in an incident that also meets the severe-incident threshold. Incident responders should therefore evaluate both reporting paths instead of assuming that one classification excludes the other.
Inform impacted users as part of the response
Article 14 also requires manufacturers, after becoming aware of an actively exploited vulnerability or severe incident, to inform impacted users and, where appropriate, all users. Where necessary, that communication must include risk-mitigation and corrective measures users can deploy to reduce the impact.
This means the regulatory workflow should not end at the SRP submission. The response plan should connect authority reporting, technical mitigation, product communications and user guidance while keeping the facts consistent across each channel.
Useful retained evidence includes the affected product and release scope, the incident timeline, the severity assessment, reasons for the Article 14 decision, indicators and forensic evidence, mitigations, user instructions, notification timestamps and copies of the submitted information.
Build the decision record around the awareness time
The reporting clock is tied to when the manufacturer becomes aware of the severe incident. Teams should therefore record the evidence behind that awareness point rather than reconstruct it later.
A practical incident record should capture:
| Decision field | Evidence to retain | | --- | --- | | Awareness time | Alert, escalation, case record and timestamp | | Product scope | Product, variant, release and affected components | | Security impact | Availability, authenticity, integrity or confidentiality analysis | | Importance or sensitivity | Why affected data or functions are considered sensitive or important | | Malicious-code path | Evidence of introduction, execution or credible capability | | Severity decision | Article 14(5)(a), 14(5)(b), both, or documented reason neither applies | | 24-hour submission | Time, submitter, content snapshot and acknowledgement | | 72-hour submission | Initial assessment, mitigation status and user actions | | Final report | Severity, impact, likely cause and ongoing mitigation | | User communication | Audience, timing, instructions and published message |
This record is useful even when the decision is that an incident is not severe. A documented negative decision shows what facts were considered and why the team concluded that neither statutory test was met at that point in time.
Avoid simplistic severity scoring
Internal severity labels such as “P1”, “critical”, “SEV-1” or a CVSS score can help incident operations, but they do not replace the CRA legal test. The CRA asks specific questions about the security of the product, sensitive or important data or functions, and malicious-code introduction or execution.
A practical triage workflow can use internal severity as a signal to escalate quickly, while keeping the CRA classification as a separate documented decision. This prevents an organisation from assuming that every internal critical incident is automatically reportable or, conversely, that a lower-scored event cannot meet Article 14(5).
A practical severe-incident decision flow
For each product-security incident:
- Confirm product-security relevance. Identify whether the event negatively affects, or can negatively affect, the product's ability to protect data or functions.
- Apply Article 14(5)(a). Determine whether sensitive or important data or functions are affected or could be affected across availability, authenticity, integrity or confidentiality.
- Apply Article 14(5)(b). Determine whether malicious code has been, or could be, introduced or executed in the product or user systems.
- Record awareness time. Capture the timestamp and evidence that established awareness of the severe incident.
- Escalate immediately if either test is met. Start the 24-hour reporting workflow while investigation continues.
- Prepare the 72-hour assessment. Keep product scope, technical findings, mitigation and user actions current.
- Complete the final report. Consolidate severity, impact, likely cause and mitigation within the required timetable.
- Retain the decision trail. Preserve the evidence supporting both the incident response and the regulatory classification.
The most important operational principle is to make the reporting decision traceable. The CRA threshold is specific enough to be mapped into a repeatable decision record, but it still requires product and incident judgement from the manufacturer.
Keeping that judgement connected to the right product, release, evidence and notification history becomes difficult when incident facts are spread across tickets, security tools and documents. AA-sec is designed around traceability between requirements, security evidence, vulnerability work, decisions and exact product or lifecycle context; its roadmap includes CRA reporting and post-market workflows. AA-sec does not determine CRA conformity or make the manufacturer's Article 14 reporting decision.
Key takeaway
A CRA severe incident is not defined by an internal severity label alone. For Article 14, the manufacturer must first establish an incident affecting product security and then apply two alternative tests: impact or potential impact on sensitive or important data or functions, or introduction or potential execution of malicious code in the product or user systems.
From 11 September 2026, once a manufacturer becomes aware of a severe incident meeting that threshold, the reporting process begins: early warning within 24 hours, incident notification within 72 hours, and a final report within one month after the 72-hour notification. The practical preparation task is therefore to make severity classification, awareness time, ownership, evidence and notification steps part of the incident-response process before the deadline arrives.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Reporting obligations — European Commission
- Single Reporting Platform (SRP) — ENISA
- Commission guidance on the application of the Cyber Resilience Act — European Commission