NIST’s CVE Shift Raises the Bar for Vulnerability Prioritization

COMMENTARY: Vulnerability risk can’t be judged by a score alone. CVEs still matter, but security teams and MSSPs need more context. They need to know if a flaw is exposed, if it affects a critical system, if attackers are using it, and how quickly it needs to be fixed. CVSS can show how serious a vulnerability could be, but it does not show how risky it is for a specific client. For MSSPs, this raises the bar. Their value will come from helping clients cut through the noise, focus on the risks that matter most, and explain why some fixes need urgent action while others can wait.

A new method of vulnerability prioritization is changing how security teams contextualize risk. Recently, the National Institute of Standards and Technology (NIST) announced it will no longer provide detailed severity scoring and impact analysis for every Common Vulnerability and Exposure (CVE) in the National Vulnerability Database. Going forward, only CVEs meeting specific high-impact criteria will receive that level of analysis.

NIST said the change is driven by a volume of submissions that outpaced the system, with a 263% increase since 2020. At the same time, the change places greater responsibility to contextualize risk on individual security teams and their partners. For organizations still relying on the Common Vulnerability Scoring System (CVSS) as the primary driver behind remediation priorities, it also exposes a gap that’s been there all along.

CVSS scores lack context. They represent what a vulnerability could do in a vacuum, an idealized scenario disconnected from any specific environment. VulnCheck’s 2026 Exploit Intelligence Report found that just 1% of vulnerabilities disclosed in 2025 were confirmed as exploited in the wild, yet CVSS scores don’t reflect that. The score doesn’t know what software is running in your clients’ infrastructure, which systems face the internet, or which ones keep the business operational.

Security teams have always had to add context to these alerts, but with NIST scaling back its analysis, more of that work now falls back to them. There’s now a higher premium on the fundamentals of vulnerability prioritization. Security teams need to really understand their environments, know what’s exposed, and be deliberate about what gets prioritized and why.

Organization-specific exposure modeling is where that starts. It means knowing whether the software flagged in a CVE is actually running in the environment, whether it’s exposed to the network perimeter or the internet, and what the business impact would be if that system went down. That kind of triage cuts through the noise fast and separates what needs immediate attention from what can wait for a scheduled maintenance window.

The next layer is threat intelligence, which describes actual exploitation rather than potential. A threat that’s rated lower but is actively weaponized takes priority over a higher-rated vulnerability that no one is targeting. Weighting threat intelligence feeds accordingly is how teams stay ahead of what’s actually happening.

A recent example shows how these layers work together. Three CVEs dropped against a major firewall vendor in a single morning, all with scores that warranted attention. But org-specific context revealed that one targeted the management interface, and the standard practice in that environment locked management interfaces so they were accessible only from the provider’s corporate IP space. A threat actor would need to physically breach the office or compromise the internal network before reaching the surface. For a client base of thousands of firewalls, that vulnerability was effectively moot. Without that context, remediation would have been triggered across every device, creating wasted hours, wasted resources, and attention diverted from the two CVEs that actually mattered.

The final fundamental piece is the feedback loop. How long does it take from the moment a vulnerability is identified until it’s remediated? Tracking that metric and continuously refining the process is what keeps vulnerability management from going stale.

Once those fundamentals are in place, security teams can take it a step further with AI-assisted tools that help them triage faster and at a greater scale. When these tools are trained on real analyst decision-making — how a security operations center team triaged alerts, identified false positives, and determined what required customer notification — they can produce agents that surface genuinely threatening activity and push noise to the background. That compresses mean time to resolution, which matters when the difference between staying ahead of an incident and chasing one comes down to hours.

But AI has real limitations in this context. AI lacks adversarial reasoning. It can’t think like a threat actor probing for the unexpected. It can hallucinate and carry the biases of its training data. That’s why there should still always be a human element in the judgment and decision-making. Weighing conflicting signals, overriding a score, and communicating risk to a client are the kinds of judgment calls that require understanding a specific organization’s context, and that’s something AI isn’t equipped to do.

While AI helps detect risk, it’s also one of the reasons that the volume of attacks and vulnerabilities has increased. IBM’s 2025 Cost of a Data Breach Report found that 16% of breaches involved attackers using AI, most commonly for phishing and deepfake impersonation. Threat actors are using the technology to run campaigns at a volume and speed that previously required larger teams and far more manual effort.

Additionally, threat actor groups are leveraging AI and LLMs to create, test, and distribute cyberattacks. Google published findings that a recent zero-day exploit was leveraged against an organization and was likely created by AI, the first known instance of its kind.

With AI amplifying risk on both sides, how organizations govern their own use of it matters just as much as how they deploy it. Incorporating AI into any system needs to be matched by governance — policies for what data goes into AI tools, oversight of which tools teams are actually using, and accountability for unsanctioned shadow AI adoption. This is done best when there’s a governance, risk, and compliance committee set up among multiple departments, such as IT, HR, cybersecurity, and executive sponsorship. Every part of the business needs to understand the risk and how it affects the organization.

Without policies in place around AI or overarching internet policies as a whole, it’s the wild, wild west out there. These policies serve as the foundation that drives business outcomes and clarifies how humans interact with technology.

Along with policies, vulnerability prioritization should be viewed as a partnership between MSSPs and their clients, and between vendors and the organizations that depend on them. When a client’s brand suffers reputational damage from an attack, the provider feels it too. That shared stake makes constant communication about a client’s environment so important. A CVSS score is theoretical. An attack isn’t. The policies, partnerships, and communication that connect the two are what determine whether an organization is ready when it matters, even as the industry changes.

MSSP Alert Perspectives columns are written by trusted members of the managed security services, value-added reseller and solution provider channels or MSSP Alert's staff. Do you have a unique perspective you want to share? Check out our guidelines here and send a pitch to [email protected].