CVD Portal
← CRA Glossary
Security Standards & Frameworks

Common Vulnerabilities and Exposures (CVE)

CVE is a public catalogue of known cybersecurity vulnerabilities, each assigned a unique identifier (e.g. CVE-2024-12345) maintained by MITRE. Under the CRA, manufacturers are expected to track CVEs affecting their products and report actively exploited vulnerabilities to ENISA.

CVE is a public catalogue of known cybersecurity vulnerabilities, each assigned a unique identifier (e.g. CVE-2024-12345) maintained by MITRE. Under the CRA, manufacturers are expected to track CVEs affecting their products and report actively exploited vulnerabilities to ENISA.

Security Standards & Frameworks
Free CVD portal →

What Is CVE?

The Common Vulnerabilities and Exposures (CVE) programme, operated by MITRE Corporation and funded by the US Cybersecurity and Infrastructure Security Agency (CISA), maintains a public catalogue of individually identified software and hardware vulnerabilities. Each vulnerability receives a CVE ID (e.g. CVE-2024-12345) that serves as a universal reference across vulnerability databases, security tools, and advisories. CVE IDs are assigned by CVE Numbering Authorities (CNAs) - organisations authorised by MITRE to assign IDs within their scope. Large manufacturers (e.g. Microsoft, Siemens) are CNAs for their own products. Smaller manufacturers obtain CVE IDs via the National Vulnerability Database (NVD) or a root CNA.

CRA reference:Article 13(6)

CVE in the Context of CRA Compliance

The CRA requires manufacturers to monitor for vulnerabilities in their products, including in third-party and open-source components (Annex I Part II, §2). CVE is the primary mechanism for this monitoring. Manufacturers must:

  • Subscribe to CVE feeds or vulnerability databases for components in their SBOM.
  • Assess whether a newly published CVE affects their deployed products.
  • Determine if a CVE is actively exploited (triggering the Article 14 24-hour ENISA notification).
  • Reference CVE IDs in security advisories and CSAF documents.

When manufacturers publish a patch for a vulnerability they discovered, they should request a CVE ID to ensure the vulnerability is formally tracked in the public record.

CRA reference:Article 13(6), Article 14, Annex I Part II

Becoming a CVE Numbering Authority (CNA)

Manufacturers that regularly discover and fix vulnerabilities in their own products should consider becoming a CVE Numbering Authority (CNA). CNA status allows a manufacturer to self-assign CVE IDs without waiting for MITRE, which speeds up coordinated disclosure and advisory publication. Requirements include: a functioning PSIRT or equivalent team, a published CVD policy, capacity to respond to CVE-related queries, and agreement to MITRE's CNA Rules. ENISA and the EU regulatory framework treat CNA membership as evidence of a mature vulnerability management programme. Manufacturers with a significant product portfolio or active bug bounty programme will find CNA status particularly valuable.

CRA reference:Article 13(6)

Common CVE-Related Mistakes

Manufacturers frequently encounter these problems with CVE:

  • Not monitoring third-party component CVEs - a CVE in an embedded OpenSSL version affects the manufacturer's product; ignoring it is a CRA violation.
  • Publishing advisories without a CVE ID - an advisory that cannot be cross-referenced with the CVE catalogue is difficult for customers and regulators to action.
  • Treating NVD CVSS scores as final - NVD enriches CVE records with CVSS scores, but these are sometimes inaccurate for specific product contexts; manufacturers should score independently.
  • Delayed CVE requests - requesting a CVE ID after publishing a patch wastes the coordinated-disclosure window and frustrates customers trying to correlate their patch management data.

CVD Portal makes Common Vulnerabilities and Exposures (CVE) compliance straightforward.

Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Receiving and tracking reports is free for all manufacturers placing products with digital elements on the EU market. Article 14 filing with the SRP-ready package is on Pro.

Start your free portal

Frequently asked

Do we need a CVE ID for every vulnerability we fix?+

Best practice is to request a CVE ID for any vulnerability that could be independently discovered or exploited by an external party. Internal configuration issues or logic errors that only affect a specific customer deployment may not require a CVE. For vulnerabilities discovered via your CVD programme or found by external researchers, always request a CVE ID - it is expected in CRA-compliant security advisories and enables customers to track remediation in their patch management systems.

How do we get a CVE ID for a vulnerability in our product?+

If you are not a CNA, submit a request through the MITRE CVE Request web form or contact a Root CNA. Provide the affected product name and version, a description of the vulnerability type, and proof of the issue. MITRE or the relevant Root CNA will assign an ID, which you then reference in your security advisory. If you issue advisories regularly, applying for CNA status simplifies this process significantly.

What is the National Vulnerability Database (NVD) and how does it relate to CVE?+

The NVD, operated by NIST, enriches CVE records with additional metadata: CVSS scores, CWE classifications, CPE (Common Platform Enumeration) identifiers for affected products, and remediation guidance. Manufacturers should verify that NVD's CVSS score and affected-product enumeration for their CVEs is accurate, as downstream customers and security tools rely on NVD data to determine whether they are affected.

Related terms

Common Vulnerability Scoring System (CVSS)CVSS is an open framework for communicating the characteristics and severity of software vulnerabilities, producing a numerical score from 0 to 10. Manufacturers use CVSS scores to prioritise remediation and to communicate risk in security advisories required under the CRA.Software Bill of Materials (SBOM)An SBOM is a formal, machine-readable inventory of all software components - including open-source libraries, third-party dependencies, and firmware packages - that make up a product. The EU Cyber Resilience Act requires manufacturers to maintain an SBOM as part of their technical documentation.Security AdvisoryA security advisory is a public document published by a manufacturer to inform users of a security vulnerability in a product, the severity of the issue, and how to remediate it. Annex I Part II of the CRA requires manufacturers to publish security advisories when releasing vulnerability fixes.Common Security Advisory Framework (CSAF)CSAF is an OASIS open standard for machine-readable security advisory documents, replacing the older CVRF format. ENISA recommends CSAF as the preferred format for security advisories published by manufacturers under the EU Cyber Resilience Act.CISA Known Exploited Vulnerabilities (KEV) CatalogueThe CISA Known Exploited Vulnerabilities (KEV) catalogue is a curated list maintained by the US Cybersecurity and Infrastructure Security Agency that identifies CVEs for which there is credible evidence of active exploitation in the wild. For EU manufacturers, the KEV catalogue is the highest-priority vulnerability intelligence source - any KEV entry affecting a shipped product triggers the CRA's 24-hour ENISA notification obligation.Common Vulnerability Scoring System (CVSS) - Full GuideThe Common Vulnerability Scoring System (CVSS) is the industry-standard framework for assessing and communicating the severity of software vulnerabilities using a numerical score from 0 to 10. CVSS scores are referenced throughout the CRA compliance ecosystem - in vulnerability advisories, SBOM tooling, CSAF documents, and PSIRT triage processes - and are the primary language for communicating vulnerability severity under the regulation.

CRA articles using this term

Article 13Obligations of ManufacturersArticle 14Active Exploitation and Incident Reporting - 24h, 72h, and 14-Day ObligationsAnnex IEssential Cybersecurity Requirements for Products with Digital Elements

Sector checklists covering Common Vulnerabilities and Exposures (CVE)

Consumer Routers & ModemsConsumer routers and modems are high-value targets for attackers and face specific CRA requirements around default credentials, remote management security, and firmware update integrity. Routers marketed for home use are Default class; those marketed for industrial or critical infrastructure use may be Annex III Class II.Industrial Controllers & PLCsIndustrial controllers, PLCs, and SCADA components are classified as Important Class II under Annex III of the CRA, requiring third-party conformity assessment. These products have long operational lifetimes (10–20+ years), network connectivity, and significant safety implications. CRA compliance must be planned well in advance of the September 2026 deadline.

Browse the full CRA Compliance Checklist

See how Common Vulnerabilities and Exposures (CVE) fits into your complete CRA compliance programme.

View checklists →