An ordinary vulnerability is not automatically an actively exploited vulnerability. The CRA definition adds a specific evidentiary condition: there must be reliable evidence that a malicious actor exploited the vulnerability in a system without the system owner’s permission.
That distinction matters when a public advisory, CVE record, supplier message, or scanner result enters the intake queue. Each can justify investigation, but none should be relabelled as evidence of active exploitation without examining what it actually establishes.
Test the evidence, not the label
Start with four bounded questions:
- Is the vulnerability contained in the manufacturer’s product?
- Does the evidence describe exploitation rather than only exploitability?
- Does it identify malicious use without the system owner’s permission?
- Is the evidence reliable enough to support the conclusion recorded?
The answer may change as new information arrives. Preserve the earlier assessment, attach the new evidence, and record the new decision time. That history is more useful than a final status with no explanation.
Build an evidence matrix
Give every exploitation signal its own row. Record the source, the original observation, the product and version it concerns, whether the source observed exploitation directly, and whether the activity was authorised. Keep a supplier statement, public advisory, customer report, telemetry finding, and researcher demonstration distinct until the evidence supports joining them.
A row may establish that exploitation is technically possible without establishing that it occurred. Another may establish malicious activity without proving that the exploited weakness is contained in the manufacturer’s product. Record both gaps explicitly instead of converting an urgent label into a legal conclusion.
Test product containment
Trace the reported weakness to the component, build, configuration, and released product in scope. If the vulnerable code is present but unreachable in the affected configuration, retain that reachability analysis and its assumptions. If a component version changed during remediation, preserve the before-and-after product mapping.
Use a separate column for contrary evidence. A vendor denial, clean telemetry window, or disputed attribution should be evaluated rather than deleted from the file. The reviewer can then explain why one source was more probative without pretending the conflict never existed.
Keep the second trigger open
A case that does not meet the actively exploited vulnerability definition may still need assessment as a severe incident affecting product security. Treat the two Article 14 triggers as separate tests. Closing one test is not a conclusion about the other.
Record the outcome as trigger met, trigger not met, or assessment open. A negative result needs a reopening condition, such as a confirmed product match or reliable exploitation observation. An open result needs an owner and review time so uncertainty does not become an unrecorded decision to wait.
This is a workflow distinction, not a substitute for legal judgment. Escalate ambiguous evidence to the accountable legal and security reviewers.
Continue this workflow with the conflicting-signal review and the component-containment analysis.