Cisco Kenna Is Ending. What Regulated Financial Firms Should Look For in a Replacement.

If your firm runs Cisco Vulnerability Management, the platform most people still call Kenna, part of the decision has already been made for you.

Cisco announced the end of the product in December 2025. The end-of-sale date was March 10, 2026. The last day to renew or extend a contract was June 11, 2026, which has now passed. Support continues until June 30, 2028, but the product is effectively frozen. No new features, no connector updates, and no support for newer standards like CVSS 4.0 or EPSS v5. Cisco has said there is no replacement.

So the question is no longer whether to move. It is where to land. And for a regulated financial firm, that choice deserves more care than a like-for-like swap, because the thing that made Kenna valuable is exactly the thing easiest to lose in a rushed migration.

Give Kenna its due

Kenna earned its place. It helped popularize risk-based vulnerability management at a time when most teams were drowning in flat, unranked lists of CVEs from their scanners. The core idea was sound and, for many teams, genuinely clarifying. Take findings from whatever scanners you already run, apply threat intelligence and risk scoring, and focus attention on what matters instead of treating every finding as equal.

The part worth holding onto is the architecture. Kenna was scanner-agnostic and independent. It sat above your tools rather than being one of them, which meant its risk picture was not tied to any single vendor’s view. Teams chose Kenna partly for that independence, and the end-of-life notice does not change why that independence mattered.

The trap regulated firms should avoid

In the wake of the announcement, every scanner vendor is making a case that its own platform is the natural home for your Kenna data. For a regulated firm, moving to a scanner vendor’s bundled module is the option to think hardest about.

When the same vendor both finds vulnerabilities and decides which ones matter, there is a built-in tension. That vendor sees its own findings well and everything else poorly, which skews the risk picture toward what its scanner happens to detect. You lose the independent, cross-source view that was the reason to run Kenna in the first place.

For a regulated firm the stakes are higher than architecture. When an examiner asks why you prioritized the way you did, you want an answer grounded in a defensible, independent assessment of real risk, not one that reflects a single vendor’s coverage. Replacing an independent layer with a scanner-centric one is not really a migration. It is a quiet step backward in how mature your program looks under scrutiny.

What to actually look for

If you are a regulated financial firm choosing where to go, a few criteria matter more than feature checklists.

Independence and scanner-agnostic ingestion. Preserve the reason you chose Kenna. Whatever you move to should take findings from all your sources and give you one honest risk picture, not privilege the tools sold by the same vendor.

Prioritization that reflects your environment. Global severity scores and CVSS are not enough. You want scoring that accounts for real-world exploitability and your specific context, so the truly urgent set stays small enough to act on. This is not academic. Leaning on CVSS labels more than 70 percent of findings critical, while risk-based scoring narrows that to roughly 20 percent, which is the difference between a workable queue and an impossible one.

Remediation, not just scoring. This is the big one, and it is where a regulated firm’s needs have outgrown what Kenna did. Scoring findings is table stakes now. The exam question is whether you close them, on a defensible schedule, with evidence. That means ownership on every finding, remediation timelines by risk tier, and closed-loop tracking that proves a fix landed. A replacement that only re-scores your findings leaves you with the same backlog and the same audit gap.

Compliance evidence built in. For firms under NYDFS Part 500, the SEC, and similar regimes, the platform should generate the documentation an examiner wants without a manual scramble. Asset inventory, tracked remediation, and audit-ready reporting should be outputs of the system, not side projects.

A real migration path. Moving off Kenna should not mean rebuilding your program from scratch. Look for a migration that preserves the dashboards, metrics, and SLAs your stakeholders rely on, and maps your existing program into the new platform rather than starting you at zero.

Where NopSec fits

This is the problem NopSec is built for. NopSec is the remediation intelligence platform for regulated financial services, scanner-agnostic by design, with prioritization tied to real risk and a remediation workflow that assigns ownership, enforces timelines, and produces exam-ready evidence. It is the independent layer Kenna customers valued, extended into the part Kenna never fully covered, which is closing the loop.

For teams making the move, Kenna JumpStart is our migration program built specifically for Cisco Kenna end-of-life customers. It is designed to get you off a frozen product and onto a platform that does more than score, without losing the visibility your program already depends on.

The Kenna sunset is a forced decision, but it is also a real opening. The first era of risk-based vulnerability management was about ranking findings. The next one is about closing them. If you have to choose a new home anyway, it is worth choosing one built for where the discipline is going.

Product lifecycle dates above reflect Cisco’s official end-of-life bulletin. Confirm specifics for your own contracts with Cisco directly.