Topic starter
20/08/2026 5:39 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by ArmorCode: “Kenna End of Life: How to Preserve Independent Vulnerability Management”.
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.
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.
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.
Practitioner guidance
- Preserve scanner-agnostic prioritisation Map every replacement option against one test: can it normalise findings from multiple scanners without privileging its own telemetry?
- 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.
Bottom line: Kenna’s end-of-life is really a governance test for whether vulnerability teams can keep prioritisation independent from the tools that generate findings.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:23 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Kenna end of life exposes the case for independent exposure governance