Kenna end of life exposes the case for independent exposure governance

At a glance

What this is: This is ArmorCode’s analysis of Cisco’s Kenna end-of-life timeline and the risk that vulnerability programmes lose scanner-agnostic prioritisation.

Why it matters: It matters because vulnerability teams, IAM-adjacent governance owners, and security architects need to preserve independent risk decisioning as tool consolidation, automation, and AI-driven discovery increase exposure volume.

By the numbers:

• Cisco’s Kenna platform reached end-of-sale on March 10, 2026, and end-of-support is scheduled for June 30, 2028.
• NIST reported that CVE submissions increased 263% between 2020 and 2025, forcing a more risk-based enrichment model.
• According to Mordor Intelligence, the security and vulnerability management market will grow from $16.75 billion in 2025 to $22.91 billion by 2030.

👉 Read ArmorCode’s analysis of Kenna end of life and exposure governance

Context

Kenna’s end of life is not just a product sunset. It is a test of whether security programmes can preserve independent vulnerability governance when the underlying platform disappears and the remediation window is finite. For teams that built around scanner-agnostic prioritisation, the key question is whether the next platform can still normalise risk across multiple sources without inheriting scanner bias.

The primary issue is exposure governance, not feature parity. Vulnerability discovery is accelerating faster than remediation capacity, while application, cloud, supply chain, and AI-related findings continue to expand the scope of what must be prioritised. That makes independent ranking, deduplication, and workflow orchestration more important than simply replacing a named product with another console.

Key questions

Q: How should security teams migrate off a scanner-agnostic vulnerability platform without losing governance?

A: Start by separating the migration of data, workflows, and decision logic. Preserve the prioritisation model, deduplication rules, and ownership routing before you switch consoles. If the new platform cannot normalise multiple telemetry sources and preserve historical context, the migration has replaced governance with a new reporting layer rather than a stronger operating model.

Q: Why do scanner vendors struggle to replace independent vulnerability governance?

A: Because the vendor that detects the issue often has the strongest visibility into its own telemetry and the weakest incentive to keep external findings equally weighted. Independent governance exists to reduce that bias, normalise heterogeneous data, and create a decision layer that reflects enterprise risk rather than product coverage.

Q: What do security teams get wrong about high CVSS scores?

A: They often treat CVSS as a complete ranking signal. In practice, a lower-scored issue can be more dangerous if it is reachable, chained to other weaknesses, or linked to exposed credentials. Teams should look at real attack paths, not just the score attached to an individual finding.

Q: When should organisations invest in exposure management instead of point-tool consolidation?

A: When they have multiple scanners, cloud tools, application findings, or supply chain inputs that do not resolve into one trusted queue. In that situation, consolidating tools can reduce console sprawl, but only exposure management preserves the independent ranking and workflow control needed to actually reduce risk.

Technical breakdown

Why scanner-agnostic vulnerability governance matters

A scanner-agnostic governance layer sits above point tools and normalises their findings into one prioritisation model. That matters because scanners see their own telemetry best, but not the full mix of infrastructure, application, cloud, endpoint, and supply chain exposures. Independent governance reduces prioritisation bias, helps deduplicate duplicate findings, and supports risk ranking based on exploitability and business context rather than raw severity alone. In practice, the value is not just visibility. It is decision quality across many tools and teams.

Practical implication: preserve a governance layer that can ingest multiple security tools without forcing a single vendor’s telemetry to become the decision standard.

Why risk-based prioritisation is replacing severity-only triage

Severity scores describe technical seriousness, but they do not tell teams which findings actually change enterprise risk. Risk-based prioritisation adds exploitability, asset criticality, threat intelligence, and operational context, which is why it scales better as vulnerability volumes rise. With AI-assisted discovery increasing the number of issues found, programmes that still rely on severity-only queues will accumulate backlog faster than they can remediate. The challenge is not finding more problems. It is selecting the few that justify immediate action.

Practical implication: treat exploitability and asset context as mandatory inputs to remediation ordering, not optional enrichment fields.

How unified exposure management extends beyond classic vulnerability management

Unified Exposure Management extends the old RBVM model across code, cloud, containers, software supply chain, endpoints, and emerging AI systems. The architectural difference is that it treats exposure as a cross-domain governance problem rather than a scanner output problem. That means ingesting broader telemetry, applying common risk logic, and routing remediation to the right operational owners. For modern programmes, this is the bridge between vulnerability data and enforceable action across engineering, operations, and security.

Practical implication: evaluate whether a replacement platform can govern exposures across domains, not just replicate the original console’s dashboard.

NHI Mgmt Group analysis

Independent vulnerability governance is becoming a structural requirement, not a feature preference. Kenna’s exit matters because many programmes relied on a scanner-agnostic layer to prevent detection vendors from also controlling prioritisation. That separation matters even more now that multi-cloud, application, supply chain, and AI findings all compete for attention. The practitioner lesson is to protect the decision layer even if the tooling stack changes.

Exposure backlogs will grow faster than remediation capacity unless prioritisation logic stays independent. The article’s core argument is that discovery is accelerating, but human and workflow capacity are not. That creates a governance gap where severity-only or vendor-native scoring becomes too blunt for enterprise use. The named concept here is prioritisation bias drift: when the platform that detects issues also shapes the ranking model, risk decisions can slowly skew toward the vendor’s best visibility rather than the organisation’s worst exposure. Practitioners should insist on cross-tool normalisation.

Tool consolidation can simplify operations while weakening governance if it collapses the wrong abstraction. The market is clearly moving toward fewer suppliers and broader exposure platforms, but the control objective should be consolidation of workflow, not consolidation of judgment. Independent ranking, deduplication, and routing remain essential control functions. The practitioner conclusion is to keep governance independent even when the operating stack becomes more integrated.

AI is changing the economics of vulnerability discovery, which raises the value of remediation orchestration. As AI-assisted research increases issue discovery rates, the security bottleneck shifts further downstream into triage, ownership, and closure. That means teams need exposure platforms that can convert prioritised findings into accountable action, not merely aggregate more telemetry. The field is moving toward governance that can absorb machine-scale discovery without losing human control over remediation priorities.

What this signals

Exposure management programmes will be judged less by how many findings they ingest and more by whether they can keep an independent prioritisation model as the tool stack changes. For identity and security teams, that means governance must survive vendor churn, especially where scanner data, cloud signals, and supply chain findings all feed the same remediation queue.

Prioritisation bias drift: once detection and ranking collapse into the same vendor workflow, the programme can gradually optimise for what is easiest to see rather than what is most dangerous. Teams should watch for this drift when evaluating replacements and should prefer platforms that preserve cross-tool normalisation and ownership routing.

For practitioners

• Preserve a scanner-agnostic decision layer Map every critical vulnerability source to a governance layer that can normalise findings from infrastructure, cloud, application, endpoint, and supply chain tools before prioritisation. If the replacement only scores its own telemetry well, it is not a true successor.
• Test prioritisation against business-critical exposures Run side-by-side comparisons between vendor-native rankings and risk-based rankings that include exploitability, asset criticality, and threat intelligence. Use the delta to identify where scanner bias or incomplete context is affecting remediation order.
• Plan migration before the support deadline compresses options Build a migration roadmap that covers data export, workflow remapping, integration testing, and stakeholder sign-off well before June 30, 2028. Enterprise platform transitions often take months, and late moves increase the chance of losing historical context.
• Extend exposure governance into supply chain and AI Verify that the next platform can handle SBOM ingestion, third-party component risk, and AI-related findings alongside classic vulnerability data. A modern exposure programme now needs cross-domain coverage, not just a new dashboard.

Key takeaways

• Kenna’s end of life is a governance problem because many teams depended on its scanner-agnostic prioritisation layer, not just its dashboard.
• The scale problem is getting worse, which makes independent risk ranking and remediation orchestration more valuable than ever.
• Teams should preserve decision independence as they migrate, or they risk replacing one tool with a weaker operating model.

Key terms

• Scanner-agnostic governance: A security operating model that normalises findings from multiple scanners and security tools before prioritisation. It reduces vendor bias, deduplicates overlapping alerts, and creates one decision layer for risk ranking, ownership, and remediation routing across the enterprise.
• Risk Prioritisation: A method for ranking NHIs by exposure, privilege, business criticality, and age so remediation effort lands on the identities most likely to widen blast radius. It prevents lifecycle programmes from treating every credential as equally urgent, which is rarely true.
• Unified Exposure Management: An operating model that treats cloud, application, container, and supply chain risk as one continuous security problem. It connects discovery, prioritisation, ownership, and remediation so teams can answer what is exposed, what matters most, and what has been done about it using a shared evidence trail.
• Prioritisation bias drift: A gradual skew in risk ranking that happens when the same vendor controls both detection and scoring. Over time, the programme may favour issues easiest for that vendor to see, which can distort enterprise remediation decisions and weaken independent governance.

What's in the full article

ArmorCode's full blog covers the operational detail this post intentionally leaves for the source:

• Cisco’s Kenna end-of-life milestones and support deadlines for migration planning
• ArmorCode’s scanner-agnostic integration model across multiple security tool types
• Unified Exposure Management workflows for remediation routing and ownership tracking
• The AI Exposure Management and agentic AI architecture sections that go beyond vulnerability governance

👉 ArmorCode’s full post covers the migration timeline, scanner-agnostic architecture, and exposure management model in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, secrets management, and lifecycle controls. It is designed for practitioners who need to connect identity governance with broader security operations.