Since mid-February 2024, NIST's National Vulnerability Database (NVD) has added CVSS scores, CWE classifications and CPE product data to only a small share of newly published CVEs. The result is a growing backlog of records with none of that enrichment. For your vulnerability program, this means two things. Tools that match software against NVD's CPE data may miss newer vulnerabilities, and many findings arrive with no severity score. The answer is to stop relying on a single source: use the data in CVE records themselves, read vendor advisories, and put CISA's KEV catalog and FIRST's EPSS scores at the front of your prioritization.
What happened to the NVD?
To understand the problem, it helps to separate two things that often get blurred.
The CVE Program assigns CVE IDs and publishes the basic vulnerability record. That work is done by CVE Numbering Authorities (CNAs), such as software vendors and research organizations, and it hasn't stopped.
The NVD, run by NIST, takes those records and enriches them. NIST analysts add their own CVSS base score, map the weakness to a CWE category, and write CPE "applicability statements" that describe exactly which products and versions are affected. Many security tools depend on that enrichment rather than on the raw CVE record.
In February 2024, NIST sharply cut back that enrichment. New CVEs kept appearing in the NVD, but many now sit with a status of "Awaiting Analysis" and no NIST score, CWE mapping or CPE data.
What has NIST said about the backlog?
NIST's public statements so far have been brief. Here's what it has said publicly as of early May 2024:
| When | What NIST said |
|---|---|
| February 2024 | A notice on the NVD website said NIST was working to establish a consortium to improve the NVD program, and that users would see temporary delays in analysis during the transition. |
| By early April 2024 | NIST described "a growing backlog of vulnerabilities submitted to the NVD and requiring analysis," caused by "a variety of factors, including an increase in software and, therefore, vulnerabilities, as well as a change in interagency support." |
| Same statement | NIST said it was prioritizing analysis of the most significant vulnerabilities, working with agency partners to bring on more support, and had reassigned additional NIST staff to the work. |
| Same statement | For the longer term, NIST said it was looking at a consortium of industry, government and other stakeholder organizations to collaborate on research to improve the NVD. |
NIST has also said it remains committed to supporting and managing the NVD. As of this writing, we haven't seen a firm public date for when normal enrichment will resume or the backlog will clear. Plan on the gap lasting a while.
What does NVD enrichment actually provide?
It's worth being precise about what's missing, because each piece feeds a different part of your process.
| Enrichment | What tools use it for | What happens without it |
|---|---|---|
| CPE applicability statements | Matching installed software and versions to vulnerabilities | Some tools can't tell that a CVE affects you |
| NIST CVSS base score | Severity ratings, sorting, remediation deadlines | Findings appear unscored or fall back to a default |
| CWE mapping | Weakness trends, secure development reporting | Less insight into root causes |
| Reference tags | Spotting patches, advisories and exploit references quickly | More manual reading per CVE |
The CVE record usually still contains a description and references. Many CNAs also include affected product and version details, and some include their own CVSS score. What's missing is NIST's standardized layer on top.
How does the backlog affect your vulnerability program?
Scanners that rely on CPE matching may miss vulnerabilities
This is the most serious impact because it's silent. If a scanner or software composition analysis tool decides whether you're affected by comparing installed software against NVD's CPE data, a CVE with no CPE data may never produce a finding. There's no error message. The vulnerability simply doesn't show up.
Tools vary a lot here. Some write their own detection logic or use vendor and ecosystem data. Others lean heavily on NVD. You need to know which kind you have.
Findings without severity scores
When a finding does appear, it may lack a CVSS score. Depending on the tool, it could show as "unknown," fall to the bottom of a sorted list, or be excluded from reports filtered by severity. An unscored critical vulnerability on an internet-facing system can end up behind a hundred scored medium findings.
Reports that look better than reality
Dashboards that count new high and critical vulnerabilities may show an encouraging drop since February. Some of that drop may just be missing data. Be careful about presenting that trend to leadership as an improvement.
Policies tied to NVD severity
If your remediation deadlines say something like "critical per NVD within 15 days," those rules no longer cover every new vulnerability. Auditors may ask how you handled findings that had no NVD score, so it's better to have an answer ready.
How can you keep your program working?
Find out how your tools get their data
Ask your scanner and software composition analysis providers direct questions. Do they depend on NVD CPE data to detect vulnerabilities? What do they do for CVEs that NVD hasn't analyzed? Which other sources do they use? The answers tell you where your blind spots are.
Then check your own data. Count how many open findings have no CVSS score, and look at when their CVEs were published. A cluster of unscored findings after mid-February is the backlog showing up in your environment.
Use CVE records and CNA-provided scores
The CVE record, available from CVE.org and the CVE Program's public record repository, is published whether or not NVD has analyzed it. Many CNAs, especially larger software vendors, include a CVSS vector and a list of affected products and versions. Depending on the CNA, that score may be CVSS v3.1 or the newer v4.0, so record which version you're using.
CNA scores are a reasonable stand-in for NIST's. The CNA usually knows the product best. Just be aware that scoring practice varies between CNAs, and for your most important systems it's worth sanity-checking a score against the vendor's own advisory.
Go straight to vendor advisories
For the platforms you depend on most, such as operating systems, hypervisors, network and remote access appliances, and core business applications, the vendor's security advisory is the primary source anyway. It tells you which versions are affected, which fixes to apply and, often, a severity rating. Some vendors also publish machine-readable advisories in the CSAF format, which can be ingested automatically.
A short list of vendor advisory pages, checked on a schedule, covers a large share of the risk in most small and mid-sized environments.
Put KEV and EPSS at the front
CISA's Known Exploited Vulnerabilities (KEV) catalog doesn't depend on NVD enrichment. It lists CVEs with reliable evidence of active exploitation, along with the required action. A KEV match on your systems should be fixed first, with or without an NVD score.
FIRST's Exploit Prediction Scoring System (EPSS) still publishes daily probabilities of exploitation activity for published CVEs. EPSS draws on some of the same public data as other tools, so scores for unenriched CVEs may be based on less information. It's still a useful signal for ordering the long tail of findings that aren't in KEV.
Add ecosystem sources for open-source dependencies
For open-source libraries, ecosystem-specific databases often cover vulnerabilities by package name and version, with no CPE required. The open-source OSV project aggregates many of them in a common format. If your developers use dependency scanning, check whether it can use these sources.
Treat "unscored" as its own state
Don't let missing data default to low priority. Add an explicit rule to your process, such as:
- Any unscored finding that matches a KEV entry is handled as your highest priority.
- Any unscored finding on an internet-facing or business-critical system gets triaged within a few days, using the CNA score or vendor advisory to assign a severity.
- Everything else unscored is reviewed weekly until a score is available from any trusted source.
For the few findings that matter most and have no score anywhere, score them yourself with FIRST's CVSS calculator. It takes minutes, and it gives you a documented basis for the decision.
Frequently asked questions
Is the NVD shutting down?
NIST has said it is committed to continuing to support and manage the NVD and is working on longer-term improvements, including an industry and government consortium. The problem right now is the pace of analysis, not the database's existence.
Can we trust CNA-provided CVSS scores?
Generally, yes, as a working input. CNAs are often the product vendor and know the affected code best. Scoring practices do differ, though, so compare with the vendor advisory for critical systems and don't mix CNA and NIST scores without noting which is which.
Do we need to change our remediation SLAs?
Probably not the timelines themselves, but the triggers. Write policies around severity from any trusted source plus exploitation evidence, rather than NVD severity alone. That makes them more resilient whatever happens next with the NVD.
Should we stop using the NVD?
No. It's still a valuable source, and analyzed records are as useful as ever. Just treat it as one source among several instead of the single source of truth.
Next steps
- Ask each tool provider whether detection depends on NVD CPE data, and what they do for unanalyzed CVEs.
- Count your unscored findings and check how many sit on exposed or critical systems.
- Pull CVSS scores and affected versions from CVE records and vendor advisories when NVD data is missing.
- Keep KEV matches at the top of the queue and use EPSS to order the rest.
- Update policies so that "no NVD score" never means "low priority."