Skip to content
11 days until the Art. 14 reporting obligation (11 September 2026).
Documentation Support Risk class
03Blog & insight · Regulation · 5 August 2026 · 8 min read

Reported vs exploited: the 15-million difference

The 24-hour early warning is not owed for every vulnerability that lands in your inbox. It is owed only when there is reliable evidence that someone exploited it, without authorisation, in a real system. Everything hinges on one written line: the qualification of the event.

Source code under review on a screen
Photo: Pankaj Patel / Unsplash

Where the obligation actually begins

The Cyber Resilience Act does not ask you to report vulnerabilities. It asks you to report actively exploited vulnerabilities. The distinction is not rhetorical: it is written into the definition itself at Art. 3(42), and the whole 24-hour clock of Art. 14 hangs from it.

The trigger is not the existence of a flaw, nor the fact that someone told you about it. The trigger is reliable evidence that a malicious actor has used it, in a system, without the owner's authorisation. A researcher's responsible disclosure, an academic paper, an automated scan flagging an outdated library: none of these, on its own, starts the clock.

Art. 3(42)Actively exploited vulnerability: a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's authorisation.

The risk runs both ways

Report too little and you breach the obligation. Report everything, indiscriminately, and you pay a different price: you lose credibility with the CSIRT, you drown your own team in filings, and you burn the hours you would need on the one report that matters. Over-reporting is not a safe default. It is a slower way of failing.

The way out of both risks is the same, and it is unglamorous: a reasoned qualification, made quickly and written down. A documented "no" is a defence you can hand to an inspector. An implicit "no" — the report you silently decided not to file — is indistinguishable from negligence when someone asks, months later, why nothing was sent.

Three cases, and the line you would write for each

Qualification is easier to teach through examples than through definitions. Here are three that recur, with the exact reasoning we would enter in the register — not a verdict, but the evidence and the conclusion drawn from it.

Case 1 — Researcher email with a PoC

A security researcher writes to your disclosure address. Attached is a proof-of-concept that reliably triggers a buffer overflow on the current firmware. There is no claim, and no evidence, that anyone has used it against a live customer device.

Reported, not exploited. Register line: "Confirmed vulnerability, working PoC received from external researcher on [date]. No evidence of exploitation in any system without authorisation. Art. 3(42) not met → no Art. 14 early warning. Handled under the coordinated disclosure process; remediation timeline opened."

Case 2 — Honeypot and log evidence

Your honeypot captures a payload that exploits the same overflow, and production logs from two customer installations show the identical request pattern followed by an outbound connection to an unknown host. The behaviour matches active use in the wild, against systems no one authorised.

Exploited. File the early warning. Register line: "Reliable evidence of exploitation without authorisation: honeypot payload + matching production logs at two sites, [timestamps]. Art. 3(42) met → Art. 14 early warning filed with the CSIRT within 24h of [awareness time]. 72h update and final report scheduled."

Case 3 — Scanner flags an outdated dependency

A nightly dependency scanner flags a CVE in an old version of a library bundled in your product. There is no report of a vulnerability in your product, no PoC against your build, and no sign of exploitation anywhere. Just a version number below a threshold.

Neither — but document it. Register line: "Scanner flag on library [name/version], CVE [id]. Not yet confirmed as an exploitable vulnerability in our product; no evidence of exploitation. Art. 3(42) not met → no Art. 14 obligation today. Opened triage to confirm reachability; if it concerns a third-party component, upstream reporting under Art. 13(6) to be assessed."

Why "15 million" is in the title

The reporting obligations of Art. 13 and Art. 14 sit in the highest sanction band of the regulation: up to 15 million euro, or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. The figure is not a scare tactic. It is the ceiling the legislator attached specifically to the duties around vulnerability handling and notification.

What an authority weighs, in practice, is not whether you happened to guess right. It is whether you had a process and applied it. Two companies can reach the same "no" — one by silence, one by a dated register entry citing Art. 3(42). Only the second can show it. The qualification is not paperwork around the decision; the qualification is the decision.

The test in one line Is there reliable evidence that a malicious actor exploited it, in a system, without authorisation? If yes → 24h early warning. If no → a written, reasoned "no".

This article describes our reading of the regulatory text and does not constitute legal advice.

Risk class