Commission guidance on the Cyber Resilience Act treats a vulnerability as known when a relevant public database lists it. A manufacturer should match each product's SBOM against the EUVD, OSV.dev and NVD, and check exploitation in the CISA KEV catalog.
Key takeaways
- Commission guidance C(2026) 5252 point 233 treats a vulnerability as known when relevant publicly accessible vulnerability databases list it, and names the European vulnerability database (EUVD) as an example.
- Annex I Part I(2)(a) of the CRA requires products to be made available on the market "without known exploitable vulnerabilities", on the basis of the cybersecurity risk assessment and where applicable.
- OSV.dev matches open-source components by package name and version, and NVD matches firmware and vendor binaries by CPE.
- Since 15 April 2026, NIST enriches only priority CVEs in NVD, so many CVEs have no NIST severity score or CPE data.
- Under Article 17(5) of the CRA, ENISA adds a vulnerability notified under Article 14(1) to the EUVD after a fix is available, in agreement with the manufacturer.
Why do vulnerability databases matter under the CRA?
Public vulnerability databases decide which vulnerabilities a manufacturer is expected to know about. Annex I Part I(2)(a) requires products to be made available on the market "without known exploitable vulnerabilities", on the basis of the cybersecurity risk assessment and where applicable. Commission guidance C(2026) 5252 point 233 treats a vulnerability as known when relevant publicly accessible vulnerability databases list it, such as the European vulnerability database or other prominent vulnerability databases.
A listing is the start of the analysis. Point 235 adds that a report alone does not show that a vulnerability is exploitable in practice or that it applies to the specific product. The manufacturer investigates and confirms both.
Databases also serve component due diligence. Recital 34 lists one possible check as "verifying that a component is free from vulnerabilities registered in the European vulnerability database established pursuant to Article 12(2) of Directive (EU) 2022/2555 or other publicly accessible vulnerability databases". Annex I Part II(1) requires the manufacturer to identify and document vulnerabilities and components, including by drawing up a software bill of materials. The SBOM is the list that each database is matched against.
Which databases should a manufacturer check?
The right set depends on what the SBOM contains. Open-source packages, firmware and vendor binaries are each covered best by a different database.
| Database and operator | What it holds | Role in CRA work |
|---|---|---|
| CVE List, run by MITRE for CISA | CVE identifiers with the description from the numbering authority | The shared identifier in reports, advisories and SBOM matches |
| NVD, run by NIST | CVE records with NIST severity scores, weakness types and CPE product data for priority CVEs | Matches firmware, hardware and vendor binaries by CPE |
| EUVD, run by ENISA | Vulnerabilities from CVE data, vendor advisories, CSIRT alerts and exploitation markings | The EU database named in Recital 34, Article 17(5) and the Commission guidance |
| OSV.dev, run by Google with the OSV schema under OpenSSF | Advisories for open-source ecosystems and Linux distributions, such as npm, PyPI, Maven, Go, crates.io, Debian and Ubuntu | Matches open-source components by package name and exact version |
| GitHub Advisory Database, run by GitHub | Advisories for open-source packages, with or without a CVE | A main source of OSV.dev records |
| CISA KEV catalog, run by CISA | CVEs with reliable evidence of exploitation in the wild, each with remediation guidance | Exploitation evidence for the Article 14 assessment |
| JVN, run by JPCERT/CC and IPA | Vulnerabilities handled under the Information Security Early Warning Partnership in Japan | Products and components from Japanese vendors |
| GCVE, run by CIRCL | A correlation of many sources, with decentralised identifiers and exploitation sightings | Cross-source lookup when one database has no record |
Both lists grow each week. OSV.dev publishes its current ecosystem list, and CISA publishes the KEV catalog as a JSON feed.
What changed in NVD in 2026?
NIST changed how it enriches CVEs on 15 April 2026. NVD now enriches CVEs in the CISA KEV catalog, CVEs for software used in the US federal government, and CVEs for critical software as defined by Executive Order 14028. Other new CVEs wait at the lowest priority. Backlogged CVEs published in NVD before 1 March 2026 moved to the status "Not Scheduled", except CVEs in the KEV catalog.
The change matters most for components identified by CPE, such as firmware and vendor binaries. A CVE without NIST enrichment can lack the CPE data that a matching tool needs, so a scan that uses only NVD can miss affected components. Match open-source components against OSV.dev, and read the advisories of each firmware vendor. NIST accepts requests to enrich a specific CVE at nvd@nist.gov.
What does the EUVD add for a CRA manufacturer?
The EUVD is the vulnerability database that the CRA names. Article 12(2) of Directive (EU) 2022/2555 (NIS2) gives ENISA the task to develop and maintain it, and ENISA announced it as operational on 13 May 2025. ENISA fills it from CVE data, vendor advisories, CSIRT alerts and the CISA KEV catalog. ENISA correlates the data with Vulnerability-Lookup, the open-source software from CIRCL that also runs db.gcve.eu.
The CRA links the EUVD to Article 14 reporting. Under Article 17(5), after a security update or another corrective or mitigating measure is available, ENISA adds a publicly known vulnerability notified under Article 14(1) or Article 15(1) to the EUVD, in agreement with the manufacturer. A vulnerability that a manufacturer notified can therefore get an EUVD record after the fix ships.
ENISA became a CVE Program Root on 20 November 2025. It is now the point of contact in the CVE Program for EU and national authorities and for members of the EU CSIRTs network.
How should a manufacturer use the databases?
Match the SBOM, confirm each match, and record the decision.
- Keep one SBOM for each product version. Give each open-source component a package URL (purl), and give firmware and vendor binaries a CPE.
- Match purls against OSV.dev and CPEs against NVD.
- Look up each match in the EUVD and the CISA KEV catalog for its exploitation status.
- Confirm that the vulnerability is exploitable and applies to the product, as point 235 of the guidance expects.
- Record the result. Article 13(7) requires manufacturers to systematically document the vulnerabilities of which they become aware.
- Report a vulnerability in an integrated component to the person or entity that maintains it, as Article 13(6) requires.
A KEV listing is evidence of exploitation in the wild. When the product contains a KEV-listed vulnerability, assess it for Article 14 reporting without delay, because the 24-hour early warning runs from the moment the manufacturer becomes aware. The difference between an exploitable and an actively exploited vulnerability is explained in Exploitable vs. exploited.
The free SBOM exposure snapshot matches an SBOM against OSV.dev and checks each match for exploitation evidence from the EUVD and GCVE. CVD Portal also matches CPE components against NVD and keeps the findings for each product version.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), CELEX 32024R2847, Recital 34, Articles 13, 14 and 17, and Annex I.
- Directive (EU) 2022/2555 (NIS2), CELEX 32022L2555, Article 12.
- European Commission. Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 final, 27 July 2026, points 233 to 235. Listed on the Cyber Resilience Act implementation page.
- ENISA. Consult the European Vulnerability Database to enhance your digital security! 13 May 2025.
- ENISA. Stepping up our role in Vulnerability Management: ENISA Becomes CVE Root. 20 November 2025.
- NIST. NIST updates NVD operations to address record CVE growth. 15 April 2026.
- CISA. Known Exploited Vulnerabilities Catalog.
- OSV.dev. Data sources and ecosystem list.
- GitHub. GitHub Advisory Database.
- JPCERT/CC and IPA. Japan Vulnerability Notes.
- CIRCL. GCVE and db.gcve.eu.
Frequently asked questions
Is a vulnerability known under the CRA once a public database lists it?
Commission guidance C(2026) 5252 point 233 treats a vulnerability as known when relevant publicly accessible vulnerability databases list it. Point 235 adds that the manufacturer must still confirm that the vulnerability is exploitable and applies to the product.
Does the CRA require manufacturers to use the European vulnerability database?
No article of the CRA obliges a manufacturer to query the EUVD. Recital 34 names the EUVD and other publicly accessible vulnerability databases as a due diligence check for integrated components, and Article 17(5) has ENISA add notified vulnerabilities to the EUVD.
Is NVD enough for CRA vulnerability monitoring?
NVD alone leaves gaps. Since 15 April 2026, NIST enriches only priority CVEs, such as those in the CISA KEV catalog, so many CVEs have no NIST severity score or CPE data. Match open-source components against OSV.dev as well.