Incident affecting product security

An incident affecting product security is one of two events that trigger a notification to authorities under the Cyber Resilience Act (CRA). Article 3, point (44) sets it out under the full official name “incident having an impact on the security of the product with digital elements”. The shorter form used on this page means the same thing.

The definition builds on an earlier one. Under Article 3, point (43), an Incident is an incident as defined in the NIS2 Directive, that 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. Point (44) adds the product link: the incident must affect, or be capable of affecting, a product’s ability to protect data or functions.

The phrase “is capable of” carries weight here. No damage need have occurred. It is enough that the incident could undermine the product’s protective capability.

How this differs from a vulnerability

A vulnerability is a property of the product, whereas an incident is an event. And that event typically plays out at the manufacturer, not in the shipped device. Recital 68 says exactly this: the situations meant are those in which a cybersecurity incident affects the manufacturer’s development, production or maintenance processes in a way that could raise the cybersecurity risk for users or other persons.

The example the regulation itself gives is the compromised release channel: an attacker introduces malicious code into the route by which the manufacturer ships security updates. A hijacked build server, a stolen signing key and a taken over package registry account fit the same pattern.

The CRA’s other reporting track, the Actively exploited vulnerability, concerns a flaw in the product itself. Both tracks use the same reporting platform and the same first two deadlines of 24 and 72 hours, but they attach to entirely different facts. The final report differs too: for a vulnerability it is due no later than 14 days after a corrective or mitigating measure is available (Article 14(2)(c)), for an incident within one month of the 72-hour notification (Article 14(4)(c)).

Only a severe incident must be reported

Article 14(3) requires the manufacturer to notify every severe incident affecting product security that it becomes aware of. Article 14(5) says what severe means. Either limb suffices:

• the incident 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; or
• 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.

Two words separate this from the definition in Article 3, point (44). There the text says simply “data or functions”; Article 14(5)(a) says “sensitive or important data or functions”. That qualifier divides the reportable incident from the one that need not be reported. The CRA defines neither “sensitive” nor “important”, so the classification stays a reasoned decision by the manufacturer, and one worth documenting.

Notification in three stages

The notification goes simultaneously to the CSIRT designated as coordinator and to ENISA, submitted through the Single reporting platform. Article 14(4) breaks it into three steps:

• 24 hours after becoming aware: the early warning. It states at minimum whether unlawful or malicious acts are suspected and, where applicable, in which Member States the manufacturer is aware the product has been made available.
• 72 hours after becoming aware: the incident notification itself, covering, where available, the nature of the incident, an initial assessment, the corrective or mitigating measures taken, and what users can do themselves. This is also where the manufacturer indicates, where applicable, how sensitive it considers the reported information to be.
• One month after the 72-hour notification was submitted: the final report, containing at least a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, and the mitigation measures applied and ongoing.

In between, the CSIRT designated as coordinator that initially received the notification may request an intermediate status report under Article 14(6). The first two deadlines run from the moment the manufacturer becomes aware, not from the start of the incident. The clock for the final report, by contrast, runs from the 72-hour notification.

Telling users

Article 14(8) adds a duty to inform the impacted users and, where appropriate, all users, including any risk mitigation and corrective measures they can deploy themselves, where appropriate in a structured, machine-readable format that is easily automatically processable. This duty stands next to the notification to authorities and carries no clock in hours, only the standard of timeliness.

If the manufacturer fails to inform users in a timely manner, the notified CSIRTs designated as coordinators may inform users themselves where they consider it proportionate and necessary to prevent or mitigate the impact. Article 17(2) goes further: where public awareness is necessary, the CSIRT designated as coordinator may, after consulting the manufacturer, inform the public or require the manufacturer to do so.

More can be reported voluntarily

Article 15(2) allows any incident affecting product security to be notified voluntarily, including one that does not reach the severity threshold, as well as a Near miss that could have resulted in such an incident. Article 15(5) makes clear that a voluntary report must not create obligations that would not have applied without it. Where someone other than the manufacturer reports a severe incident this way, the CSIRT informs the manufacturer without delay.

From when, and what a breach costs

Under Article 71, Article 14 applies from 11 September 2026. The rest of the CRA applies from 11 December 2027, with Chapter IV on the notification of conformity assessment bodies applying from 11 June 2026. Reporting is therefore the first obligation in the regulation that falls on the manufacturer itself.

Breaches of Article 14 attract fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2.5 % of its total worldwide annual turnover for the preceding financial year under Article 64(2), whichever is higher. Article 64(10)(a) names manufacturers qualifying as microenterprises or small enterprises in respect of failure to meet the 24-hour deadline in Article 14(2)(a) or Article 14(4)(a). That carve-out is drafted as a derogation from paragraphs 3 to 9, however, while breaches of Article 14 are governed by paragraph 2.

Prevention is required elsewhere in any case. Annex I, Part I, point (2) requires, where applicable and on the basis of the cybersecurity risk assessment under Article 13(2), that essential and basic functions stay available even after an incident (point (2)(h)) and that the design limits an incident’s impact from the outset (point (2)(k)).