When a Security Incident Becomes Severe

The CRA’s incident track asks a different question from its actively exploited vulnerability track. This chapter examines when an incident affecting a product’s security becomes severe, why potential harm can be enough to trigger reporting, and how the incident deadlines differ from the vulnerability deadlines. The practical judgment is to separate symptoms, impact, cause, and remediation so that one event is not either minimized as a technical defect or flattened into an uninformative severity label.

From a product-security symptom to severe impact

The Cyber Resilience Act treats an incident as a security problem in relation to what the product protects. An incident has an impact on the security of a product with digital elements when it negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity, or confidentiality of data or functions. These four properties provide a better starting point than asking whether the incident was public, expensive, or embarrassing.

Availability concerns whether the product and the functions it supports can remain usable when needed. Authenticity concerns whether data, commands, or other functions can be trusted as genuine. Integrity concerns whether stored, transmitted, or processed information and operations remain unaltered by unauthorized action. Confidentiality concerns whether information remains protected from unauthorized access. A security incident may affect one of these properties without producing the others. A controller that continues operating but accepts altered commands has a different failure pattern from one that becomes unreachable, even though both can be product-security incidents.

The CRA adds a severity test. An incident having an impact on product security is severe when it negatively affects, or is capable of negatively affecting, the product’s ability to protect sensitive or important data or functions. It is also severe 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.

The two branches should be tested separately. The first asks what data or functions are at stake and whether the incident affects or threatens their protection. The second asks whether the incident creates a path for malicious code to enter or run. The second branch does not require the manufacturer to wait until every downstream system has been proven infected. The statutory wording includes capability because early action can prevent a possible route to wider harm.

That does not make every alarming event severe. “Capable of” still needs a factual connection. A manufacturer should be able to explain what product function is affected, which data or functions are sensitive or important, how malicious code could be introduced or executed, or why the available evidence supports the potential-impact conclusion. An internal label such as “critical incident” may help coordinate staff, but it is not a substitute for those predicates.

Consider a manufacturer of a network-connected building controller. The company detects that an attacker has changed a configuration through an unauthorized path. The controller remains online, but its ability to protect the integrity and authenticity of commands is in doubt. If the incident can also lead to malicious code executing on the controller or reaching a user’s network, the severe-incident analysis becomes stronger. The important point is not whether the incident has already shut down a building. The point is whether the product’s security functions are negatively affected or placed in a credible path toward serious consequences.

The analysis must also distinguish cause from impact. A likely root cause may be a software weakness, compromised credential, malicious update, or another condition, but the severe-incident threshold is not simply a list of causes.