The CISA’s Acting Director Nick Andersen announced Tuesday plans to overhaul how the agency evaluates and prioritizes software vulnerabilities, moving beyond severity scores alone to focus more heavily on real-world risk and operational impact. The agency said the changes are intended to help organizations better prioritize remediation efforts as the volume of disclosed vulnerabilities continues to grow.
Under the new approach, CISA plans to place greater emphasis on factors such as active exploitation, asset criticality, attack complexity, and the potential consequences of a successful attack. Agency officials said the goal is to help defenders focus resources on vulnerabilities that pose the greatest operational risk rather than relying solely on CVSS scores or the total number of disclosed flaws.
The initiative follows broader efforts by CISA to improve vulnerability management programs, including opening nominations for its KEV Catalog and expanding collaboration with security researchers and vendors. Officials said the updated framework is intended to provide organizations with more actionable guidance for addressing the vulnerabilities most likely to affect critical systems and infrastructure.
Denis Calderone, CTO, Suzu Labs:
“A risk-based approach to vulnerability management makes a lot of sense to us, and how we approach vulnerability management with our own clients. CVSS alone has never been a reliable way to decide which vulnerabilities to prioritize. Just in the last two weeks we’ve seen a Palo Alto GlobalProtect vulnerability rated 7.8 that was operationally critical, a SolarWinds Serv-U DoS at 7.5 against a product with a documented history of nation-state and ransomware targeting, and a Check Point zero-day where CISA’s own three-day remediation deadline told a completely different story than the score. So, the policy direction here is right. Where we get skeptical is the execution. Risk-based prioritization is significantly harder than “patch everything as fast as you can.” It requires understanding what assets you have, what functions they support, how they’re exposed, and what the real-world consequences of compromise look like. Who is going to ensure that each entity is actually performing effective risk-based assessments and not just checking a compliance box?
“That question gets harder to answer when you look at the resource picture. CISA has faced roughly half a billion dollars in proposed budget cuts and lost about a third of its workforce. Andersen is describing an approach where CISA engages directly with critical infrastructure entities to identify specific critical functions and the assets that support them. That kind of hands-on, entity-by-entity engagement requires more analytical capacity, not less. The 329 new hires are a good step forward and show the agency is serious about rebuilding operational capability, but risk-based prioritization at the scale of the federal government and critical infrastructure sectors is an enormous undertaking even for a fully staffed agency.
“The other thing we’d like to see this framework to address is chainability. CVSS scores vulnerabilities in isolation and doesn’t model scenarios where an attacker combines a medium-severity information disclosure with a medium-severity privilege escalation and ends up with critical impact. Neither bug scores as urgent on its own, but together they give you full system compromise. If the goal is to prioritize based on real-world risk, the methodology has to account for how vulnerabilities interact in actual attack chains, not just how they score individually.
“Organizations shouldn’t wait for this directive to be fully operationalized. Start building your own prioritization stack now: KEV status, EPSS exploitation probability, and your own environmental context. That combination has been more reliable than CVSS alone for a while now.”
Ryan McCurdy, VP of Marketing, Liquibase:
“CISA’s shift is the right move because severity scores alone do not tell defenders what actually puts the business at risk. A vulnerability on a low-impact system is very different from one affecting a production database, deployment pipeline, or system tied to customer data and critical operations.
“The next step is connecting vulnerability prioritization to proof of control. Security teams need to know not only which issues are being exploited, but where they sit, what they can impact, who remediated them, and whether the fix moved through a controlled change process. Otherwise, teams can patch one risk while introducing another through rushed, manual, or poorly governed changes.”
Doc McConnell, Head of Policy and Compliance, Finite State:
“The pace of vulnerability identification is accelerating thanks to AI, and the volume is outpacing response even for well-resourced teams. It makes sense that the federal government is moving from blanket timelines to more individualized, risk-based prioritization.
“But this approach demands more sophistication from cyber defenders. In order to make an effective risk-based assessment, they need to understand what they’re protecting. For example, device manufacturers need a deep understanding of their own firmware, including third-party components, to know whether a new vulnerability is present and exploitable in their product.
“Organizations need to ask themselves: do they have the context they need to make informed prioritization decisions about new vulnerabilities? If not, building that context has to be priority number one.”
Damon Small, Board of Directors, Xcape, Inc.:
“The Cybersecurity and Infrastructure Security Agency (CISA) is shifting the federal vulnerability baseline from predictable, severity-based scoring to a risk-centric paradigm. While moving beyond Common Vulnerability Scoring System (CVSS) numbers helps manage patch fatigue, calculating real-world operational risk requires localized context that most organizations struggle to automate. This subjective approach demands greater effort from analysts to extract local context, but it shifts the metric from superficial scorekeeping to actionable, risk-aligned defense.
“Security teams must integrate localized threat intelligence with strict asset discovery to ensure asset criticality tags match actual business functions. Chief Information Security Officers (CISOs) should audit their pipelines immediately to ingest CISA’s expanded Vulnrichment telemetry, prioritizing active exploitation data over static metrics to justify mitigation exceptions to auditors and business units.
“Critical Takeaways
- “Context Over Score: Severity scores are officially deprecated as standalone metrics, forcing security leaders to justify patching decisions based on active exploitation and asset criticality.
- “Telemetry Upgrade Required: Security teams must immediately update vulnerability management pipelines to ingest and process CISA’s expanded context data, rather than relying on traditional automated scanner outputs.
- “Audit Local Asset Context: CISOs need to establish strict, defensible asset discovery and business-criticality tagging, as automated risk prioritizations are useless without precise local context.
“It turns out that counting to ten over and over was a terrible way to run a security program, even if it did look nice on an executive dashboard.”
Sunil Gottumukkala, CEO, Averlon:
“Glad to see CISA’s acting director focusing on real-world risk, this shift is overdue. Knowing a vulnerability is exploited in the wild, which the KEV catalog already delivers, answers only half the question. The other half is whether it matters in your environment. Do the specific conditions the exploit depends on, a particular configuration, an exposed or reachable service, actually exist in your fleet.
“This directive pushes agencies to answer that second half. Doing it well requires two things: knowing what assets you have and how they are deployed and configured, and understanding how a given CVE is being exploited to assess its real impact on your environment.”
My advice is to take risk and operational impact and make those operational now. Then tweak things based on what is finalized. That way there is forward movement in term of making environments safer for all.
Guest Post: Stop paying attention to failure metrics
Posted in Commentary on June 10, 2026 by itnerdBy Scott Pope, Value Advisory Director, Nexthink
There’s an old saying that IT is like plumbing. You only notice it when things have gone wrong when you turn on the shower and there’s no hot water, meaning that the experts are generally only called in after the problem has occurred.
For decades, IT teams have tracked ticket volumes, mean time to resolution (MTTR) rates, and first-call resolution (FCR) percentages. Companies have endless dashboards, full of metrics showing how efficiently they handle these failures. I know many teams who work unbelievably hard and rightly pride themselves on these metrics.
The problem is that all this hard work isn’t making nearly as much difference as it should. By their very nature, IT tickets demonstrate failure because something that should be working now isn’t. What does a ticket actually represent? It means an employee has stopped doing their job because their tech has let them down. The ones who can be bothered then struggle with a portal or call IT for help, while the rest just suffer in silence. And one of the prime reasons is the use of the metrics above as a measure of success for IT teams.
You get what you incentivise
Most IT leaders don’t like to admit it, but the uncomfortable reality is that most of what IT has built; processes, portals, forms, and so on, have been designed to meet its own needs, not those of end users.
Think about what happens when IT makes a change. If there is a business impact, the employee must stop working, find a portal, pick up the phone, describe the problem in IT’s language (a language most employees don’t speak), and then wait. Wait for triage, or a resolution, or even just a callback. No wonder most employees (56%) find it easier to live with the problem instead.
Worse, the upshot of this is that IT’s metrics look better than ever. Calls to the helpdesk stagnate because people don’t want to wait on hold. Clunky portals and complex forms that make it difficult to log tickets? This results in unhappy employees, who are reluctant to raise tickets or speak to IT. Consequently, IT can show brilliant numbers about how few complaints there have been because they are inadvertently filtering out vast amounts of real demand. In short, too many IT teams have performance metrics that incentivise them to hide friction and failure, rather than eliminating it.
What’s the goal?
One key reason why IT teams default to metrics like MTTR and FCR is because there isn’t a clear directive about what the business is looking for from the department. Of course every CEO wants IT to provide better services and to improve productivity, while also reducing costs. But which of these takes precedence?
Having a clear end goal is essential to setting useful metrics. For example, if the priority is cost reduction, then metrics need to be targeted around efficiency. In this scenario, the most important metrics might be the number of automated resolutions, the recovery of IT capacity, and reducing the number of vendors in the tech stack. Conversely, a company with a high employee churn rate should be looking at the role that tech plays in worker dissatisfaction and focusing on boosting Digital Employee Experience (DEX) and Net Promoter Score (NPS) scores.
Thinking big
The role of IT is evolving rapidly. The days of installing / maintaining infrastructure and calling it a day are long gone. IT teams aren’t just expected to provide and maintain devices and applications; they’re being tasked with driving the key strategic goals of the enterprise.
To do this, all IT professionals – especially leadership – need two core skills. They need to be able to listen to their colleagues and they need to be able to get creative around solutions. A good example is the issue of employee dissatisfaction. In years gone by, this wouldn’t be seen as a problem for IT at all. Does the laptop work? Do they have access to the things they need? Then it was job done.
Today, there is virtually nothing that isn’t an IT problem in some form. Consider travel as one of the key sources of discontent. Why? Perhaps the booking platform is terrible? Or maybe people are struggling to have meetings on the road because of connectivity issues. These are problems that IT needs to be aware of and that they have the ability to fix, thus addressing a tangible enterprise pain point.
Consequently, IT needs to focus on business-outcome metrics, such as amount of friction eliminated, productive time that has been freed up, or value-added by new digital rollouts or initiatives. Otherwise, if success and failure are judged on ticket volumes and MTTR, IT will never get to the heart of what is actually being asked of it.
Enterprises have been through decades of rapid, comprehensive digital transformation that has fundamentally reshaped everything from software development to compute capabilities. It’s time for IT to do the same with support and leave these failure metrics in the past where they belong. Metrics should be directly tied to business benefits, such as friction points eliminated, productivity increased, or tasks automated, enabling IT to clearly demonstrate the value it is providing for the enterprise as whole.
Scott Pope is a Value Advisory Director at Nexthink and an accomplished IT leader, with senior level experience spanning all areas of IT Infrastructure and Project Delivery.
Leave a comment »