CVE

What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a unique, public identifier for a known vulnerability in software, hardware or firmware, such as CVE-2021-44228, used worldwide by vendors, defenders and tools to refer to the same security vulnerability. The CVE Program has existed since 1999, is operated by MITRE and is funded by the US agency CISA. A CVE tells you which vulnerability it is, not how severe it is: that is what CVSS is for. In OT environments, the CVE ID is the key that links vendor advisories, scanners and your own asset list together.

🧠 How does the CVE Program work?

The CVE Program is essentially a dictionary: it assigns identifiers but does not test or fix anything itself. The work is spread across hundreds of organisations:

• MITRE - has run the programme since its launch in September 1999, when the first list contained 321 entries
• CVE Numbering Authorities (CNAs) - more than 500 organisations allowed to assign CVE IDs within their own scope, such as Microsoft, Siemens, ABB, Schneider Electric and Rockwell Automation
• Root CNAs - coordinators above a group of CNAs; since 15 September 2020 CISA has been the top-level root for vendors of industrial control systems (ICS) and medical devices
• CVE Board - a board with representatives from government, industry and research that sets the rules

Europe is taking a larger role. ENISA has been a CNA since January 2024 and a root for European organisations since November 2025. The Dutch DIVD (Dutch Institute for Vulnerability Disclosure) is a CNA and now sits under that ENISA root.

The programme proved fragile. In April 2025 the contract between CISA and MITRE was about to expire; CISA extended it at the last minute by eleven months, to 16 March 2026. Members of the CVE Board then set up the CVE Foundation, aimed at more independent governance. In early 2026 CISA stated that funding for the programme had been secured.

🧱 How is a CVE ID structured?

A CVE ID has the form CVE-YYYY-NNNN. The year is the year in which the ID was reserved or assigned, not necessarily the year of discovery or publication. Since 1 January 2014 the sequence number has at least four digits and can be longer, as in CVE-2024-123456.

A CVE Record has three states:

A published record contains at least:

• The CVE ID
• A description of the vulnerability
• The affected products and versions
• References, such as the vendor’s advisory

Often, but not always, it also includes a CVSS score, a CWE category (the type of weakness, for example a buffer overflow) and machine-readable product identifiers (CPE). That enrichment comes from the CNA itself, from CISA, which since 2024 adds extra data as a so-called ADP, or from the National Vulnerability Database (NVD) run by NIST.

🔄 What is the difference between CVE, CVSS, CWE and KEV?

These terms are often confused, but each answers a different question:

CVSS v3 and v4 rate scores as follows:

🎯 Why are CVEs important?

CVEs make vulnerability management possible at scale. Without a common identifier, every vendor, scanner and database would name the same flaw differently. With a CVE you can:

• Quickly establish whether your systems are vulnerable, by matching CVEs against your asset inventory
• Prioritise updates within patch management, combined with CVSS, KEV and your own context
• Automate: vulnerability scanners, SBOMs and CSAF advisories all refer to CVE IDs
• Communicate unambiguously with vendors, the NCSC, your CERT and regulators

The number of CVEs is growing fast: almost 40,000 were published in 2024 and more than 48,000 in 2025. Since 1999 the total has passed 300,000. Nobody can assess them all, so filtering is essential.

The pressure is also visible at the NVD. A backlog in enrichment built up from February 2024. Since 15 April 2026 NIST prioritises enrichment for CVEs in the KEV catalogue, in software used by the US federal government and in critical software; backlogged CVEs outside those groups are marked Not Scheduled. If your scanner relies entirely on NVD data, it will miss product mappings as a result. Vendor advisories and CSAF feeds are therefore becoming more important.

🏭 How do you use CVEs in OT environments?

In industrial environments, CVEs affect among others:

• PLCs, SCADA systems, HMIs and industrial gateways
• Network components such as routers, switches and firewalls
• Software such as MES, historians and Windows engineering workstations
• IT components inside the OT zone, such as VPN gateways for remote access

Well-known cases show how CVEs and OT meet. In 2010 Stuxnet spread partly via CVE-2010-2568, a flaw in how Windows handled shortcut files. CVE-2023-6448, a default password in Unitronics Vision PLCs, was exploited against drinking water utilities in late 2023. And Log4Shell (CVE-2021-44228), public since 9 December 2021, let attackers execute code remotely (RCE) with a single simple string through the Apache Log4j logging library. It also hit many industrial software packages and scored 10.0 on CVSS.

A practical approach in OT:

1. Know your installation - record the manufacturer, type and firmware version of each asset; without a version there is no CVE match.
2. Follow the right sources - advisories from your vendors (preferably as a CSAF feed), CISA ICS advisories, NCSC advisories and the KEV catalogue.
3. Assess in context - is the system reachable, is the flaw being actively exploited, does it affect safety? Record the decision in your risk management.
4. Choose a measure - patch during a maintenance shutdown, or mitigate temporarily with network segmentation, firewall rules or extra monitoring when patching is not immediately possible.
5. Verify and document - this aligns with the patch and vulnerability requirements of IEC 62443 and with the CSIR approach.

In the Netherlands, regulation adds to this. The Dutch Cybersecurity Act (Cyberbeveiligingswet) requires essential and important entities to handle vulnerabilities actively, and under the Cyber Resilience Act manufacturers have had to report actively exploited vulnerabilities within 24 hours since 11 September 2026 under the CRA reporting obligations. Researchers who find a flaw can report it through responsible disclosure to the vendor, the NCSC or DIVD.

❓ Frequently asked questions

Who assigns a CVE ID?

A CVE ID is assigned by a CVE Numbering Authority (CNA), usually the vendor of the affected product itself, such as Siemens or Microsoft. If the vendor has no CNA of its own, a root CNA assigns the ID; for industrial control products that is CISA. MITRE acts as the CNA of last resort.

Does a CVE mean my system has been hacked?

No, a CVE only means that a known vulnerability exists in a particular product version. Whether your system is really at risk depends on the version, the configuration, its reachability and whether the flaw is being actively exploited. That is why you always combine a CVE with CVSS, the KEV catalogue and your own context.

What is the difference between a CVE and a zero-day?

A zero-day is a vulnerability exploited before the vendor knows about it or has a patch, and it often has no CVE ID yet. Once the vulnerability becomes known, it usually receives a CVE after all. Many CVEs in the KEV catalogue started out as zero-days.

Why does a CVE ID contain a year?

The year in a CVE ID indicates the year in which the ID was reserved or assigned. A vulnerability reserved in December and published in January therefore keeps the earlier year. The year says little about how old the flaw actually is.

Where can I look up CVEs for my OT equipment?

You can find CVEs for OT equipment in the manufacturer’s advisories, CISA’s ICS advisories, NIST’s NVD and ENISA’s European Vulnerability Database. Vendors such as Siemens publish their advisories on a fixed day each month, including as machine-readable CSAF files. Ideally, link these sources automatically to your asset inventory.

Does every vulnerability get a CVE?

No, only publicly known vulnerabilities in products covered by the CVE Program receive a CVE ID. Misconfigurations, weak passwords in your own installation or design flaws in a bespoke application usually do not get one. They still belong in your vulnerability management process.

📌 In summary

A CVE is the common identifier the whole industry uses to refer to the same vulnerability. The programme run by MITRE and funded by CISA has more than 500 CNAs and publishes tens of thousands of CVEs a year, which makes prioritising with CVSS, KEV and your own context indispensable. In OT, the CVE ID is the link between vendor advisories, your asset inventory and your patch and mitigation decisions.

A CVE is a unique identifier for a known vulnerability that helps organisations respond quickly and consistently to security risks: an essential tool for patch management, risk management and information security, including in OT environments.