TL;DR: Cisco’s end-of-sale and end-of-life for Vulnerability Management, formerly Kenna Security, marks a category shift from RBVM toward continuous, contextual exposure management that prioritises business impact, remediation orchestration, and increasingly autonomous workflows, according to Tonic. The governance problem is no longer finding more vulnerabilities, but preserving context and reducing exposure across identities, assets, and attack paths.
At a glance
What this is: Cisco’s retirement of Vulnerability Management reflects the decline of severity-led RBVM and the rise of exposure management focused on context, business impact, and automation.
Why it matters: For IAM and security teams, this matters because exposure programmes now need to understand identity, ownership, and remediation context, not just asset and vulnerability counts.
👉 Read Tonic’s analysis of the Kenna Security retirement and exposure management migration
Context
Vulnerability management is shifting because the old model of counting findings no longer keeps pace with hybrid infrastructure, cloud sprawl, and faster attacker decision-making. In practice, teams need to know which weaknesses are exploitable in context, which assets matter most, and which control failures turn a vulnerability into an active exposure.
This article is really about the transition from risk-based vulnerability management to exposure management, and that transition has an identity dimension. Asset ownership, remediation assignment, exception handling, and access context all depend on reliable identity data, so poor identity governance weakens even a well-tuned exposure programme.
Key questions
Q: How should security teams migrate from RBVM to exposure management?
A: Security teams should preserve the operating model, not just export vulnerability records. That means carrying forward ownership, exceptions, tags, business criticality, and remediation history, then validating queue behaviour in parallel before cutover. If those elements are lost, the new programme will inherit the old noise with a different label.
Q: When does vulnerability scoring stop being useful for prioritisation?
A: Scoring stops being sufficient when the environment is too dynamic for a static rank to reflect real exposure. In hybrid and cloud-heavy estates, exploitability, service importance, compensating controls, and remediation feasibility matter more than the score itself. Use scoring as a starting point, not the final decision rule.
Q: What do security teams get wrong about vulnerability remediation automation?
A: They often automate ticket creation but not end-to-end closure. That creates busywork without reducing risk. Effective automation must assign ownership, enforce SLAs, trigger fixes through IT and DevOps workflows, and verify that the vulnerability is actually gone after the change. Otherwise the programme only automates reporting.
Q: Who is accountable when exposure management uses agentic workflows?
A: Accountability remains with the organisation, not the automation layer. Teams need named owners for prioritisation policy, remediation approval, exception handling, and evidence retention. If agentic systems can act, the governance model must specify who authorises those actions and who reviews the outcomes.
Technical breakdown
Why severity-based vulnerability management stops scaling
Traditional vulnerability scanning ranks issues by technical severity and creates a list of findings faster than teams can process them. RBVM improved on this by adding exploitability and asset importance, but the unit of analysis remained the vulnerability itself. That model breaks down in modern environments because exposure depends on configuration, compensating controls, business criticality, and whether remediation can actually be executed. The result is a prioritisation problem, not just a discovery problem.
Practical implication: teams should measure exposure by asset criticality and exploitability, not by CVSS alone.
How exposure management changes the control model
Exposure management shifts the question from what is vulnerable to what creates reachable, business-relevant risk. It combines vulnerabilities, misconfigurations, attack paths, identity context, and remediation feasibility into a single operational picture. The key change is that prioritisation becomes continuous and contextual, rather than periodic and manually interpreted. This is why exposure programmes increasingly depend on connected asset identity, ownership data, and workflow integration across IT and security systems.
Practical implication: connect vulnerability findings to asset identity, ownership, and workflow systems before changing prioritisation rules.
Why agentic remediation is the next governance layer
Agentic exposure management adds systems that can reason across context and then act, such as opening tickets, applying policies, managing exceptions, and tracking remediation progress. That matters because many teams do not fail at discovery, they fail at execution. In governance terms, the control plane is shifting from reporting to orchestration, which means accountability, approval logic, and exception handling must be explicit. Without that, automation just accelerates bad decisions.
Practical implication: define approval boundaries, exception rules, and audit trails before automating remediation workflows.
Threat narrative
Attacker objective: The attacker aims to reach the most valuable business services through the path of least resistance while defenders are still sorting, scoring, and assigning findings.
- Entry begins with broad vulnerability discovery that produces more findings than teams can validate, which attackers exploit through the noisiest and slowest-remediated assets.
- Escalation occurs when prioritisation relies on severity scores instead of business context, leaving critical services exposed even when known issues exist.
- Impact is realised when exposure remains reachable because ownership, workflow, and remediation context are fragmented across tools and teams.
NHI Mgmt Group analysis
RBVM is reaching its natural limit as an operating model. Severity-led prioritisation helped security teams reduce noise, but it still treats risk as a property of individual vulnerabilities rather than of reachable exposure. That works until cloud sprawl, shared services, and business-critical dependencies make context the real determinant of urgency. The discipline is moving toward exposure-centric governance, and teams that keep using scores as the primary decision input will continue to optimise the wrong thing.
Asset identity and ownership are now security controls, not administrative details. Exposure management fails when teams cannot reliably map findings to the systems and people responsible for remediation. That is where IAM-adjacent governance becomes relevant, because ownership mapping, exception handling, and access to remediation workflows all depend on trustworthy identity data. A programme that cannot identify who can fix what is already operating with blind spots.
Agentic remediation changes the governance burden, not just the tooling model. When systems can open tickets, enforce policies, and manage exceptions, the question becomes who authorises action, under what conditions, and with what evidence trail. That makes accountability, approvals, and exception expiry central to the operating model. The practical conclusion is that automation without governance will only scale inconsistency.
Context drift is the hidden failure mode in every migration away from RBVM. Preserving history, ownership, tags, and accepted-risk logic is more important than exporting raw vulnerability data. If that context is lost, teams reset reporting, lose remediation continuity, and reintroduce severity-only behaviour under a new label. Practitioners should treat context preservation as a control objective, not a migration task.
What this signals
Context preservation will become a differentiator in vulnerability programmes. As teams move toward exposure management, the quality of their asset identity, ownership, and exception data will matter as much as scan coverage. Programmes that cannot preserve that context will keep rediscovering the same risk in a new workflow.
The next operational challenge is not discovery but orchestration. Security leaders should expect greater pressure to connect exposure platforms with service management, identity records, and remediation approval flows, because that is where measurable risk reduction actually happens.
For practitioners
- Preserve remediation context during migration Carry forward ownership mappings, exceptions, tags, and prioritisation logic so the new platform does not reset historical risk decisions or create temporary spreadsheet workflows. The goal is to migrate the operating model, not just the data.
- Rebuild prioritisation around exposure, not severity Use exploitability, business criticality, compensating controls, and attack-path reachability as the criteria for queue ordering. Keep CVSS as an input, not the decision rule, so remediation effort tracks actual exposure.
- Validate workflow parity before cutover Run the new exposure workflow in parallel with existing systems such as ServiceNow or Jira and compare queue parity, deduplication, and assignment behaviour before switching off the legacy process.
- Define governance for agentic remediation Set approval thresholds, exception lifetimes, and audit requirements before allowing systems to open tickets or apply controls automatically. This keeps automation within explicit accountability boundaries.
- Link vulnerability data to identity and asset records Ensure remediation decisions can resolve asset identity, service ownership, and responsible teams without manual reconciliation. That link is what turns exposure data into executable work.
Key takeaways
- RBVM solved noise reduction, but it cannot by itself govern exposure in hybrid, contextual environments.
- The biggest migration risk is losing ownership, exception, and history data that makes remediation executable.
- Exposure management only improves outcomes when governance, identity context, and remediation orchestration move together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-1 | Risk identification and prioritisation align with the shift from vulnerability counts to exposure context. |
| NIST SP 800-53 Rev 5 | RA-5 | RA-5 governs vulnerability scanning and supports the move toward contextual remediation. |
| CIS Controls v8 | CIS-7 , Continuous Vulnerability Management | Continuous vulnerability management is the baseline control being expanded into exposure management. |
| MITRE ATT&CK | TA0007 , Discovery; TA0040 , Impact | Discovery and impact tactics map to the exposure path attackers exploit in noisy environments. |
| NIST AI RMF | MANAGE | Agentic remediation requires governance, monitoring, and bounded action under AI risk management. |
Keep CIS-7 in place, then add attack-path and business-impact context before ordering remediation.
Key terms
- Exposure management: Exposure management is the practice of identifying which assets are reachable by attackers and reducing that reach before exploitation occurs. For collaboration systems like SharePoint, it is not enough to know that a patch exists, because public accessibility changes the speed and likelihood of attack.
- Risk-based Vulnerability Prioritisation: A method of ordering remediation by how likely a flaw is to be exploited in the real world, not just by how severe it looks on paper. It combines exposure, exploit activity, asset importance, and automation potential to focus limited effort where attackers are most likely to succeed.
- Agentic Remediation: Agentic remediation uses systems that can reason about context and then take bounded action, such as opening tickets or applying controls. The governance challenge is not whether automation can move faster, but whether approvals, exceptions, and evidence remain auditable.
- Context Drift: Context drift is the gap between what an identity was authorised to do at the start of a session and what it ends up doing after inputs, tools, or instructions change. In agentic systems, it is a core governance problem because behaviour can move outside the original approval boundary.
What's in the full article
Tonic's full article covers the operational detail this post intentionally leaves for the source:
- The Kenna migration workflow, including how Tonic preserves asset identity, ownership mapping, exceptions, and prioritisation logic.
- The parallel-run approach for validating queue parity across ServiceNow, Jira, and related remediation systems.
- The cutover checklist for maintaining KPIs, audit trails, and reporting continuity without resetting historical trends.
- The agentic remediation workflow details, including how tickets, policies, exceptions, and mitigation actions are orchestrated.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle principles that help teams manage access context and accountability. It is useful for practitioners building identity-aware security programmes across modern infrastructure.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
