TL;DR: AI has shortened the gap between vulnerability disclosure and weaponization, while many teams still run scan, score, ticket, chase workflows that assume defenders have time, according to Tonic. The real control problem is not finding more issues, but contextualizing business impact, ownership, and exploitability quickly enough to reduce exposure before attackers do.
At a glance
What this is: Tonic argues that legacy vulnerability management is too slow for an environment where AI compresses disclosure-to-weaponisation timelines and backlog has become part of the attack path.
Why it matters: For IAM and security teams, this shifts the question from volume of findings to ownership, business context and verified exposure reduction, including where identity and access dependencies shape real risk.
Context
Vulnerability management fails when it treats discovery as the end of the control loop. In practice, modern attackers move faster than scan, score and ticket workflows can resolve ownership, context and remediation, so the primary gap is execution speed rather than visibility.
This is not only a vulnerability operations problem. When exposed systems are tied to business applications, cloud workloads or identity dependencies, slow remediation turns access paths, service accounts and internet-facing services into durable risk. The typical backlog-driven operating model is now the weak point, not an exception.
Key questions
Q: What breaks when vulnerability management stops at scanning and ticketing?
A: Teams create a false sense of progress. Findings can be logged quickly, but attackers care about whether the weakness is still reachable. If ownership, fix approval, and verification are missing, the exposure remains live even when dashboards look healthy. The result is exposure debt, where known exploitable issues stay open long enough to be reused.
Q: Why does prioritizing vulnerabilities by business context improve remediation outcomes?
A: Prioritizing by business context reduces wasted effort on low-value findings and directs scarce resources toward exposures that could disrupt important services. When teams factor in asset criticality, dependencies, and exploitability, they can focus on issues with the greatest operational and security impact. This creates faster, more defensible remediation decisions and better alignment between security work and business continuity.
Q: What are the signs that vulnerability management is not working well enough in an enterprise?
A: Common warning signs include long remediation cycles, weak visibility into where vulnerabilities exist, and inconsistent prioritisation of high-risk findings. If teams keep repeating the same issues, rely on ad hoc reports, or lack a clear treatment path, the programme is probably underperforming. Another signal is when vulnerabilities are discovered only after attackers or audits surface them.
Q: What should teams measure to know whether exposure management is working?
A: Track time to containment, secret revocation latency, and the percentage of high-risk systems covered by explicit ownership. If findings regularly sit between discovery and action, the programme is failing where AI-driven testing will pressure it most. Those metrics show whether the organisation can respond at machine speed.
Technical breakdown
Why scan-score-ticket workflows break down
Traditional vulnerability management assumes there is enough time to find issues, rank them and hand them off for later remediation. That assumption collapses when exploitation windows shrink to hours or less. The workflow optimises for triage volume, not exposure reduction, so teams can accumulate tickets faster than they can resolve the underlying attack surface. In that model, severity scores are treated as a proxy for urgency, even though they rarely capture exploitability, reachability or business consequence. The result is a backlog that looks organised but still leaves material exposures available to attackers.
Practical implication: replace linear triage with an exposure model that measures whether a vulnerability is still reachable and exploitable in context.
Why severity scores are not a remediation strategy
CVSS is a useful indicator, but it is not a decision system. A high score on an isolated asset may matter less than a moderate issue on an internet-facing system tied to critical processes, privileged access or sensitive data flow. Effective prioritisation has to combine exploitability, asset reachability, compensating controls, ownership and operational constraints. That requires contextual enrichment from CMDB, identity, cloud and business systems, not just scanner output. Without that added context, teams are optimising for ticket closure rather than actual risk reduction.
Practical implication: enrich vulnerability findings with asset, identity and business context before assigning remediation priority.
How continuous exposure reduction changes the operating model
Exposure reduction is a closed-loop discipline. Signals come in from scanners, cloud platforms, identity systems, ITSM and business applications, then get contextualised into decisions that drive action and confirm whether the exposure was actually reduced. This is where agentic workflows matter: they can coordinate ownership, remediation and validation across systems that humans cannot manage at the same speed. The control objective is not more findings, but faster movement from detection to verified reduction. That makes the operating model execution-oriented rather than report-oriented.
Practical implication: build feedback loops that validate remediation outcomes, not just ticket creation.
NHI Mgmt Group analysis
Exposure reduction velocity is now the relevant control metric. Security programmes that still measure success by scan coverage or ticket volume are optimising the wrong thing. The attacker advantage comes from the time gap between discovery and exploitation, so governance has to focus on how quickly exposure is materially reduced. Practitioners should treat velocity as an operational risk indicator, not a reporting vanity metric.
Backlog is no longer a side effect of vulnerability management, it is part of the attack surface. Once exposures remain unresolved long enough to be operationally normal, the backlog itself becomes a risk-bearing asset. That changes governance from counting unresolved issues to understanding which unresolved issues are still reachable, business-critical and actively exploitable. Teams need to stop assuming backlog growth is neutral.
Context is the missing decision layer in vulnerability operations. CVSS, scanner output and threat intelligence each describe part of the problem, but none of them alone tells a team what to fix first. The article correctly points to business impact, reachability and ownership as the practical determinants of risk. Exposure context debt: when teams cannot connect a finding to asset criticality, ownership and exploitability fast enough, remediation becomes performative instead of effective. Practitioners should reduce that debt before it accumulates into persistent exposure.
Agentic workflows will increasingly govern remediation execution, but only if the inputs are trustworthy. The move from collect to contextualize to act depends on clean ownership data, accurate asset relationships and dependable workflow automation. That has an identity implication because remediation coordination often depends on who owns the asset, who can approve the change and which systems can safely act. Without governed automation, speed simply multiplies confusion instead of reducing exposure. Practitioners should design for auditable execution, not just faster routing.
What this signals
Exposure reduction velocity is becoming a programme-level control objective. Teams that still optimise for issue discovery will keep accumulating exposure faster than they can govern it. The practical shift is toward a workflow that proves reduction, not just activity, and that means integrating remediation verification into the operating model.
Identity and ownership data are now part of vulnerability governance. The article's core point is not limited to scanners or CVSS. Remediation only completes when the right owner is identified, the right change is executed and the resulting exposure state is validated, which makes identity, CMDB and ITSM data operationally relevant to vulnerability operations.
For practitioners
- Replace severity-only prioritisation Combine exploitability, reachability, business criticality, ownership and compensating controls before deciding remediation order.
- Map every exposure to a clear owner Tie findings to the application, workload or business service owner so tickets can move beyond generic queue assignment.
- Validate that remediation actually reduced exposure Require post-change checks that confirm the vulnerable service, path or configuration is no longer reachable or exploitable.
- Automate enrichment from identity and asset systems Pull CMDB, ITSM, cloud and identity context into the vulnerability workflow so prioritisation reflects current operational reality.
Key takeaways
- Legacy vulnerability management fails when it assumes defenders have time to process findings before exploitation windows close.
- The backlog is now a risk-bearing part of the attack path when exposures remain reachable and unresolved.
- Teams need contextualised remediation and post-change validation to prove that exposure was actually reduced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Risk Management Strategy | The article is about risk-based prioritisation of exposures before attackers exploit them. |
| PR.PS-03 — Configuration Management | Reducing exposure depends on correcting vulnerable or misconfigured assets, not just logging findings. | |
| Recommendation — Use ID.RA-01 to tie remediation priority to exposure, exploitability and business impact. Apply PR.PS-03 to enforce remediation of vulnerable configurations and exposed services. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article directly critiques legacy vulnerability management and calls for continuous reduction of exposure. |
| Recommendation — Use CIS-7 to operationalise continuous vulnerability discovery, prioritisation and verified remediation. | ||
| MITRE ATT&CK | TA0007;TA0006 — Discovery; Credential Access | The article focuses on shortening the window between disclosure and exploitation, including paths to access. |
| Recommendation — Map fast-moving exposure windows to ATT&CK tactics and prioritise assets that are reachable now. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The article is fundamentally about moving beyond scan output to measurable exposure reduction. |
| Recommendation — Use RA-5 as the discovery layer and pair it with contextual prioritisation and remediation validation. | ||
Key terms
- Exposure Reduction Velocity: The rate at which an organisation turns a discovered weakness into a verified reduction in attack surface. It captures ownership, prioritisation, remediation, and validation as one outcome, rather than treating discovery and closure as separate success measures.
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
- Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
- Validated remediation: Validated remediation means proving that a patch, configuration change, or mitigation actually closed the attack path. The key test is not whether the change was deployed, but whether the environment now blocks, detects, or otherwise neutralises the technique that made the issue dangerous.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance and agentic AI through independent research, practitioner guides and the NHI Foundation Level course. It is a useful next step for practitioners aligning exposure management with identity-driven control and governance.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org