Your Vulnerability Coverage Gap Just Expanded

For two decades, the NVD (National Vulnerability Database) served as the de facto foundation of vulnerability management. Scanners, SIEMs, patch tools, compliance frameworks, all relied on the assumption that when a CVE appeared in NVD, NIST's analysts would promptly add the severity scores, product version mappings, and contextual metadata that make a raw CVE ID actually useful.

On April 15, 2026, that assumption officially stopped being reliable.

NIST announced that the NVD is shifting to a risk-based enrichment model. Most new CVEs entering the database will no longer receive NIST-added CVSS score, no CPE product mapping, and no independent analysis by default. For organizations whose vulnerability workflows depend on NVD-enriched data, this creates a real and growing coverage problem. For security product developers and vendors who embed that data into their tools, it raises an even more pointed question: what exactly is your feed telling you now?

According to NIST’s own announcement, CVE submissions increased 263% between 2020 and 2025, and submissions in the first quarter of 2026 were already running nearly one-third higher than the same period a year earlier.

NIST enriched nearly 42,000 CVEs in 2025, a 45% increase from any prior year. But this increased productivity has not been enough to keep up with growing submissions, resulting in a formalized triage system.

Starting April 15, 2026, NIST will only enrich vulnerabilities that appear in CISA's KVE (Known Exploited Vulnerabilities) catalog, software used by the federal government, or software designated as critical under Executive Order 14028. Everything else will be listed in the NVD but without NIST-added enrichment and will not be immediately processed.

Consequently, nearly 300,000 backlogged CVEs published before March 1, 2026 have been moved into a "Not Scheduled" category wholesale.

For CVEs falling outside NIST's priority criteria going forward, severity scores will now come from whatever was self-reported by the CVE Numbering Authority, often the vendor of the affected software, rather than from an independent NIST analysis. NIST will also stop recalculating severity scores when a CNA has already provided one.

Every major vulnerability scanner, every SIEM correlation rule, every third-party risk score, and every regulatory compliance framework from PCI DSS to FedRAMP depends on the NVD enrichment pipeline.

With the update, that pipeline has now formally narrowed, leading to potentially dangerous CVEs not being catalogued as such, or discovered in due time.

There's an additional acceleration factor worth understanding, as the reduction in enrichment is colliding with the rapid proliferation of AI-assisted threat discovery.

Advanced AI models and coding tools are significantly lowering the barrier for identifying exploitable weaknesses and complex attack paths in applications, driving a spike in CVE disclosures. In February 2026, the Forum of Incident Response and Security Teams (FIRST) forecast a record-breaking 50,000 additional CVEs to be reported in 2026. Current enrichment infrastructure is not equipped to handle this volume at previous quality levels.

NVD's own documentation describes product identification as a fundamental part of enrichment because it lets consumers programmatically check whether a known vulnerability affects products in their environment.

If CPE mappings are absent, incomplete, or delayed, tools that rely primarily on CPE matching may fail to surface the match, surface it late.

Security product vendors are among the most affected, since their products often depend on CPE matching, and CVE enrichment. Patch management, endpoint protection, network access control, and asset management tools rely on accurate vulnerability intelligence to determine what is affected, how severe the issue is, and what action should be taken next.

For teams building new security products, starting with NVD alone means building on a foundation where key gaps may already exist: limited zero-day coverage, missing enrichment for a growing share of CVEs, and update cycles that may struggle to keep pace with AI-speed vulnerability discovery and exploitation.

For teams that already have patching or remediation capabilities, the risk is different but just as important. A remediation engine is only as effective as the vulnerability intelligence it receives. If that intelligence is incomplete, delayed, or overly dependent on NVD-derived enrichment, downstream workflows may miss affected products, deprioritize unknown-severity vulnerabilities, or fail to act before exposure increases.

If those products inherit NVD's blind spots, those blind spots could be inherited by every downstream customer.

That is the gap OESIS Framework Vulnerability Assessment was designed to address: helping security product teams strengthen vulnerability intelligence without relying on NVD enrichment alone.

Detection identifies what is vulnerable. Remediation fixes it. Together, they help close the risk loop as much as possible. OESIS Vulnerability Assessment handles detection and prioritization. OESIS Patch Management is available for teams that want both capabilities under one framework:

• Detection: Vulnerable applications, version-matched, OPSWAT Score-ranked, and KEV-flagged
• Prioritization: OPSWAT Score helps surface what to fix first, based on real-world exploitation signals
• Remediation: Your existing pipeline can act on the OESIS output — or OESIS Patch Management can patch, enforce versions, or block access directly
• Verification: OESIS re-scans post-fix to help confirm the endpoint is clean before access is restored

Detection without remediation is a report. Detection with remediation is a resolved risk. OESIS aims to give your product both, helping close detection and remediation loops more quickly to better match AI-speed threats.