TL;DR: Cisco’s Kenna end-of-life notice highlights a broader vulnerability management problem: teams that depended on scanner-agnostic prioritisation now need a replacement governance layer before support ends in 2028, according to ArmorCode. The real issue is not product sunset but whether exposure programmes can keep independent risk ranking as AI and supply-chain findings continue to outpace remediation capacity.
At a glance
What this is: ArmorCode argues that Kenna’s end-of-life is less about one product sunset and more about whether vulnerability teams can preserve independent exposure governance as discovery volume keeps rising.
Why it matters: For IAM, NHI, and security teams, the issue is whether prioritisation remains separate from the tools that generate findings, especially as application, cloud, supply chain, and AI exposures converge.
Context
Kenna’s retirement matters because vulnerability management is not just a collection problem. It is a governance problem: teams need a way to normalise findings from multiple scanners, rank them by exploitability and business context, and avoid inheriting the bias of whichever tool produced the alert.
The identity angle appears when exposure programmes extend into application and cloud estates that are full of service accounts, API keys, tokens, certificates, and workload access paths. When prioritisation becomes vendor-centric, teams lose the independent view needed to govern both human and non-human access risk across the wider attack surface.
Key questions
Q: What breaks when vulnerability prioritisation is tied to the same vendor that finds the issues?
A: The main failure is bias in ranking and limited visibility across competing tools. A scanner-centric platform often prioritises what it sees best, while an independent layer can normalise findings from the full estate and rank them against business context. That separation matters when remediation capacity is limited and teams need an impartial queue.
Q: Why does Kenna’s end-of-life force teams to rethink exposure governance now?
A: Because replacement is not just a tooling decision, it is a control decision. The article shows that migration windows are finite, new features will stop, and the original governance model has to survive the transition. Teams that wait risk rebuilding the same bias Kenna was designed to remove.
A: The test is whether it can ingest multiple sources, deduplicate overlapping findings, enrich them with exploitability and asset context, and present a single prioritised queue without collapsing into vendor-specific scoring. If it cannot do that, it is changing the operating model, not replacing it.
A: They should use one governance model, but extend it across both problem sets. Software vulnerabilities, service accounts, tokens, certificates, and AI agents all create exposure, and the prioritisation logic should compare them using the same business-risk lens. Separate programmes usually create separate blind spots.
Technical breakdown
Why scanner-agnostic prioritisation changes exposure governance
Scanner-agnostic vulnerability management sits above detection tools and turns disparate findings into one prioritised queue. The mechanism matters because scanners are good at finding issues in their own telemetry, but they do not naturally give equal treatment to data from competing tools. A governance layer normalises severity, exploitability, asset value, and threat context before remediation decisions are made. That separation reduces bias and makes risk ranking consistent across infrastructure, cloud, applications, and supply chain inputs. It also becomes more important when remediation capacity is limited, because the control is not discovery volume but decision quality.
Practical implication: Keep prioritisation logic separate from the tool that discovers the issue.
Why vulnerability volume is now the bottleneck
The core problem is no longer whether teams can find vulnerabilities, but whether they can decide which few exposures deserve action first. As submissions rise and AI-assisted research lowers the cost of discovery, the backlog grows faster than remediation capacity. That shifts the operating model from raw enumeration to triage at scale. In practice, risk-based vulnerability management depends on enrichment, deduplication, exploit intelligence, and business context. Without those layers, even a well-instrumented programme becomes noise-heavy and operationally brittle, because the security team spends more time sorting than fixing.
Practical implication: Use enrichment and deduplication to turn volume into an actionable queue.
What changes when AI enters exposure discovery
AI-assisted vulnerability research changes the economics of discovery, not the economics of fixing. More findings arrive faster, but the finite part of the system is still validation, prioritisation, and remediation orchestration. That means exposure governance has to absorb AI-generated code, AI agents, and AI-enabled features alongside traditional assets. The relevant control shift is from periodic review to continuous intake, scoring, and workflow automation. The governance model also has to preserve independence so that AI-era findings are judged against the same business risk criteria as legacy vulnerabilities.
Practical implication: Design governance for faster discovery, not just larger backlogs.
NHI Mgmt Group analysis
Independent exposure governance is now the real control plane for vulnerability management: the market problem is not shortage of scanners but shortage of impartial decision-making above the scanners. When prioritisation is fused to a vendor’s own detection stack, risk ranking inherits that stack’s blind spots and incentives. The better model is a governance layer that can compare findings across tools without favouring the source of the alert. Practitioners should treat independence as a control requirement, not a procurement preference.
Kenna’s end-of-life exposes a governance gap, not merely a migration task: the vulnerable assumption is that a prioritisation platform can be replaced by any tool that also finds issues. That assumption fails because scanning and exposure governance are different functions. One produces inventory, the other resolves conflict between competing signals, business context, and remediation capacity. Teams should re-evaluate whether their replacement preserves scanner neutrality before they commit.
AI-driven discovery widens exposure debt faster than traditional remediation models can absorb: this creates what we can call exposure prioritisation lag, the growing gap between issue creation and decision quality. As AI-assisted research and machine-generated code increase the pace of new findings, governance models that depend on manual review will fall behind. The implication is clear: prioritisation must become continuous, automated, and context-rich.
The identity dimension is easy to miss, but it is where exposure governance becomes broader than vulnerability management: modern exposure programmes increasingly touch service accounts, API keys, tokens, certificates, and AI agents, not just CVEs on servers. That means the same independent governance layer must reconcile machine identity risk with application and infrastructure exposure. Teams that do not extend the model will end up with separate blind spots for human access, NHI risk, and software flaws.
Market consolidation will keep pushing teams toward platform decisions that can distort governance boundaries: as vendors bundle detection, scoring, and remediation into one stack, practitioners have to decide whether convenience outweighs independence. The discipline is to preserve cross-tool normalisation even if the toolset changes. That is how exposure management stays credible when the asset base, threat volume, and AI-generated findings keep expanding.
What this signals
Exposure prioritisation lag: when discovery accelerates faster than remediation capacity, the security programme stops failing at finding issues and starts failing at deciding which issues matter most. That is why independent ranking logic becomes a control requirement rather than an optional architectural preference.
The operational lesson for practitioners is to defend the separation between detection, scoring, and workflow orchestration. When those functions collapse into a single stack, the programme may look simpler, but its decision quality becomes harder to trust across cloud, application, supply chain, and NHI-adjacent exposures.
For practitioners
- Preserve scanner-agnostic prioritisation Map every replacement option against one test: can it normalise findings from multiple scanners without privileging its own telemetry? If not, it is not a like-for-like governance replacement.
- Separate discovery from decision-making Keep ingestion, deduplication, exploitability scoring, and remediation workflow under a distinct governance layer so the tool that finds an issue does not also define its priority.
- Build a migration plan before support ends Use the remaining support window to inventory integrations, export requirements, scoring logic, and workflow dependencies so the transition does not become a rushed platform swap.
- Extend exposure governance to machine identities Include service accounts, API keys, tokens, certificates, and AI agents in the same prioritisation model so non-human access risk is not handled as a separate programme.
Key takeaways
- Kenna’s end-of-life is really a governance test for whether vulnerability teams can keep prioritisation independent from the tools that generate findings.
- The pressure is increasing because discovery is accelerating faster than remediation capacity, which makes decision quality more important than raw alert volume.
- Teams that replace an independent exposure layer with a scanner-centric stack risk rebuilding the same bias and blind spots that scanner-agnostic programmes were meant to avoid.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | This article is about how teams govern exposure prioritisation as a risk function, not just a tool feature. |
| Recommendation — Define exposure prioritisation as a governed risk function with clear ownership and decision criteria. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article centres on vulnerability prioritisation, enrichment, and remediation at scale. |
| Recommendation — Operationalise continuous vulnerability management with enrichment, prioritisation, and tracking of remediation. | ||
| MITRE ATT&CK | TA0007;TA0010 — Discovery; Exfiltration | The piece discusses attacker-driven exploitability, backlog pressure, and the value of exploit intelligence. |
| Recommendation — Map exploitability-driven prioritisation to discovery and exfiltration pressure when ranking exposures. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article extends exposure governance into APIs, cloud, and software supply chain inventory challenges. |
| Recommendation — Use API inventory controls to ensure exposure governance sees every externally reachable service and dependency. | ||
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.
- Exposure Prioritisation Lag: The growing delay between when issues are discovered and when teams can make confident remediation decisions. It appears when discovery volume rises faster than enrichment, deduplication, and workflow capacity, leaving security teams with more findings than they can meaningfully rank.
- 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.
- 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.
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 suited to teams that need to connect access governance, machine identity risk, and broader security operations.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org