Vulnerability or incident — which path applies?

What matters is not whether a vulnerability could be exploited, but whether it is being exploited. The regulation looks at whether an actor is actually using the flaw without the permission of the system operator or owner.

Reliable evidence includes traces of attack in log files, a publicly available working exploit combined with matching anomalies, or a report from an affected customer. Theoretical exploitability without evidence of actual use does not trigger Article 14.

On this path the final report requires details that do not exist for an incident: severity and impact, details of the security update provided, and whether the vulnerability has been publicly disclosed and a CVE ID assigned.

This concerns an event with a negative impact on availability, authenticity, integrity or confidentiality — relating to the security of the product with digital elements. Whether a vulnerability was the cause is initially secondary.

Already in the early warning on this path you must state whether, to the manufacturer's knowledge, unlawful or malicious acts are involved. Anyone unable to judge that yet says so and supplies the assessment later — staying silent is not an option.

The final report requires a detailed incident description, the type of threat or likely root cause, and ongoing and completed mitigation measures.

An actively exploited vulnerability often produces an incident at the same time. Then both are met, and because the final report deadlines differ it makes sense to run two separate cases rather than bend one.

If the classification stays open, the clock runs regardless. In that situation the early warning should be submitted on time and the assessment refined in an intermediate report. A notification that later turns out not to have been required has no consequences; an omitted one does.