Can we object when ENISA adds one of our vulnerabilities?

For the route through Article 17(5), yes. ENISA adds a notified vulnerability only in agreement with the manufacturer, and that holds for notifications under Article 14(1) as well as for voluntary ones under Article 15(1). The control reaches no further than that, though. Article 12(2) of the NIS2 Directive lets entities and their suppliers of network and information systems register publicly known vulnerabilities themselves, quite independently of you. Agreement over one channel is therefore not a veto over what the database contains.

Is a single check before placing the product on the market enough?

No. Article 13(8) CRA requires vulnerabilities in the product, including its components, to be handled effectively throughout the support period, and Article 13(7) requires systematic documentation of all relevant cybersecurity aspects, including the vulnerabilities the manufacturer becomes aware of. An entry created months after launch therefore concerns you exactly as much as one you could have found beforehand. In practice that means a recurring automated match of the Software Bill of Materials (SBOM) against whichever sources you rely on. How often that check has to run, the CRA does not say.

What do we do when a component we ship has an entry there?

Article 13(6) CRA requires you to report the vulnerability to the person or entity manufacturing or maintaining the component and to address and remediate it in line with Annex I, Part II. Where you have developed a software or hardware modification yourself to fix the vulnerability in that component, share the relevant code or documentation, in a machine-readable format where appropriate. The entry alone does not trigger the reporting duty under Article 14, which presupposes an actively exploited vulnerability in your own product. Where the vulnerable part is not reachable in your product at all, record that assessment, for instance with VEX.

Cyber Resilience Act

European vulnerability database

Practical term

The European vulnerability database is a publicly accessible record of known vulnerabilities in ICT products and ICT services. ENISA, the European Union Agency for Cybersecurity, develops and maintains it. Its legal basis sits not in the Cyber Resilience Act (CRA) but in Article 12(2) of the NIS2 Directive (Directive (EU) 2022/2555). It has been running under the abbreviation EUVD since 2025; that abbreviation appears in neither legal text and comes from the practice of ENISA.

The CRA establishes no vulnerability database of its own. It draws on the existing one, and does so at two opposite ends of the vulnerability process. In one place the database is a source manufacturers can consult when checking parts they did not write themselves. In the other it is the destination for fixed vulnerabilities once they have been notified.

What an entry contains

Article 12(2) of the NIS2 Directive fixes the minimum content. Every entry carries three things:

information describing the vulnerability
the affected ICT products or ICT services and the severity of the vulnerability in terms of the circumstances under which it may be exploited
the availability of related patches or, while none are available, guidance from the competent authorities or the CSIRTs on mitigating the resulting risks

Access to that information is open to all stakeholders. Registering an entry, by contrast, is voluntary. Entities, whether or not they fall within the scope of the NIS2 Directive at all, and their suppliers of network and information systems may disclose and register publicly known vulnerabilities there.

First role: a reference for due diligence

Article 13(5) CRA requires manufacturers to exercise due diligence when integrating parts sourced from third parties. The article text names no database. Recital 34 fills that in and lists four measures, one or more of which should be taken into account:

verifying that the manufacturer of a Component has demonstrated conformity with the Regulation, for instance by checking whether it already bears the CE marking
verifying that the component receives regular security updates, such as by checking its security update history
verifying that it is free from vulnerabilities registered in the European vulnerability database or in other publicly accessible vulnerability databases
carrying out additional security tests

Two qualifications matter. The CRA mandates no particular database and puts the European one expressly alongside other publicly accessible sources. And the appropriate level of Due diligence for third-party components depends on the nature and the level of cybersecurity risk associated with the component in question. A search that turns up nothing is one building block among several, not an absolution.

Second role: a destination for notified vulnerabilities

Article 17(5) CRA describes the opposite direction. ENISA adds a publicly known vulnerability notified under Article 14(1) or Article 15(1) to the European vulnerability database. Two conditions attach to that, and both are easy to miss.

A Security update or another form of corrective or mitigating measure must be available.
The addition happens in agreement with the manufacturer of the product concerned.

A notification therefore reaches the database neither automatically nor at once. Recital 66 states what this route is for. The database is meant to help manufacturers detect known exploitable vulnerabilities in their own products.

Not the same thing as the reporting platform

The Single reporting platform under Article 16 CRA and the European vulnerability database are two separate systems from two separate legal acts. Through the platform, a manufacturer notifies an actively exploited vulnerability simultaneously to the CSIRT designated as coordinator and to ENISA. Under Article 16(5) the specifications for that platform must ensure that information about a notified vulnerability for which no corrective or mitigating measure is yet available is shared only under strict security protocols and on a need-to-know basis.

The database sits at the other end, because it is public. Recital 73 puts the relationship between the two cautiously. When establishing the reporting platform, ENISA should analyse “potential complementarities” with the database. No technical link is prescribed.

When this starts to apply

Article 71(2) CRA sets the general date of application at 11 December 2027. Only two blocks come earlier: Article 14 from 11 September 2026, and Chapter IV (Articles 35 to 51) from 11 June 2026. Articles 16 and 17 are not among them, even though Article 14 already requires notification through the platform established under Article 16. How that gap is bridged in practice does not follow from the text of the Regulation.

Why a European database exists

Recital 63 of the NIS2 Directive gives the reasoning. Comparable registries are operated and maintained by entities not established in the Union. A database maintained by ENISA is meant to add transparency about the publication process before a vulnerability is publicly disclosed, and to add resilience should similar services be disrupted or interrupted.

Duplication of effort is to be avoided. ENISA should therefore explore whether it can enter structured cooperation with comparable registries under third-country jurisdiction, expressly including the operators of the CVE system.

What the CRA does not require

Nothing obliges you to create your own entries in the European vulnerability database. Your publication duty comes from Annex I, Part II, point 4: once a security update has been made available, information about the fixed vulnerability must be shared and publicly disclosed, including a description of the vulnerability, enough detail for users to identify the affected product, the impacts, the severity and clear and accessible guidance on remediation. In duly justified cases, where the manufacturer considers the security risks of publication to outweigh the security benefits, publication may be delayed until users have had the chance to apply the relevant patch.

An entry ENISA makes under Article 17(5) does not stand in for that disclosure. It sits beside it.

Practical questions

: For the route through Article 17(5), yes. ENISA adds a notified vulnerability only in agreement with the manufacturer, and that holds for notifications under Article 14(1) as well as for voluntary ones under Article 15(1). The control reaches no further than that, though. Article 12(2) of the NIS2 Directive lets entities and their suppliers of network and information systems register publicly known vulnerabilities themselves, quite independently of you. Agreement over one channel is therefore not a veto over what the database contains.
: No. Article 13(8) CRA requires vulnerabilities in the product, including its components, to be handled effectively throughout the support period, and Article 13(7) requires systematic documentation of all relevant cybersecurity aspects, including the vulnerabilities the manufacturer becomes aware of. An entry created months after launch therefore concerns you exactly as much as one you could have found beforehand. In practice that means a recurring automated match of the Software Bill of Materials (SBOM) against whichever sources you rely on. How often that check has to run, the CRA does not say.
: Article 13(6) CRA requires you to report the vulnerability to the person or entity manufacturing or maintaining the component and to address and remediate it in line with Annex I, Part II. Where you have developed a software or hardware modification yourself to fix the vulnerability in that component, share the relevant code or documentation, in a machine-readable format where appropriate. The entry alone does not trigger the reporting duty under Article 14, which presupposes an actively exploited vulnerability in your own product. Where the vulnerable part is not reachable in your product at all, record that assessment, for instance with VEX.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.