Is "the NVD No Longer Scoring Vulnerabilities" Really Cause for Panic?

The NVD scaled back its own scoring

In April 2026, the NVD (National Vulnerability Database), run by the U.S. NIST, changed how it operates. It now prioritizes vulnerabilities that are known to be exploited and, for the vast majority of the rest, no longer attaches its own severity score (CVSS) or affected-product identifiers (CPE) (NIST announcement).

A note on terms: CVSS (Common Vulnerability Scoring System) is the international standard for expressing a vulnerability's severity on a 0–10 scale. The reason is simple—there are too many CVEs. Published CVEs grew 263% from 2020 to 2025, and scoring every single one uniformly hit its limit. And the surge is only accelerating with the spread of AI—as AI gets used for code analysis and vulnerability hunting, the sheer number of discoveries and reports is spiking.

"We've always acted on the score, and now the score is disappearing"—at first glance it sounds serious. But look closely at the details, and the story is different.

In fact, the ones that truly matter still get scored

Read the NVD's new policy carefully, and you'll see three categories are prioritized for enrichment (NIST announcement):

• Vulnerabilities in the CISA KEV catalog (i.e., actively exploited): the goal is to score these within one business day
• Vulnerabilities in software used by the federal government
• Vulnerabilities in critical software as defined by Executive Order 14028

In other words, NIST simply shifted to scoring "what is dangerous right now" first and most thoroughly.

There's another key point worth noting: it's the scorer that changed, not the scores. Historically, the CVSS for CVEs across the board was assigned mainly by the NVD. But now the NVD has scaled back that role and defers to the score provided by the issuing CNA (CVE Numbering Authority—the organization that assigns the CVE ID, and often a product vendor). NIST itself states plainly that "when a CNA has already provided a score, we will no longer routinely provide a separate one" (NIST announcement). The scoring baton has simply passed from the NVD to the vendors—the scores themselves don't vanish. In fact, even as the NVD's own scoring narrowed through 2025, CVSS coverage across published CVEs stayed above 90%.

So what stops getting scored is mainly the low-impact "long tail." Vulnerabilities that truly bite get scored first once exploitation begins, and those in major products are already scored by their vendors. The structure of "the ones that matter get scored" hasn't changed.

Adding more sources doesn't change the root cause

"If the NVD falls short, just fill the gap with JVN (Japan's vulnerability database), the EU's EUVD (run by ENISA), or another vulnerability database"—it's tempting to think that way. But it doesn't solve the root problem.

Vulnerabilities are flooding in because the spread of AI has made the sheer number of discoveries and reports explode. Unless that "discovery backdrop" changes, every source faces the same flood. Adding more references doesn't shrink the total volume that no one can finish scoring—it tends to just mix in data of uneven accuracy and freshness. The problem isn't "how many sources you have."

So the real question isn't "is there a score?"

Here's the shift in thinking. If you can get a score, how do you use it? The answer: a score is an entry point, not a conclusion.

CVSS tells you how dangerous it would be if exploited (severity). As an entry point for gauging danger, it's still useful—now and going forward. For prioritization, we combine it with other signals:

• Exploitation probability (EPSS) — is it likely to be targeted? (see What is EPSS)
• Actively exploited? (KEV) — is it already being used in attacks? (see The KEV Catalog)
• Business impact — how important is that asset to your organization? (see Business Impact Score)

But no matter how many of these you combine, all you learn is "how dangerous it looks in theory." Whether an attack actually succeeds in your own environment lies outside any score.

The conclusion comes from "proof" — a two-step approach beyond the score

So we add one more step: confirming whether an attack actually succeeds.

But validation has a pitfall. It takes effort and cost, and reproducing an attack carelessly can take down or damage critical IT assets. You can't fire live rounds at a production system. That's exactly why how you confirm is decisive.

PentaTrail solves this with AI Deep Scan. AI Deep Scan confirms whether a discovered vulnerability can really be exploited, remotely and non-destructively (without changing or deleting data). Tailored to the target's context, the AI generates validation code and runs it remotely and non-destructively. The key point: you can confirm "does it land?" without breaking production assets.

And we don't validate everything. We validate only the "top" items already prioritized by the entry-point scores and signals.

• Confirm the top vulnerabilities; those proven to be "exploitable" are pushed even higher in priority
• Those that are "not exploitable" (already patched or mitigated by configuration) move to monitoring
• Items that sank to the bottom, and those that can't be confirmed via remote, non-destructive HTTP (require destructive actions, sit behind authentication, etc.), are deliberately not validated

This is a two-step approach: rank by score, then verify only the top non-destructively (see Deep Scan Vulnerability Validation). "Confirm whether it lands, without breaking anything"—a practical way to defend the attack surface in an age of sheer volume.

How PentaTrail is designed

PentaTrail's CTEM (Continuous Threat Exposure Management) is built on this two-step approach.

• Use scores and signals as the entry point to prioritize — TER bands (S/A/B/C/D) are computed from CVSS + EPSS + KEV + business impact (see What is TER)
• Verify only the top with AI Deep Scan — narrowing to high-priority vulnerabilities, it confirms remotely and non-destructively whether an attack succeeds and elevates the ones that do. The design avoids the risk of halting or breaking production assets.
• It runs under your control — because active confirmation matters, control matters too. You decide whether to enable it, and you can pause and resume at any time.
• No validation cost on the long tail — resources concentrate on the top, where something is most likely to land.

Even as the NVD scales back its own scoring, the vulnerabilities that matter still get scored. So a design that "uses scores as an entry point" keeps working. What sets you apart is what happens beyond that entry point—can you turn theory into measurement without breaking critical assets?

Conclusion

There's no need to panic at the scoring gap and go hunting for scores elsewhere—because the vulnerabilities that count are still scored. What you need is the discipline to use scores correctly as an entry point and, beyond it, to prove "can this actually be exploited?" without breaking your assets.

Is your external attack surface "ranked correctly by score, with the top verified through non-destructive proof?" Start your 14-day free trial. For the bigger picture, see What is CTEM? too.

---

Sources: The three prioritized categories, the one-business-day KEV goal, and the deferral to CNA scoring are from the NIST announcement (April 2026). "CVSS coverage stayed above 90% through 2025 even as the NVD's own enrichment narrowed" is based on Recorded Future's analysis.