Is every outage an incident?

Only if one of the four protected properties is affected. An outage compromises availability and is therefore covered, regardless of whether an attack caused it. A hardware failure or a botched update rollout can be an incident. Whether it is also reportable depends on the additional threshold.

Do we have to report every incident?

No. Only severe incidents having an impact on the security of the product with digital elements are reportable. An incident in your office IT with no connection to the product triggers no CRA duty. Other rules may still apply, the GDPR or NIS2 for instance.

The CRA defines that too: an event that could have caused an incident but was successfully prevented or did not materialise. Near misses are not reportable. They remain valuable for your own risk assessment, because they show where safeguards only just held.

Cyber Resilience Act

Incident

Legal definition Art. 3(43) CRA

“an incident as defined in Article 6, point (6), of Directive (EU) 2022/2555”

Regulation (EU) 2024/2847, Art. 3(43) CRA

The Cyber Resilience Act (CRA) does not define an incident itself; it refers to the NIS2 Directive. There it is: an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data, or of the services offered by or accessible via network and information systems.

The cross-reference is deliberate: it keeps the two instruments aligned. If you already run NIS2 processes, you are working from the same definition.

Four properties, one incident

What matters is that the definition needs no attacker. Compromised is compromised. Whether the cause was an attack, a misconfiguration or a hardware failure makes no difference to the classification.

This surprises many who equate “incident” with “attack”. A failed update that bricks a device compromises availability, and is therefore an incident in the terms of the definition.

The reporting threshold sits higher

The definition alone creates no reporting obligation. The CRA ties reporting to a narrower notion: a severe incident having an impact on the security of the product with digital elements. Two filters therefore apply, severity and product relevance.

Two common cases drop out: the minor incident without consequences, and the incident in your own corporate IT that does not touch the product you ship. Both need handling, but not a report under Article 14.

Relation to actively exploited vulnerabilities

The CRA’s two reporting triggers overlap but do not replace one another:

An Actively exploited vulnerability describes a property of the product that has demonstrably been exploited.
An incident describes an event affecting data or services.

A successful attack through a vulnerability is both at once. Both reporting routes then apply. The final reports carry different deadlines: 14 days after a fix becomes available for the vulnerability, one month after the 72-hour notification for the incident.

What this means in practice

Because the classification decides deadlines, it belongs settled in advance rather than deferred to the moment of crisis. A short written decision aid helps: does it concern a product we shipped, is one of the four properties compromised, is the incident severe, and who decides that outside office hours?

Answering those four questions in advance costs an hour. Answering them under pressure costs a substantial share of the 24 available.

Practical questions

: Only if one of the four protected properties is affected. An outage compromises availability and is therefore covered, regardless of whether an attack caused it. A hardware failure or a botched update rollout can be an incident. Whether it is also reportable depends on the additional threshold.
: No. Only severe incidents having an impact on the security of the product with digital elements are reportable. An incident in your office IT with no connection to the product triggers no CRA duty. Other rules may still apply, the GDPR or NIS2 for instance.
: The CRA defines that too: an event that could have caused an incident but was successfully prevented or did not materialise. Near misses are not reportable. They remain valuable for your own risk assessment, because they show where safeguards only just held.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.