The EUVD: Europe has its own exploited-vulnerability list, and the report form asks for it

If you have built any kind of exploitation watch in the last three years, it almost certainly watches CISA's Known Exploited Vulnerabilities catalogue. It is free, it is well maintained, it has an obvious JSON endpoint, and it has become the default answer to "is anyone actually using this one." None of that is wrong. It is just not the list the authority reading your Article 14 filing reaches for first.

The short answer

ENISA runs the European Vulnerability Database, and it records which vulnerabilities are being exploited. The reporting form has a field for a EUVD identifier and no field at all for a KEV reference. The two catalogues overlap heavily and not entirely, so watching only one is a real gap — and since September, either listing is enough on its own to raise an alert here.

The form asks for one identifier and not the other

This is the detail worth acting on. The vulnerability notification asks for a CVE identifier, and separately for the record in the European Vulnerability Database if one exists.Art. 14⁠(2)⁠⁠(b)⁠ There is no field anywhere on the form for "this is in KEV."

Read that as what it is: a signal about which evidence the recipient is set up to recognise. Citing an identifier the reader already holds a record for is not a formality, it is the difference between a claim they can look up and a claim they have to take on trust — at hour twenty-four, from a manufacturer they have never heard of.

The two lists are not the same list

They cover the same phenomenon and they do not contain the same rows. Different sources, different evidence thresholds, different speeds, and a European record will reasonably pick up things a US federal agency's catalogue has no particular reason to. A watch built on one of them has a blind spot shaped exactly like the other one.

It is also why "is this exploited" is a question that deserves two answers rather than one, and why we store the exploitation date from each separately instead of collapsing them into a boolean.

A correction to something we wrote

When we described how we tier alerts we said Tier A — the only tier that interrupts anybody — is earned by membership in the KEV catalogue or by an exploitation-probability score of 0.5 or higher. That was two signals. It is three now: a listing in either catalogue, or the probability threshold. A vulnerability that ENISA records as exploited and CISA has not yet added raises the same alert it would have raised the other way round.

The post is unchanged apart from this note, because it is easier to trust a blog that says what it corrected than one whose old posts quietly acquire new facts.

What neither list can do for you

Neither one matches. KEV and the EUVD both name vendors and products in prose, not in package identifiers, so neither can tell you whether a component in your bill of materials is the thing being exploited. They enrich advisories that other feeds describe in machine-readable terms; the matching is done elsewhere, against version ranges.

And neither listing is a reportable event. The duty turns on exploitation of your product.Art. 14⁠(1)⁠ A catalogue entry — either catalogue — says somebody somewhere is exploiting something you happen to ship a copy of. That is a reason to open an assessment, and it is not a reason to start a clock. The distinction survives having two lists instead of one; it just now has two ways of arriving.

You can see which of your own components carry a live exploitation listing with the SBOM check — nothing is stored, and the file never leaves the request.