In April 2026, the National Vulnerability Database (NVD), run by NIST, changed how it operates: it prioritizes vulnerabilities with confirmed exploitation and will not attach its own severity score (CVSS) to the large majority of the rest.
"We've been working from scores, and now the scores are going away" is how it sounds. The substance is different, and it is worth walking through.
01 / Scoring didn't stop; the priority order changed
Read the announcement and three prioritized categories come out of it. The first is vulnerabilities with confirmed real-world exploitation.

Figure 1: The three prioritized categories (NIST's announcement)
Deep dive: a reordering toward what is dangerous now
For vulnerabilities that reach KEV, the stated target is scoring within one business day. The shift is from scoring everything thinly and evenly to concentrating effort where the danger is. The driver is the continuing growth in CVE volume; our own measurements of that scale are in the CVSS, EPSS and KEV post.
02 / The scoring work moved from NVD to the issuers
Historically most CVSS values across the CVE corpus came from NVD. That role has been narrowed in favour of scores supplied by the organizations that assign CVE identifiers. Most of those are product vendors.

Figure 2: The author of the score changed; the score does not disappear
Deep dive: no duplicate scoring, stated explicitly
NIST states in the announcement that where an assigning organization has already scored a CVE, it will not add a duplicate score of its own. What loses a score is mostly the low-impact long tail.
03 / Adding more sources doesn't drain the flood
It is tempting to think other national or regional databases can fill the gap, but what is growing is the volume of discovery and reporting itself. More places to look does not reduce the amount that cannot be scored.

Figure 3: The problem is not the number of sources
Deep dive: mixing them makes handling harder
Each source scores at a different granularity and refreshes on a different cadence, so simply adding them together spreads out both precision and freshness. Designing how you use the scores you already have does more than collecting more of them.
04 / A score is an entry point, not a conclusion
CVSS tells you how dangerous something would be if exploited, and that is where it stops. Add exploitation probability, exploitation history and asset weight, and what you still have is theoretical danger.

Figure 4: Combined, they still stop short of the real answer
Deep dive: the signals used at the entrance
Exploitation probability comes from EPSS, exploitation history from KEV, and asset weight from the Business Impact Score. Ordering by that combination is what produces TER bands.
05 / The conclusion comes from proving the top of the list without breaking anything
Proving everything costs more than it returns, and reproducing an attack carelessly can take an asset down. So only the top of the ordered list is checked, remotely and non-destructively.

Figure 5: Order first, then verify only the top
Deep dive: some things are deliberately left unproven
Findings that sank down the order, and findings that cannot be checked remotely and non-destructively (those needing destructive operations, or sitting behind credentials), are excluded from validation. It is a deliberate line that concentrates resources where a hit is likely; the mechanism is in Validating vulnerabilities with AI.
Checking whether your attack surface is ordered correctly and its top verified non-destructively is free to try for 14 days.
Appendix: what the announcement says, and where validation stops
Table 1: claims used above, and their sources
| Claim |
Source |
| The three prioritized categories, and the one-business-day target for KEV-listed items |
NIST's announcement (April 2026) |
| Deferring to scores from assigning organizations, and not duplicating them |
As above |
| CVSS coverage above 90% in 2025 despite reduced in-house scoring |
A figure from a commercial research firm's tally; no public link is given for it |
Table 2: what is and isn't validated
| Treatment |
Scope |
| Validated |
The top of the ordered list, where remote non-destructive checking is possible |
| Not validated |
Findings that sank down the order |
| Not validated |
Findings needing destructive operations, or sitting behind credentials |
Table 3: what happens after validation
| Outcome |
What follows |
| Exploitable |
Priority is raised further |
| Not exploitable |
Moves to watch |
Because this step actively probes, whether it is enabled is the customer's decision, and execution can be paused and resumed at any time.
There is no need to panic at the gaps and go hunting for scores elsewhere. What matters gets scored, so using the score properly as an entry point — and then proving the rest without breaking your own assets — is the discipline that pays.
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get StartedSee pricing/Compare and choose