As of April 15, NIST is changing how it handles CVEs in the NVD. The new approach is risk-based: every submission still lands in the NVD, but only a subset will get the full analysis and enrichment treatment going forward:
- CVEs in CISA’s Known Exploited Vulnerabilities (KEV) catalog
- CVEs in software the federal government uses
- CVEs in “critical software” as defined by Executive Order 14028
Everything else — including the existing backlog — gets marked “Not Scheduled.” NIST is also dropping its own severity scoring for most CVEs, to “reduce duplication of effort.” The full breakdown is on the NVD process page.
The rationale is reasonable — CVE volume has exploded, and central triage at that scale was never going to hold forever. But in practice, the single source a lot of security and network teams have been leaning on for enrichment is about to get a whole lot thinner. That’s worth pausing on.
The hot take
Here’s a line straight out of our own documentation FAQ:
“We use the NIST National Vulnerability Database (NVD) as the source of data. But we have observed many data quality issues in this database and have done a lot of data cleaning over time. In addition, we augment the data with detailed advisories published by some of the vendors to provide more detailed information or improve quality of the data.”
Think about that for a minute. We wrote that long before this latest NIST shift — because the importance of diversifying your vuln data sources was already obvious to anyone trying to operationalize CVE data at scale.
In our case, we augment what we get from the NIST NVD with CVE information straight from the horse’s mouth — the network device vendors themselves. That’s indispensable when you need the nitty-gritty details of a weakness: which specific platform, which software train, which feature or config knob actually exposes you. A vendor advisory will tell you “this only affects devices with feature X enabled on release Y.” An NVD entry, on a good day, might not.
What this means for network and security teams
The gap between “there’s a CVE” and “is this actually a problem on my network?” just got wider. KEV tells you what’s being exploited in the wild — a small, vital slice. But everything marked “Not Scheduled” still exists, still ships in your gear, and still needs a decision. Three takeaways: don’t treat NVD as the single source of truth; pull directly from vendor PSIRTs (Cisco, Juniper, Palo Alto, Arista, F5) where you can; and correlate vuln data with your actual network state, because a CVE on a device where the vulnerable feature isn’t even enabled is noise.
Where Forward Networks helps
This is exactly the problem Forward was built for. We ingest NVD, clean it, and enrich it with vendor advisories so the CVE data you’re acting on reflects what’s actually running in your environment — down to platform, software version, and configuration. Understanding your network model enables us to answer the question that matters: “Is this exposed, and from where?”
NIST narrowing its scope isn’t a crisis — but it is a nudge. If your vulnerability program was quietly over-indexed on one source, now’s a good time to diversify.
