# NIST to Phase Out Severity Ratings for Lower-Priority Vulnerabilities Amid Volume Surge


The National Institute of Standards and Technology (NIST) has announced a significant shift in how it manages vulnerability assessments, confirming that it will cease assigning severity scores to vulnerabilities deemed non-critical or lower-priority in the coming months. The decision comes in response to an unprecedented surge in vulnerability submissions—a volume increase that has strained NIST's resources and forced a difficult triage decision about where to focus its efforts.


## The Immediate Impact


NIST's vulnerability tracking system currently processes thousands of submissions annually, with the Common Vulnerabilities and Exposures (CVE) program serving as the authoritative database for all publicly disclosed security flaws. The organization has long assigned CVSS (Common Vulnerability Scoring System) severity ratings to these entries, helping organizations worldwide prioritize patching efforts. Under the new policy, however, NIST will no longer rate vulnerabilities classified as low or medium severity, effectively redirecting computational resources away from minor issues toward critical and high-severity flaws.


The shift represents a pragmatic but consequential trade-off: faster processing of the most dangerous vulnerabilities at the expense of granular threat intelligence for lower-impact flaws. For security teams relying on CVSS scores to inform patch management strategies, this creates an immediate challenge—organizations will need alternative methods to evaluate and prioritize non-critical vulnerabilities.


## Background and Context


To understand why NIST made this decision, it helps to understand the scale of the problem. The vulnerability landscape has exploded in recent years, driven by:


  • Increased security research: More ethical hackers, bug bounty programs, and automated vulnerability scanners mean more flaws get discovered
  • More complex software: Modern applications have exponentially larger codebases with more potential attack surfaces
  • Supply chain risks: Each dependency in a project introduces new vectors, multiplying vulnerability counts
  • Regulatory compliance: Organizations now actively search for vulnerabilities to meet compliance requirements

  • In 2020, fewer than 18,000 CVE entries were published. By 2023, that number had grown to over 28,000 annually. Projections suggest 2024-2026 will see even steeper increases.


    CVSS (Common Vulnerability Scoring System) was designed decades ago when threat volumes were manageable. The system uses a numerical scale (0-10) to indicate severity, helping teams understand whether a vulnerability deserves immediate patching or can wait. NIST's CVSS scoring team has become a bottleneck—the organization cannot keep pace with submissions.


    ## Technical Details: What's Changing


    NIST's CVE program will implement a three-tier system going forward:


    | Vulnerability Tier | CVSS Scoring | Timeline | Priority |

    |-------------------|--------------|----------|----------|

    | Critical (CVSS 9.0-10.0) | Assigned immediately | Days | Highest priority |

    | High (CVSS 7.0-8.9) | Assigned within 2 weeks | 2 weeks | High priority |

    | Medium & Below | Score deferred or not assigned | On request | Lower priority |


    This means organizations will receive official severity assessments only for the most dangerous flaws. Lower-priority vulnerabilities will either:


    1. Receive deferred scoring (scored months later, if at all)

    2. Require manual vendor scoring (rely on the affected company's own assessment)

    3. Be evaluated by security tools (third-party solutions will fill the gap)


    The CVE database itself will continue to exist—vulnerability descriptions, affected software, and references will still be published. Only the severity *rating* disappears for lower-tier flaws.


    ## Why This Matters: The Implications


    For security teams, this represents a significant operational shift. Organizations that have relied on CVSS scores as the primary input to patch management workflows face several consequences:


    ### Increased Decision Burden

    Without official CVSS ratings for medium and low vulnerabilities, security teams must invest more time in manual assessment. Questions like "How long can we wait before patching this?" and "Does this affect our environment?" require custom analysis rather than a standard score.


    ### Vendor Inconsistency

    When NIST doesn't score a vulnerability, vendors may provide their own assessment—but vendor severity ratings are notoriously inconsistent. A flaw rated "medium" by one vendor might be rated "critical" by another, creating confusion across organizations using multiple products.


    ### Pressure on Third-Party Tools

    Security vendors (like Qualys, Tenable, and others) will face increased demand to provide their own severity ratings and contextualization. Organizations will become more dependent on proprietary tools that claim to "solve" NIST's bandwidth problem—potentially shifting costs to end users.


    ### Delayed Intelligence

    For emerging vulnerabilities in critical infrastructure or widely-used frameworks, the lack of immediate CVSS scoring could leave organizations blind during the critical first weeks after a flaw is disclosed.


    ## The Broader Context


    This decision reflects a systemic problem in cybersecurity: the vulnerability ecosystem has become too large for traditional, manual rating processes. Some experts argue NIST made the right call, while others warn of unintended consequences.


    Arguments in favor:

  • Focuses resources on critical threats
  • Prevents wasteful effort on low-impact flaws
  • Forces organizations to adopt more sophisticated (context-aware) risk assessment practices

  • Arguments against:

  • Creates a two-tiered system that may disadvantage smaller organizations without proprietary tools
  • Reduces transparency in the vulnerability landscape
  • Could slow patching for vulnerabilities that are low-severity in isolation but dangerous in combination

  • ## What Organizations Should Do Now


    Security teams should begin planning for this transition immediately:


    ### 1. Audit Your Current Process

    Document how you currently use CVSS scores. Do you rely on them for:

  • Patch prioritization?
  • Risk scoring?
  • Compliance reporting?
  • SLA definitions?

  • ### 2. Develop Alternative Assessment Methods

    Consider adopting:

  • EPSS (Exploit Prediction Scoring System): A newer metric that predicts whether a vulnerability will be actively exploited
  • Context-aware scoring: Evaluate vulnerabilities based on your organization's specific software inventory and risk profile
  • Vendor-specific metrics: Track vendor ratings for software you use

  • ### 3. Invest in Better Tooling

    Security teams may need to adopt or upgrade vulnerability management platforms that provide:

  • Contextual vulnerability assessment (considering your specific environment)
  • Automated triage and prioritization
  • Integration with patch management systems

  • ### 4. Update Documentation and SLAs

    If your policies reference CVSS scores, begin preparing alternate language that doesn't depend on NIST-provided ratings.


    ### 5. Engage with Your Vendors

    Ask your software vendors how they plan to respond to NIST's decision. Will they provide their own scoring? How will it differ from CVSS?


    ## The Path Forward


    NIST's decision is pragmatic but incomplete. The organization acknowledges the vulnerability volume problem but doesn't entirely solve it—it merely redirects resources. The larger question remains: *How should the industry collectively manage threat intelligence when the volume far exceeds human capacity?*


    Emerging solutions include:

  • Machine learning-based scoring to automate severity assessment
  • Vulnerability exchange standards that enable better information sharing between vendors
  • Exploit prediction metrics (like EPSS) that focus on active threat likelihood rather than theoretical impact

  • Organizations shouldn't view this as a crisis—instead, treat it as a catalyst to modernize vulnerability management practices. Moving beyond simple CVSS scores toward context-aware, predictive, and automated assessment is the inevitable evolution of the field.


    The vulnerability landscape will continue to grow. NIST's decision to refocus its efforts on high-impact flaws is a sign that the old playbook no longer works at scale.


    ---


    *HackWire will continue monitoring NIST's implementation of this policy and its impact on enterprise vulnerability management. Stay tuned for updates as the transition unfolds.*