The fastest way to misunderstand the CRA is to assume every vulnerability has to be reported to a regulator. It does not. The reporting obligation under Article 14 is deliberately narrow. The vast majority of vulnerabilities a manufacturer discovers, receives, and fixes will never cross the threshold that triggers a notification to authorities. They are handled internally under the vulnerability handling rules in Article 13.
Knowing where that threshold sits is essential. Report too little and you breach the regulation. Report everything and you flood the authorities, exhaust your own team, and lose the signal that matters. This post defines the two reportable categories, separates them from routine vulnerability handling, and gives a decision framework with worked examples.
This is the second post in our CRA reporting series. The first covered when reporting becomes mandatory. Later posts cover where reports go and the timelines that apply. For a single-page overview of the whole reporting regime, see our guide to which CRA reporting obligations apply, when they start, and how to be ready.
Two reportable categories, and everything else
Article 14 creates two distinct reporting triggers. They are related, but they are not the same thing, and conflating them is a common source of error.
Category one: actively exploited vulnerabilities
A vulnerability becomes reportable when it is being actively exploited. The test has two parts. There must be a vulnerability in your product, and there must be evidence that a malicious actor is exploiting it in the field against real systems.
The word that does the work here is "actively." A vulnerability that is theoretically exploitable, has a published proof of concept, or scores high on CVSS is not automatically reportable. It becomes reportable when exploitation is actually occurring. We have written separately on this exact distinction in exploitable versus exploited reporting obligations, because it is the single most misjudged call in the whole regime.
Category two: severe incidents affecting product security
The second trigger is a severe security incident that has an impact on the security of the product. This is broader than a vulnerability in the code. It covers events such as a compromise of the manufacturer's build pipeline, signing infrastructure, or update distribution system, where that compromise affects the security of products in the field.
A severe incident does not require a known vulnerability in the product itself. The classic example is a supply-chain compromise: an attacker gains access to your software distribution and ships a tampered update. The product may be flawless, but the incident affecting its security is severe and reportable.
Everything else: handled, not reported
Outside these two categories sits the large body of routine vulnerability work. A researcher reports a stored cross-site scripting bug in your admin console. Your own team finds a buffer overflow during a code review. A dependency scanner flags a vulnerable library version. None of these, on their own, triggers an Article 14 report. They are handled under Article 13: triaged, fixed, and disclosed through your coordinated disclosure process.
This is the proportion most people get wrong. In a healthy programme, reportable events are rare and routine handling is constant. If you find yourself reporting most of what you handle, you have misread the threshold.
The decision framework
For any vulnerability or incident, work through four questions in order.
- Is there a vulnerability in, or a security incident affecting, a product with digital elements that we placed on the EU market? If no, Article 14 does not apply. If the affected thing is an internal tool with no bearing on a marketed product, it is not in scope.
- For a vulnerability: is it being actively exploited in the field? Look for evidence of real exploitation: indicators of compromise, exploit traffic, victim reports, threat-intelligence confirmation. A high severity score or a public PoC is not, by itself, active exploitation.
- For an incident: is it severe and does it affect the security of the product? Consider impact on confidentiality, integrity, or availability for users of the product, the number of users potentially affected, and whether the incident touches infrastructure that protects the product.
- Did we become aware of this? The obligation runs from awareness. A credible report from a researcher or customer can constitute awareness even before you have fully confirmed it. Err toward treating a credible signal as the start of the clock.
If a vulnerability passes questions one, two, and four, it is reportable as an actively exploited vulnerability. If an incident passes questions one, three, and four, it is reportable as a severe incident. Everything else is routine handling.
Worked examples
Abstract criteria are hard to apply under pressure. These examples show the framework in use.
Example 1: critical CVSS, no exploitation
A researcher privately reports an unauthenticated remote code execution flaw in your network appliance. It scores 9.8. There is no evidence anyone is exploiting it. Reportable under Article 14? No. It is a serious vulnerability you must handle urgently under Article 13, fix, and coordinate disclosure for. It does not trigger the Article 14 clock unless and until you see active exploitation. If exploitation begins, the position changes immediately.
Example 2: low severity, active exploitation
Attackers are chaining a modest information-disclosure bug in your product to harvest credentials, and you have log evidence of it happening across multiple customers. The individual bug is not dramatic on a severity scale. Reportable? Yes. It is being actively exploited in the field. Active exploitation, not severity score, is the trigger.
Example 3: build-pipeline compromise
An attacker breaches your CI system and you discover a tampered build was signed and made available for download for several hours before you caught it. No specific code vulnerability is involved. Reportable? Yes, as a severe incident affecting product security. The integrity of the product as delivered to users was compromised.
Example 4: vulnerable dependency, no product impact
A scanner flags a vulnerable version of a logging library bundled in your product. The vulnerable code path is not reachable in your configuration and there is no exploitation. Reportable? No. Handle it: confirm reachability, update the dependency, document the analysis. Track it in your SBOM-driven component inventory. It becomes reportable only if it turns out to be exploitable and is then actively exploited.
Example 5: exploited zero-day in a discontinued-but-supported product
A product you stopped selling two years ago, but which is still within its declared support period, is hit by an exploited zero-day. Reportable? Yes. Support status, not sales status, governs scope. If you still owe security updates for it, an actively exploited vulnerability in it is reportable.
Edge cases worth pre-deciding
A few situations recur often enough that you should decide your stance in advance rather than under deadline pressure.
- Suspected but unconfirmed exploitation. A credible report says exploitation is occurring but you cannot yet confirm it. The prudent reading is that a credible signal starts the awareness clock. The early warning is allowed to be preliminary, so you can file it while you confirm rather than risk missing the window.
- Exploitation of a third-party component you ship. If the vulnerable component is part of the product you placed on the market and it is being actively exploited, the manufacturer obligation attaches to you regardless of who wrote the component.
- Vulnerability in a product no longer supported. If the product is genuinely out of support and you owe no further updates, it sits outside the ongoing handling regime. Be sure your end-of-support declarations are clear and documented, because this is exactly where disputes arise.
- Exploitation observed by a customer, not by you. A customer telling you they are being attacked through your product is awareness. The clock does not wait for you to reproduce it in a lab.
Why over-reporting is its own failure
It is tempting to treat the threshold conservatively and report anything that might qualify. This feels safe. It is not.
Authorities operate the reporting platform to surface genuinely exploited vulnerabilities and severe incidents so they can coordinate a response and warn others. A stream of non-exploited, routine vulnerabilities dilutes that signal and consumes capacity that should go to real events. It also trains your own organisation to treat reporting as routine paperwork, which erodes the urgency that a genuine Article 14 event demands.
The discipline the regulation expects is accurate classification: handle the many, report the few, and be able to show your reasoning either way. That reasoning trail is part of why the audit log matters.
Document the decision either way
For every event that could plausibly be reportable, record the determination and the basis for it. If you reported, record what evidence of active exploitation or severe impact you relied on. If you did not, record why the threshold was not met.
This record serves two purposes. It demonstrates to a market surveillance authority that you applied a consistent, defensible process. And it protects the individuals who made the call, because a documented good-faith classification is very different from an undocumented omission.
CVD Portal captures this automatically. Each submission carries its triage decision, the severity assessment, the active-exploitation determination, and a timestamped trail of who decided what and when, so the reasoning behind both reported and non-reported events is preserved without extra effort.
The bottom line
Article 14 reporting is narrow by design. Only actively exploited vulnerabilities and severe incidents affecting product security have to be reported. Severity scores, public proofs of concept, and vulnerable dependencies do not, on their own, trigger a report. They trigger handling.
Get the classification right and reporting becomes a rare, well-evidenced act rather than a constant burden. The next post in the series follows the report once it is filed, explaining how reporting to ENISA and national authorities is organised.