How the CVE contract scare exposed the public plumbing under every patching policy

The week

Most executives have never heard of the CVE program, yet almost every security report that crosses their desk depends on it. In the middle of April 2025, it came within hours of going dark.

On April 15, 2025, MITRE, the nonprofit that runs the program, told its members that its contract to operate the Common Vulnerabilities and Exposures program would expire the next day. It warned that operations could be interrupted.

MITRE had created the CVE list in 1999, and the federal government had funded it for most of the time since, latterly through CISA within the Department of Homeland Security. MITRE served as the program’s secretariat and top-level authority. It maintained the rules, ran the central record service and coordinated a CVE Board drawn from industry, academia and government. The letter arrived during a broad review of federal contracts and spending that spring, which made an abrupt end seem plausible to many readers.

CVE is the naming system for software flaws. Someone might discover a weakness in a piece of software, such as a bug in a widely used web server that lets an outsider take control of it. The flaw then gets a standard identifier, a short code such as “CVE” followed by a year and a number. That code works much like a part number in a car recall. Vendors put it in their warnings, and the scanners that sweep a company’s computers for problems look for it. Patching tools use it to match fixes to machines, and security teams use it to talk to one another without confusion. Remove the shared name and everyone is suddenly describing the same problem in different words.

The records themselves were not at immediate risk. Published CVE records were already mirrored in a public code repository and copied into countless vendor databases. What a lapse threatened was the flow of new records: the assignment of identifiers to newly found flaws, the publication of their descriptions, and the coordination among the organizations allowed to issue them.

The warning set off a scramble across the security industry. Late on April 15, the Cybersecurity and Infrastructure Security Agency (CISA), the federal agency that sponsors the program, said it had executed an option period on the contract. It had used a clause already written into the agreement to keep the work going, avoiding a lapse in service.

CISA said the program was invaluable to the cyber community and a priority for the agency. Its statement did not end the debate about the program’s future. Many in the industry noted that an option period postponed the question of long-term funding and governance rather than settling it.

The next day, April 16, a group of CVE board members announced a new nonprofit, the CVE Foundation, to pursue more independent governance for the program. Its founders said they had spent the previous year developing a plan to move the program to a dedicated nonprofit, because they were concerned about its reliance on a single government sponsor. Their point was simple: something this central should not hang on a single contract with a single sponsor.

The scare did not arrive out of nowhere. It landed on top of a separate, slower problem. Since early 2024, the National Vulnerability Database, run by the National Institute of Standards and Technology (NIST), had been building a backlog. The NVD is where many flaws get the extra detail that makes them useful, such as how severe they are and which products they affect. Records had been piling up waiting for that analysis.

NIST had been candid about the trend. In a March 19, 2025 update, it said processing had returned to roughly the rate before the 2024 slowdown. But CVE submissions had risen by 32 percent in 2024, so the backlog was still growing. It said it was exploring machine learning to automate some of the work. On April 2, 2025, less than two weeks before MITRE’s letter, the NVD changed the status of older records. CVEs published before 2018 that were still awaiting enrichment were marked “Deferred.” That meant the oldest records would not get NVD analysis unless circumstances changed.

CISA had also begun filling part of the gap itself. In 2024 it started a project it called Vulnrichment, adding its own assessments to CVE records as an authorized data publisher. Those additions included decision points on whether a flaw was being exploited, whether exploitation could be automated and what an attacker could achieve, plus severity scores and weakness types for higher-risk flaws. In December 2024, CISA stopped adding the product identifiers that scanners use to match flaws to software. Enrichment was already coming from several places, each covering a different slice.

So in one week, leaders who had never thought about this plumbing learned two things. The naming system could stop on a contract date, and the system that explains the names was already falling behind.

Few organizations list the CVE program in their risk register. It is so deep in the security stack that it feels like a law of nature, as permanent as the calendar. The April 2025 scare showed otherwise. It was a government contract with an expiry date and a single sponsor.

For banks, health systems and agencies, the useful exercise is to trace how their own vulnerability management, and the audit evidence built on top of it, depends on public infrastructure they do not control. That dependency has three layers. Identification gives each flaw a shared name. Enrichment adds the severity and product data that make the name useful. Prioritization turns both into decisions about what to fix first. Each layer is owned by someone different, and each degrades in a different way.

Vulnerabilities, patches and the problem of scale

Every piece of software has mistakes in it. Most are harmless. Some, called vulnerabilities, let an attacker do something they should not be able to do: read data, take over a machine, or lock files and demand payment. When a vulnerability is found, the vendor usually writes a fix, called a patch, and customers install it. That cycle of finding, fixing and installing is what security teams call vulnerability management.

The trouble is scale. A large organization runs thousands of applications across tens of thousands of laptops, servers, medical devices, network boxes and cloud services. Thousands of new vulnerabilities are published every year. No team can patch everything at once, so every organization needs a way to answer three questions quickly. The first is what the flaw is. The second is whether it is serious and present in the environment. The third is which flaws to fix today and which can wait a month.

Who owns the process inside an organization

Inside most organizations, vulnerability management is split across teams. The security team runs scanning, interprets findings and sets priorities. IT operations and application owners install patches and absorb the risk of breaking something. Change management sets the windows when systems can be changed. Risk management and internal audit check that the policy was followed. Each handoff is a place where a missing rating or an unmatched asset can disappear.

The trade-offs differ by sector. A bank’s core processing and payment systems often run under strict change freezes around month-end and peak periods, so an urgent patch competes with operational stability. A hospital cannot reboot an infusion pump or an imaging system on a security team’s schedule, and many devices can be patched only with the manufacturer’s approval. A county may run a public safety dispatch system that must stay available around the clock. In each case, prioritization decides how much operational risk the organization accepts to remove security risk. That decision is only as good as the data behind it.

Those three questions map neatly to the three layers. And for most organizations, the answers to the first two come largely from outside the building.

How the flow outgrew the system

The volume is no longer marginal. NIST reported that CVE submissions rose 32 percent in 2024 alone. Many more organizations were issuing identifiers, open-source projects were assigning them more readily, and researchers were finding more flaws with automated tools. Each new record adds work for every downstream layer: someone must score it, someone must list affected products, and every organization must decide whether it matters to them.

Severity scoring also became more complicated. The Forum of Incident Response and Security Teams, which maintains the Common Vulnerability Scoring System, released version 4.0 in late 2023. For a period, different sources published scores under different versions, and the same flaw could carry two base scores that did not agree. A policy that says “critical means 9.0 or above” has to specify which version and which source it means.

Identification: the shared name for a flaw

A CVE identifier is the key that links a vendor advisory, a scanner finding, a patch, a threat report and a line in a software bill of materials. That bill is the ingredients list of components inside a piece of software. With that one code, a security analyst can follow a flaw from the vendor’s warning to the specific servers that carry it to the patch that fixes it.

Numbering authorities, including many large software vendors, assign identifiers under program rules. MITRE operated the program under the CISA contract, and by 2025 the network of numbering authorities exceeded 460 organizations, according to CISA. That spread is a strength: no single desk has to name every flaw in the world. But the rules, the central records and the coordination still ran through one contract.

Had identification stopped, existing records would have remained. New flaws would have lacked a common name. Vendors would have published under their own schemes, scanner vendors would have built mappings between them, and the same flaw could have appeared under several labels. Take a hospital whose network scanner reports one name, whose medical device supplier uses another and whose threat intelligence feed uses a third. Someone has to work out by hand that all three are the same problem. Multiply that by hundreds of flaws a month.

The damage would have built over weeks rather than hours, which is exactly why it is easy to underestimate. Nothing would have crashed on day one. Confusion would simply have crept into every report.

The second-order effects reach beyond the security operations center, the team that watches for attacks around the clock. Vendor security questionnaires, contract clauses that commit suppliers to patch critical CVEs within set periods, and software bills of materials all refer to flaws by CVE identifier. A gap in identification would have weakened procurement and vendor management language that most organizations never think to review. A clause that says “the supplier will remediate any critical CVE within 30 days” means little if new flaws stop receiving CVE numbers.

How an identifier is assigned

The assignment process explains where the program is strong and where it is brittle. When a researcher finds a flaw, they usually report it to the vendor. If the vendor is a CVE numbering authority, it reserves an identifier, works on a fix, and publishes a CVE record when the advisory goes out. If the vendor is not one, the report goes to a numbering authority with responsibility for that area, or to a last-resort authority. MITRE has filled that role for flaws nobody else covers.

The CVE record itself has a defined structure. The numbering authority that assigns the identifier writes the core content: a description, affected products and versions, and references. Other authorized data publishers, such as CISA, can add information in a separate section of the same record without overwriting the original. Under CISA’s published practice, when the numbering authority supplies a field, its data takes precedence over CISA’s additions.

That structure has a practical consequence. The quality of a CVE record depends heavily on the organization that assigned it. A large vendor with a mature product security team tends to publish complete records with scores and precise version ranges. A small open-source project may publish a one-line description. Enrichment exists largely to even out that difference.

What a lapse would have meant on the ground

Had new identifiers stopped, security teams would have fallen back on other names. Vendors issue their own advisory numbers, and code hosting platforms publish their own advisory identifiers for open-source packages. Teams would have needed an internal tracking number for each new flaw, mapped by hand to whatever names its sources used. Scanners would have detected some new flaws under vendor-specific checks, but reports, tickets and audit evidence would have lost their common key.

Organizations can prepare for that cheaply. Their ticketing and risk systems can allow a vulnerability to be recorded without a CVE identifier, with fields for the vendor advisory number and an internal identifier. That small design choice keeps the process working if the shared name is late, missing or disputed.

What identification means for each sector

For health systems, identification connects to medical device regulation. Since March 2023, section 524B of the Federal Food, Drug, and Cosmetic Act has applied to manufacturers of cyber devices. Their premarket submissions must include plans to monitor and address vulnerabilities, and a software bill of materials. Those bills of materials and the manufacturers’ advisories refer to flaws by CVE identifier. A hospital’s clinical engineering team relies on that shared name to connect a manufacturer’s notice to the devices on its floors.

For banks, identification runs through vendor management. Core processors, online banking platforms and payment software suppliers report flaws and fixes to client banks, usually by CVE identifier. For federal agencies, CISA’s directives and KEV catalog are keyed to CVE identifiers, so a gap in naming would reach compliance reporting directly. State and local governments that follow federal practice, or that receive support from the Multi-State Information Sharing and Analysis Center, feel the same dependency at one remove.

Enrichment: the data that makes a name useful

An identifier alone says little. Enrichment adds three things. The first is a severity score, usually a number from zero to ten that signals how bad the flaw could be. The others are the list of affected products and versions, and a weakness classification that describes what kind of mistake caused it. In the United States, much of this came from NIST’s National Vulnerability Database. Since early 2024, the NVD had struggled with a growing backlog of records awaiting analysis.

That backlog had already broken many patching policies before April 2025, often without anyone noticing. Consider a common rule: “remediate anything NVD rates critical within a set number of days.” It sounds rigorous. It fails silently when new records have no NVD score, because a flaw without a score never trips the rule. Teams that noticed had begun pulling scores from vendor advisories, CISA’s own enrichment work and commercial feeds. Teams that did not were applying their policy to a shrinking share of new vulnerabilities while their reports looked as tidy as ever.

Product data matters as much as scores. Without an accurate list of affected products and versions, a scanner cannot match a new record to the assets that carry it. Some flaws then go undetected in the environment even though they are known to the world. It is the equivalent of a recall notice that names the contaminant but not the brand.

The fix is to treat enrichment as a supply chain with several sources and a stated order of precedence. A policy can say that the vendor’s own severity rating governs, the NVD score applies when the vendor gives none, and the security team assigns a provisional rating when both are missing. That sentence takes an hour to write and closes a gap examiners and auditors are starting to notice.

Who supplies enrichment now

By April 2025, enrichment came from at least four kinds of source. Numbering authorities increasingly included their own severity scores and affected-version data in CVE records. CISA’s Vulnrichment work added decision points on exploitation, automation and technical impact for the flaws it analyzed, plus scores and weakness types for higher-risk ones. Vendors published their own advisories, often in the Common Security Advisory Framework, a machine-readable format standardized through OASIS. Commercial vulnerability intelligence providers maintained their own databases with independent analysis.

Each source has a characteristic weakness. Vendor scores can understate severity, since vendors have a reason to make their products look safer. CISA’s additions are selective by design. Commercial feeds vary in quality and are not free. The NVD offered a single, neutral, consistent source, which is why so many policies were written around it. Its backlog removed the convenience of that neutrality without removing the need for it.

Product data is the hardest part

Matching a flaw to an organization’s assets depends on product identifiers. The most common scheme, the Common Platform Enumeration, names a vendor, product and version in a structured string. Those strings are fiddly to create and easy to get wrong, and scanners rely on them to say “this server is affected.” CISA stopped adding them to its enrichment in December 2024. When the NVD fell behind, the identifiers for new flaws often arrived late or not at all.

Organizations can reduce that dependency in two ways. Some scanners and endpoint tools detect vulnerable software through vendor-specific checks rather than generic product identifiers. Software bills of materials, now common in medical devices and federal software purchases, let an organization match components directly. Neither approach is complete, but each removes some reliance on a single public catalog of product names.

Both depend on the organization’s own inventory. A software bill of materials helps only if the organization knows which products it runs, which versions are deployed and where. Many organizations find that their configuration management database and their scanner disagree about what exists. Reconciling the two is unglamorous work, and it pays off in every layer above it.

Scores are not risk

A base severity score describes how bad a flaw could be in a generic setting. It does not describe whether attackers are using it, whether the vulnerable feature is enabled, or whether the system is reachable. Policies that treat the base score as the measure of risk were fragile even before the NVD slowed down. The backlog exposed a fragility that already existed: the policy depended on a number that answered the wrong question, and then the number stopped arriving.

Prioritization: deciding what to fix first

The third layer belongs to each organization. It combines four things. The first is how severe the flaw is, and the second is whether attackers are actually exploiting it. The third is how exposed the affected machine is, whether it faces the internet or sits deep inside the network. The fourth is how important that machine is to the business. A flaw rated “high” on a public website that handles payments deserves more urgency than a “critical” flaw on a lab computer with no network connection.

CISA’s Known Exploited Vulnerabilities catalog, usually called the KEV catalog, has become a central input. It is a public list of flaws that attackers are known to be using in the real world. Federal civilian agencies must meet its deadlines under a binding operational directive, which is a mandatory instruction from CISA. Banks, health systems and state agencies use it voluntarily as the strongest public signal that a flaw is being used in attacks.

Prioritization inherits every weakness in the layers below it. If identification slows or enrichment thins out, the prioritization engine still produces a ranked list. It simply ranks incomplete data, and dashboards look healthy while coverage erodes. That is the most dangerous kind of failure: the one that does not look like a failure.

Other signals beside the KEV catalog

Two other public tools have grown in use. The Exploit Prediction Scoring System, maintained by FIRST, estimates the probability that a flaw will be exploited in the near future. The Stakeholder-Specific Vulnerability Categorization method, developed with Carnegie Mellon’s Software Engineering Institute and adopted by CISA, uses a decision tree rather than a score. It asks whether a flaw is being exploited, whether exploitation can be automated, what the technical impact is and what the affected system means to the mission.

Each signal trades something. The KEV catalog is authoritative but lags initial exploitation and covers a small share of all CVEs. Exploit prediction scores are broad but probabilistic, and they change daily, which complicates audit evidence. A decision tree is explainable but requires the organization to supply its own mission and exposure data. A strong prioritization rule usually combines them. KEV listing forces action, a high exploitation probability raises urgency, and the organization’s asset tiers decide among the rest.

How the rules differ by type of organization

Federal civilian agencies are bound by CISA’s Binding Operational Directive 22-01, issued in November 2021, which requires them to remediate KEV-listed flaws by the due dates CISA sets. Cloud providers authorized under FedRAMP work to remediation windows tied to risk levels in their continuous monitoring obligations. In both cases, the timelines assume the flaw has a name and a rating.

Banks are examined against their own policies and the Federal Financial Institutions Examination Council’s IT guidance, which expects risk-based patch management rather than fixed public deadlines. Those that handle payment cards must also meet PCI DSS, which requires the organization to rank vulnerabilities by risk and to install critical security patches within a month of release. New York–regulated institutions must meet the vulnerability management requirements of the state’s cybersecurity regulation. In each case the organization defines “critical,” which makes the choice of severity source part of its compliance position.

Health systems work under the HIPAA Security Rule, which requires risk analysis and risk management but historically has not set patch deadlines. HHS proposed a substantial update to the Security Rule in early 2025 that set out more explicit expectations, including on patching. State and local agencies vary widely. Systems handling criminal justice information must meet the FBI’s CJIS Security Policy, while many other systems follow state policy modeled on federal practice.

A useful control is a coverage metric: the share of new vulnerabilities in the environment that have a severity rating and an affected-asset match within a set number of days of publication. If that number drops, leaders know the lower layers are slipping, even when the headline “critical vulnerabilities open” figure looks fine.

Regulated organizations face a specific trap here. Examiners and auditors ask for evidence that critical vulnerabilities were remediated within policy timelines. If the policy is defined entirely by one external score and that score is missing, the organization cannot demonstrate compliance even when it acted correctly. Policies written around internal risk tiers, informed by several external sources and by the organization’s asset inventory, survive a disruption in any one source.

A 98 percent figure that meant less than it seemed

Suppose a regional bank with a few thousand employees has a security team that runs a scanning tool every night. The tool compares the software on every server and laptop against a database of known flaws, keyed by CVE number, and produces a list of findings. Each finding carries a severity score, pulled automatically from the NVD. The bank’s policy, approved by the board risk committee, says critical findings must be fixed within 15 days and high findings within 30.

Each quarter, the chief information security officer reports to the committee: 98 percent of critical findings closed on time. Internal audit samples the evidence and signs off. Everyone is comfortable.

Now suppose the enrichment layer slows down, as the NVD backlog did through 2024. New flaws arrive in the scanner with a CVE number but no score. The tool does not know whether they are critical, so they never appear in the “critical” bucket. The 98 percent figure stays steady, or even improves, because fewer items qualify. Meanwhile a flaw in the bank’s internet-facing remote access system, the kind attackers love, remains unscored and unprioritized.

Nobody in this story did anything wrong in the ordinary sense. The policy was followed to the letter. The problem was that the policy outsourced a key judgment to a single external source and never measured whether that source was still delivering.

Now give the same bank a better design. Its policy defines internal tiers such as “Tier 1: internet-facing or customer-data systems.” Severity comes from the vendor first, then the NVD, then a provisional rating by an analyst within two days. Anything on the KEV catalog jumps to the top regardless of score. The quarterly report includes a coverage line: what share of new flaws received a rating and an asset match within seven days. When that figure dips, the committee asks why. The bank would have spotted the backlog early, adjusted, and kept clean audit evidence the whole time.

What the committee should have asked for

The board risk committee in this example did nothing unusual. It received a single on-time percentage because that is what most vulnerability reports provide. A better report would add three lines without making the pack longer. The first is coverage: the share of new flaws rated and matched to assets within seven days. The second is exceptions: how many open flaws have no rating at all, and how old the oldest one is. The third is exposure: how many KEV-listed flaws exist on internet-facing systems, and for how long. Each of those numbers moves when a public source falters. The on-time percentage does not.

How an auditor would catch it

The failure in this example would not show up in a conventional audit test. Auditors typically sample findings that the scanner rated critical and check whether each was closed on time. That test only examines items that entered the critical bucket. A stronger test starts outside the tool. The auditor takes a sample of CVEs published in the period, including several KEV-listed ones, and asks the security team to show where each appears in the environment, how it was rated and when. Unrated items and missing matches surface immediately.

Internal audit teams at banks and health systems can add that test at modest cost. It turns the coverage question into evidence a board committee can read, and it gives the security team a reason to fix its data sources before an examiner asks.

Where the cost lands

When a known flaw stays unpatched, the bill arrives in four places: the budget, the audit file, the supplier contracts and the trust of customers.

Money. Unpatched, known flaws are among the most common ways attackers get in. A single missed patch on an exposed system can lead to ransomware, where criminals lock an organization’s files and demand payment. Recovery costs, lost revenue and legal bills then dwarf the cost of the patch.

Regulators and auditors. In banking, health care and government, examiners routinely test patching against policy. A policy that cannot be evidenced when a public source wobbles is a finding waiting to happen.

Contracts and suppliers. Many supplier obligations are written in CVE language. If those obligations stop applying to new flaws without notice, the organization has lost bargaining power it thought it had in its contracts, without anyone signing anything new.

Reputation and customers. After a breach, the first public question is usually “was this a known flaw, and why was it not fixed?” “Our external score was missing” is not an answer that reassures patients, customers or citizens.

Across all three layers, the test is the same: whether the program could still identify, enrich and prioritize if one public source fell silent for a month. Answering it requires tools that ingest vendor advisories directly, a written precedence order for severity, and an asset inventory accurate enough that exposure as well as severity drives the queue.

The exercise also clarifies ownership. Identification belongs to a public program, enrichment to a mix of public and vendor sources, and prioritization to the organization itself. Only the third is fully in its control. A program that invests there, in asset inventory, exposure mapping and exploitation intelligence, depends least on the first two.

Contract language that survives a gap

Supplier obligations can be written so they do not depend on one public program. A patch clause can refer to any security vulnerability the supplier knows of or that is publicly disclosed, whether or not it has a CVE identifier. Severity can be the supplier’s rating or the customer’s, whichever is higher. The supplier can be required to provide a software bill of materials and to state, for each relevant new flaw, whether its product is actually affected. Those statements are often called VEX, for Vulnerability Exploitability eXchange.

Counsel and procurement should check that the clause still gives clear deadlines and remedies. A provision that is broad but vague can be harder to enforce than a narrow one. The aim is to keep the obligation tied to real risk rather than to the presence of a particular label.

The case against multi-source policies

Some security leaders argue that this approach is overbuilt. Their arguments deserve a fair hearing.

The first is that commercial scanners maintain their own vulnerability databases, so a slow NVD barely affects them. For many leading tools that is partly true. But those databases are still keyed to CVE identifiers, their coverage of niche products varies, and the policy documents and audit evidence often still name NVD scores. The tool may cope while the policy breaks.

The second is that multiple sources produce conflicting scores and invite gaming. An analyst under pressure can choose the lowest available rating and push a flaw outside the policy window. This risk is real. The answer is a precedence order fixed in advance and applied automatically, with any manual override logged and reviewed. A defined order prevents cherry-picking rather than enabling it.

The third is that small organizations, such as a community bank, a rural hospital or a small county, cannot run this program. They usually cannot. They can, however, require it of the managed security provider or software vendor that runs scanning for them. The five questions at the end of this article work as contract and due diligence questions as well as internal ones.

The arguments do justify restraint in one respect. An organization should not build its own enrichment operation. The goal is to know which sources it uses, what happens when one fails, and how it would show an examiner that it noticed.

Features of a resilient program

A resilient vulnerability program has a few recognizable features:

• The public sources are on the dependency register. The CVE program, the NVD and the KEV catalog appear alongside cloud providers and payment processors as third parties the organization relies on, each with a named internal owner who watches for changes.
• Severity has a written pecking order. The policy names which source wins, what happens when sources disagree and what happens when there is no score at all.
• The asset inventory is trusted. The organization knows what it owns, where it sits and how important it is. Without that, no amount of external data helps.
• Coverage is measured, not assumed. Reports show how much of the incoming flow was rated and matched, as well as how much of the rated flow was fixed.
• Tools have more than one feed. Scanners and patching systems can read vendor advisories directly rather than relying on one central database.
• Machine-readable advisories are ingested. Where key suppliers publish in the Common Security Advisory Framework, the organization’s tools read those advisories automatically.
• Component data comes from the supplier. Software bills of materials for critical products, including medical devices and core banking software, are on file and matched against new flaws.

Weak programs show the mirror image:

• Writing policy around a single external score, so that the policy silently shrinks when the score is late.
• Reporting only “percent closed on time,” which looks better when less data arrives.
• Treating supplier patch clauses as boilerplate and never checking which scoring system they assume.
• Assuming that because the scare in April 2025 passed quickly, the dependency has gone away.

Where the patching evidence leans on outside sources

These need no technical knowledge to ask, and the answers reveal a great deal:

1. Where do our vulnerability names, severity scores and product details come from today, and what happens if one of those sources stops for a month?
2. Does our patching policy say which severity source wins, and what we do when there is no score?
3. What share of new vulnerabilities in our environment got a rating and were matched to our systems within a week of being published, and is that number going up or down?
4. Which of our supplier contracts define patch obligations by CVE number or by an outside score, and would they still work if that score were missing?
5. If an examiner asked us tomorrow to prove a critical flaw was fixed on time, what evidence would we show, and does it depend on any single outside source?

The April 2025 scare lasted about a day. The questions it raised are worth a standing place on the risk committee agenda, because the plumbing under every patching policy is public, shared and, as that week showed, more fragile than it looks.

With hindsight

The program did not lapse. In the months that followed, the agencies involved moved from crisis management to longer-term thinking about how the system should work.

In September 2025, CISA published a strategic vision calling CVE a public good that must be led in a conflict-free, vendor-neutral way. It described a shift from a “growth era” of more than 460 numbering authorities to a “quality era” focused on data completeness. The priority had shifted from getting more organizations naming flaws to making sure each record was complete and reliable. In September 2026, CISA followed with a white paper on how to establish and measure that quality.

Europe, meanwhile, built a second reference point. ENISA, the European Union’s cybersecurity agency, launched the European Vulnerability Database in May 2025 under the NIS2 Directive, the EU’s main cybersecurity law. That added a second reference service, which gives organizations with European operations another place to look, and gives everyone a reminder that the world no longer has to rely on a single source.

European rules added a further reason to track vulnerabilities by shared identifiers. The EU Cyber Resilience Act, in force since December 2024, requires manufacturers of products with digital elements to report actively exploited vulnerabilities, with that obligation applying from September 2026. Reporting runs through a single platform managed by ENISA. Banks, health systems and agencies that buy from those manufacturers should expect more structured vulnerability information from suppliers, and should be ready to use it.

Enrichment proved the weaker layer, just as the backlog in 2024 had hinted. On April 15, 2026, a year to the day after MITRE’s warning, NIST said the NVD would stop trying to enrich every CVE. It would prioritize CVEs in CISA’s KEV catalog, with a goal of enriching those within one business day. It would also prioritize CVEs in software the federal government uses and in critical software as defined under Executive Order 14028. Other CVEs would stay in the database but be labeled lowest priority, and users could ask NIST by email to enrich a specific record. Records published before March 1, 2026 and still waiting moved to “not scheduled,” meaning they may never receive NVD analysis.

Two details mattered as much as the headline. NIST said it would no longer routinely add its own severity score when the numbering authority had already supplied one. That made the vendor’s score the default for many records, which is exactly the source a precedence order needs to anticipate. NIST also published the scale of the problem. Submissions had risen 263 percent from 2020 to 2025, and the NVD had enriched nearly 42,000 CVEs in 2025, 45 percent more than in any earlier year. Submissions in the first quarter of 2026 were nearly a third higher than a year before. The backlog was driven largely by volume.

The following months showed the NVD becoming more of an aggregator. In late April 2026, NIST corrected about 4,500 CVSS version 4.0 scores that it said had been calculated too high. For organizations that pull scores automatically, the correction was a reminder that enrichment errors also spread without notice. In June 2026 the NVD added CISA’s exploitation and impact decision points and the numbering authorities’ affected-product data to its feeds and interfaces.

The sponsor itself changed during this period. CISA went through substantial staff reductions in 2025, which led many in the industry to watch its commitments to shared programs closely. The CVE program kept operating, and CISA’s 2025 vision and 2026 white paper both described it as a long-term federal priority. The contract scare of April 2025 did not recur in the same form, but the governance question its founders raised has not been settled in public.

That decision sorted organizations into two groups. Programs that had already written a precedence order for severity sources absorbed the change: they simply leaned more on vendor ratings and their own provisional scores. Those keyed to NVD scores alone had to rewrite policy, retrain staff and explain to auditors why their evidence had gaps.

Public security infrastructure is valuable but not guaranteed. It is run by people, funded by contracts and shaped by priorities that can change. The organizations that came through these two years most smoothly were not the ones that predicted each twist. They were the ones that had designed their policies so that no single outside source could switch off their judgment. They also kept their own asset knowledge strong enough to decide for themselves what mattered most.