You blocked a cyberattack on your connected product. Now decide whether to report it

At 9:12, the monitoring system detects an attempt to gain unauthorised access to the software controlling a connected machine. The security controls block the traffic. The machine keeps running, no data appears to have been altered and no foreign code has executed. For the technical team, the attack was repelled. For the person applying the Cyber Resilience Act, the work starts here.

The question is not only whether the event was dangerous. You must establish whether an incident has already occurred, whether the event remains a near miss and, if it was an incident, whether it was severe enough to require reporting. That classification determines whether the 24-hour early-warning period starts.

Since 11 September 2026, Article 14 of Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements — the Cyber Resilience Act, or CRA — has applied to products within its scope, including products placed on the market before the Regulation applies in full. A manufacturer cannot defer this decision until 2027.

The clock does not start with the first alert

A technical alert does not automatically amount to awareness of a severe incident. It may indicate anomalous behaviour, a blocked attempt or a compromise that has not yet been confirmed. The draft guidance annexed to European Commission Communication C(2026) 5252 of 27 July 2026 calls for an immediate initial assessment. The relevant moment arrives when, after that assessment, there is a reasonable degree of certainty that a severe incident has occurred and has led to the security of the product being compromised.

This avoids two opposite errors. The first is reporting every signal produced by security tools as a severe incident. The second is waiting for the attack to be fully reconstructed before starting the clock. The CRA provides for progressive reporting precisely because information may still be incomplete in the first hours: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month after the 72-hour notification.

The initial assessment must therefore be quick, but it cannot stop at the words "attack blocked". You need to reconstruct how far the event went and what it actually touched.

Compromise comes before severity

The CRA does not construct the distinction between an incident and a near miss by itself. Article 3 refers to the definitions in Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union — the NIS2 Directive.

Under NIS2, an incident 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. A near miss is an event that could have compromised them, but was successfully prevented from materialising or did not materialise.

The first question, therefore, is not yet about severity. It is about what happened. Was the security of a system actually compromised, or did the controls stop the attempt before that point?

If the attempt could have compromised the security of the software but was blocked before any compromise, the definition points towards a near miss. Reporting under Article 15 of the CRA is voluntary. If the attacker obtained access to an account, changed a configuration or extracted a credential, the compromise has already occurred. Containment limits the consequences, but it does not retrospectively turn the incident into a near miss.

Only then do you assess severity under Article 14.

Possible future harm does not make every alert reportable

The difficulty lies in the CRA's wording. An incident can be severe not only when it already negatively affects a product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, but also when it is capable of having that effect. The same applies where an incident 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 (Article 14(5)).

This wording prevents the manufacturer from waiting for final damage. If an environment used to build product updates is compromised and the access obtained can allow malicious code to be inserted, there is no need to wait for an infected update to reach a customer. The compromise of the environment already exists; only the more serious consequence is still potential. The more prudent reading, consistent with Article 14, leads to mandatory reporting.

But "capable of" does not erase the earlier step. The provision still refers to an incident: an event that has already compromised the security of a system. If an attempt was stopped before any compromise, the mere possibility of serious consequences is not enough, on the stronger reading of the definitions, to turn it into a severe incident.

The Commission's published draft guidance does not expressly settle this boundary. Its reporting section focuses on when a manufacturer becomes aware of an incident; it does not analyse the line between an incident and a near miss. The guidance is also non-binding. This conclusion must therefore be presented for what it is: an interpretation based on reading the CRA and NIS2 definitions together, not an official threshold that has already been clarified in every detail.

There is a middle ground between a blocked attempt and a severe incident

The distinction is not exhausted by the choice between a near miss and a severe incident. A real compromise may have occurred without meeting the severity criteria in Article 14(5).

Imagine a secondary technical account is compromised and immediately disabled. It cannot be used to affect sensitive or important data or functions, or to introduce malicious code. The event is more than a near miss because the unauthorised access happened. But if the technical reconstruction rules out both CRA severity criteria, mandatory reporting is not triggered. The incident can still be reported voluntarily under Article 15.

This third possibility also matters for documentation. If the business records only "reported" or "not reported", it loses the reason for the decision. Those two outcomes may conceal very different facts: an attempt stopped completely, a limited compromise below the severity threshold, or an incident already capable of affecting an important function.

A vulnerability follows a different route

The reporting question must not be confused with managing the vulnerability that made the attempt possible. A vulnerability, even an exploitable one, is not an incident in itself. The CRA deals separately with actively exploited vulnerabilities, incidents and vulnerability-handling duties.

This means that "not reportable as a severe incident" does not mean "irrelevant" or "no remediation needed". The product may need to be changed, customers may need to be informed, or contractual and other legal duties may apply even when the Article 14 threshold is not met. At the same time, a note published today cannot present all CRA vulnerability-handling duties as generally applicable already: Article 14 has applied since 11 September 2026, while Article 13 and Annex I apply generally from 11 December 2027.

The distinction matters particularly for products placed on the market before that date. As the Commission explains, a manufacturer may already have to report a severe incident even where the CRA vulnerability-handling duties do not yet apply to that product.

The decision must be reconstructible

The first hours do not call for a final dossier. They call for a record that shows what the business knew and when it knew it. The record should identify the product and system involved, describe the compromise actually established and separate it from effects that remained merely possible. It should then explain why the data or functions concerned are, or are not, sensitive or important, and what technical element makes the introduction of malicious code plausible.

The most delicate point is the moment of awareness. Keep the time of the first signal, but also the time when the initial assessment reached a reasonable degree of certainty. The reporting period may run from that second moment, and the difference must be shown by the facts, not by wording added later.

A useful company procedure does not ask the technical team only whether the attack was blocked. It asks where it was blocked. If the barrier prevented any compromise, the route points towards a near miss. If it intervened after access or alteration, the severity of the incident and the consequences it is still capable of producing must be assessed.

That is the decision the manufacturer must be able to make before the 24-hour clock becomes the main problem.