Why does a vulnerability become reportable under the Cyber Resilience Act?

When a CRA vulnerability crosses the reporting threshold

The cyber resilience Act is not triggered by every weakness disclosed in a product. Reporting becomes relevant when the vulnerability has crossed from theoretical exposure into evidence-based harm, especially active exploitation or a serious incident that degrades core security properties. That distinction matters because the reporting duty is about observable impact, not vulnerability presence alone.

A useful way to think about it is that the CRA cares about whether the weakness has become operationally real. If attackers are already using it, or if the product has suffered an incident that undermines confidentiality, integrity, authenticity or availability, the reporting clock is no longer hypothetical. The key question is whether the product’s trust boundary has been materially affected.

Evidence, impact, and why a CVE is not enough

A CVE record can describe a valid weakness, but a reportable CRA event requires more than cataloguing. The practical trigger is reliable evidence, such as exploit telemetry, incident response findings, or confirmed abuse that shows the vulnerability is being used or has caused serious harm. This is why teams should separate vulnerability triage from regulatory incident assessment.

The reporting decision also depends on impact severity. A flaw may be technically real yet still not rise to CRA reporting if it has not been exploited and has not caused a severe security incident. Conversely, a lower-profile issue can become reportable quickly if it is used in the wild against a product in a way that compromises protected functions or creates material exposure.

For product teams, this means evidence collection must be good enough to distinguish proof of concept chatter from reliable signs of real-world abuse. Logs, abuse reports, detection signals, customer complaints and forensic analysis all matter because they help establish whether the issue has moved into the reportable category.

How teams should interpret reportability in practice

Practitioners should treat the CRA threshold as a reporting and escalation test, not as a vulnerability scoring exercise. A weakness can be severe from a security perspective without yet meeting the legal reporting trigger, and the reverse is also true: once exploitation or serious impact is confirmed, the regulatory response becomes part of the remediation workflow.

That makes ownership important. Security, product, legal and incident response functions need a shared decision path so that confirmed exploitation is not trapped in a pure engineering queue. The fastest errors here are either under-reporting because the issue is “just another CVE”, or over-reporting every disclosed weakness without checking whether there is evidence of real harm.

In practice, the most defensible position is to document the evidence standard in advance, define who validates exploitation or incident impact, and ensure the reporting assessment is separate from the vulnerability fix itself. That keeps the organisation from confusing “known flaw” with “reportable event”.

Risk and Threat Considerations

Reportability exists because exploited vulnerabilities can turn into wider customer and ecosystem harm before the patch is fully deployed. The main risk is not the existence of the flaw, but the gap between discovery, confirmed abuse and coordinated disclosure, where attackers can continue to exploit the issue while organisations debate severity.

Failure mechanism: Attackers or incident responders provide reliable evidence that the vulnerability is being actively abused, or that the product has suffered a severe incident affecting confidentiality, integrity, authenticity or availability. At that point, the organisation must treat the issue as both a security problem and a reportable regulatory event.

Impact: Delayed escalation can leave customers exposed, slow coordinated remediation and create compliance failure. Under-reporting can also weaken trust in product security disclosures, while over-reporting can waste incident-response capacity and dilute attention from the issues that are actually being exploited.

Practitioner Guidance

What to verify: Confirm that the evidence is specific enough to show exploitation or severe incident impact, not just theoretical exploitability. If the only signal is a CVE, proof of concept or scanner output, treat it as a vulnerability management case until stronger evidence emerges.

Decision rule: If the issue has confirmed abuse or a serious security incident tied to the product, escalate immediately into the reporting workflow and preserve the evidence trail. If not, keep it in vulnerability triage and monitor for indicators that the risk has become operational.

What good looks like: A single, documented path for deciding when technical findings become reportable events, with clear handoff between engineering, incident response and legal review. The organisation should be able to show why it did, or did not, classify the issue as reportable.

Practitioner takeaway: Under the CRA, reportability is driven by demonstrated exploitation or serious security impact, so the real control is disciplined evidence handling and fast cross-functional escalation.

Related resources from NHI Mgmt Group

• Why do products with digital elements need continuous vulnerability management under the EU Cyber Resilience Act?
• Why do legacy authentication methods become a bigger problem under resilience-led cyber policy?
• Why does the EU Cyber Resilience Act force teams to rethink vulnerability management timing?
• How should organisations control source-code access under the Cyber Resilience Act?