Kenna End of Life: How to Preserve Independent Vulnerability Management

The Kenna end of life announcement marks a turning point for risk-based vulnerability management. On December 10, 2025, Cisco announced that its Vulnerability Management platform, formerly Kenna Security, will reach end-of-sale on March 10, 2026, with final support ending June 30, 2028. According to Cisco’s official bulletin, there is “no replacement available” for Kenna.VM, Kenna.VI, or the AppSec module.

For me this is a bittersweet moment, since I was employee number 45 at Kenna when it first started. I am still close friends with many of my former colleagues and we hold a reunion every year in Chicago, the home of Kenna and still one of my favorite cities. It was more of a family than a security company.

For security teams who built their vulnerability programs on Kenna’s independent, scanner-agnostic foundation along with cutting edge data science, this announcement raises an urgent question: How do you move forward without sacrificing the architectural principles that made Kenna effective?

What the EOL Timeline Means for Your Team

Cisco’s announcement outlines several milestones that security leaders need to plan around:

• End-of-Sale Date: March 10, 2026 (last day to purchase new subscriptions)
• End of Renewal Date: June 11, 2026 (last day to renew or extend existing contracts)
• Last Date of Support: June 30, 2028 (all support services end)

Notably, Cisco also confirmed that after the end-of-sale date, no new features, connector updates, or algorithm improvements will be developed. The company will not add support for CVSS 4.0 or EPSS v4, updates that are increasingly relevant as the vulnerability management field evolves.

This timeline gives organizations roughly two years to evaluate alternatives and execute a migration. That window may seem generous, but enterprise platform transitions rarely happen quickly. Security teams that start planning now will have more options and less operational disruption.

Why Independence Mattered Then, and Matters More Now

Kenna changed how organizations thought about vulnerability management. Rather than treating every CVE as equally urgent, Kenna applied data science and threat intelligence to separate signal from noise. More importantly, Kenna operated as a governance layer that sat above scanning tools, normalizing data from multiple sources without bias toward any single vendor.

That independence was the product’s defining strength. Security teams could aggregate findings from infrastructure scanners, application security tools, cloud security platforms, and endpoint solutions into a single view, with prioritization based on actual exploitability rather than raw severity scores.

The vulnerability volume problem that drove Kenna’s original adoption has only intensified. According to Bitsight research, 2025 will see between 48,000 and 59,000 new CVEs published, pushing the total above 300,000. Organizations now face an average of 128 new vulnerabilities per day requiring triage. Yet Bitsight’s analysis also shows that only about 0.2% of published CVEs are actually used in ransomware attacks or by advanced persistent threat groups.

The math is clear: trying to remediate everything remains impossible. Intelligent prioritization based on risk, not scanner output, is the only path forward.

According to NIST research, enterprises remediate approximately 16% of their vulnerabilities per month on average. When combined with exponential CVE growth, this means most organizations are falling further behind, not catching up. The independent governance layer Kenna provided wasn’t a luxury. It was a necessity.

The Risk of Scanner-Centric Alternatives

In the wake of Cisco’s announcement, Kenna customers are hearing pitches from scanner vendors claiming their platforms can replace Kenna’s functionality. These claims deserve scrutiny.

Scanner platforms, by definition, are not independent governance layers. Moving from Kenna to a scanner-centric alternative introduces several concerns:

Prioritization bias. When the same vendor both detects vulnerabilities and prioritizes them, there’s an inherent tension. Scanner vendors have limited visibility into findings from competitive tools, which can skew risk calculations.

Reduced cross-tool normalization. Kenna customers often aggregate data from a dozen or more security tools. Scanner platforms typically excel at their own telemetry but struggle to normalize and deduplicate findings across a heterogeneous toolset.

Increased vendor lock-in. Consolidating on a scanner vendor’s platform ties your vulnerability management program to their detection capabilities, pricing, and product roadmap. At a time when flexibility and tool choice matter more than ever, this trade-off deserves careful consideration.

Kenna customers chose a scanner-agnostic architecture for good reasons. This EOL announcement doesn’t change those reasons.

Replacing an independent platform with a scanner-centric one isn’t a migration, it’s a step backward in vulnerability management maturity.

What Modern Unified Vulnerability Management Requires

The security environment has evolved significantly since Kenna first popularized risk-based vulnerability management. Enterprise attack surfaces now span:

• Traditional infrastructure and endpoints
• Multi-cloud environments and containers
• Application code and APIs
• Software supply chains and third-party components
• AI-generated code and embedded AI features

A modern unified vulnerability management platform must address all these domains while maintaining the architectural independence that made Kenna effective. It also needs capabilities that didn’t exist when Kenna was at its peak: automated remediation workflows, software supply chain security, and the ability to process findings at cloud scale.

According to Mordor Intelligence, the security and vulnerability management market will grow from $16.75 billion in 2025 to $22.91 billion by 2030. Risk-based analytics now outrank raw severity scores as the primary prioritization method, a validation of the approach Kenna pioneered. However, the research also shows that three-quarters of organizations want fewer security suppliers, pushing the market toward platforms that can consolidate visibility without creating new silos.

How ArmorCode Can Help

ArmorCode was built to serve the same architectural role Kenna pioneered, as an independent, scanner-agnostic governance layer, but designed for today’s enterprise requirements.

For organizations evaluating their post-Kenna options, ArmorCode provides:

Scanner-agnostic unification. With 325+ native integrations, ArmorCode normalizes vulnerability and exposure data across infrastructure, cloud, containers, endpoints, application security, software supply chain tools, and embedded AI. Teams can consolidate findings from their existing security investments without rip-and-replace migrations.

AI-driven risk scoring. ArmorCode’s adaptive risk scoring correlates findings with threat intelligence, exploitability data, asset context, and business criticality. This approach focuses remediation effort on what actually matters rather than what scores highest on a single vendor’s severity scale.

Automated remediation workflows. Bi-directional integrations with Jira, ServiceNow, and Azure DevOps enable automated ticket creation, assignment, and tracking. No-code runbooks allow security teams to encode their remediation logic without custom scripting.

Software supply chain coverage. Automated SBOM ingestion and analysis extends visibility into third-party components, an area increasingly targeted by attackers and increasingly regulated by frameworks like the EU Cyber Resilience Act.

Rapid onboarding. ArmorCode’s integration library means most organizations can begin consolidating vulnerability data within days rather than months. For Kenna customers facing a transition deadline, speed matters. ArmorCode’s agentic AI, Anya, replaces dashboard navigation with natural language queries so customers can gain intuitive security insights quickly.

A Path Forward Without Compromise

Kenna’s end of life doesn’t mean the end of independent, risk-based vulnerability management. The principles Kenna established, normalize data from diverse sources, prioritize based on real exploitability, align security and IT around actionable intelligence, remain sound.

What has changed is the scope of the problem. Today’s security teams need that independent governance layer to extend across application security, cloud security, software supply chain, and emerging AI risks. They need platforms that can process billions of findings, not millions. And they need automation that turns prioritized risks into tracked remediation actions.

Organizations that use this transition as an opportunity to modernize, rather than simply replicate what they had, will emerge with stronger, more unified vulnerability management programs.

The end of Kenna isn’t the end of independent RBVM. It’s a chance to extend those principles across the expanded attack surface that defines enterprise security in 2025 and beyond.For Kenna customers ready to continue their independent vulnerability management approach with a platform built for current enterprise realities, request a demo to see how ArmorCode can support your transition.