Notifications
Clear all
Topic starter
02/08/2026 12:11 pm
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.
NHIMG editorial — based on content published by Tonic: Cisco’s end-of-sale and end-of-life notice for Cisco Vulnerability Management, formerly Kenna Security
Questions worth separating out
Q: How should security teams migrate from RBVM to exposure management?
A: Security teams should preserve the operating model, not just export vulnerability records.
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.
Q: What do security teams get wrong about vulnerability remediation automation?
A: They often automate ticket creation but not end-to-end closure.
Practitioner guidance
- 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.
- Rebuild prioritisation around exposure, not severity Use exploitability, business criticality, compensating controls, and attack-path reachability as the criteria for queue ordering.
- 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.
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.
👉 Read Tonic’s analysis of the Kenna Security retirement and exposure management migration →
Kenna Security is ending, but what should vulnerability teams do next?
Explore further
02/08/2026 1:14 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Kenna’s retirement signals exposure management’s shift beyond RBVM
