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 the end-of-life of its Vulnerability Management platform, formerly Kenna Security. The product reached end-of-sale on March 10, 2026, and is scheduled to reach its last date of support on 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 that built their vulnerability programs on Kenna’s independent, scanner-agnostic foundation, this announcement raises an urgent question: how do you move forward without sacrificing the architectural principles that made Kenna effective?

Where Kenna Is in Its End-of-Life Timeline

Cisco’s end-of-life timeline has entered its final phase. New purchases and contract renewals are no longer possible, leaving existing customers with support through June 30, 2028 to complete their migration to an alternative platform.

• End of Sale (Completed): March 10, 2026. New subscriptions are no longer available.
• End of Contract Renewals (Completed): June 11, 2026. Existing subscriptions can no longer be renewed or extended.
• End of Support: June 30, 2028. After this date, Cisco will no longer provide technical support or software maintenance.

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.

With both the end-of-sale and contract renewal milestones now behind us, organizations have less than two years remaining before support ends on June 30, 2028. Enterprise platform migrations often take many months to plan, validate, and execute, making it increasingly important to begin migration efforts well before the support deadline.

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 served as a governance layer above scanning tools, normalizing findings from multiple sources without favoring 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. The challenge is no longer just the number of vulnerabilities. NIST reported that CVE submissions increased 263% between 2020 and 2025, forcing the National Vulnerability Database (NVD) to adopt a risk-based enrichment model because it could no longer provide detailed analysis for every CVE.

The challenge is poised to accelerate even further. Recent advances in AI-assisted vulnerability research, highlighted by Anthropic’s Claude Mythos initiative, point to a future where identifying vulnerabilities becomes faster and more scalable. As AI expands the rate at which vulnerabilities can be discovered, security teams will face even greater pressure to distinguish the handful of issues that truly matter from the thousands that do not. Discovery is becoming easier. Prioritization remains the bottleneck.

The conclusion is clear. Attempting to remediate every vulnerability is neither practical nor necessary. As vulnerability disclosures continue to outpace the capacity of security teams, effective vulnerability management depends on identifying the small subset of issues that present the greatest business risk. 

The Risk of Scanner-Centric Alternatives

In the wake of Cisco’s announcement, Kenna customers are evaluating Kenna Security alternatives, and many 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.

Evolving Beyond Kenna to Unified Exposure Management

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, APIs, and CI/CD pipelines
• Software supply chains and third-party components
• AI-generated code, AI agents, and embedded AI features

A modern Unified Exposure Management (UEM) platform must address all these domains while preserving the architectural independence that made Kenna effective. It must correlate security findings across disparate tools, apply AI-driven risk analysis to prioritize the exposures, incorporate software supply chain and application security posture management (ASPM), and orchestrate remediation across security, development, and IT teams. The goal is to continuously reduce enterprise exposure through a unified governance layer.

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 Helps After Kenna End of Life

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 platform. With 375+ native integrations, ArmorCode normalizes vulnerability and exposure data across infrastructure, cloud, containers, endpoints, application security and software supply chain. Teams can consolidate findings from their existing security investments without rip-and-replace migrations.

Unified Exposure Management (UEM). ArmorCode extends Kenna’s pioneering approach to Risk-Based Vulnerability Management by unifying, prioritizing, and remediating risk across applications, infrastructure, cloud, code, software supply chains, and AI systems.

Adaptive risk scoring. ArmorCode goes beyond severity scores with Adaptive Risk Scoring that normalizes findings across security tools and combines threat intelligence, exploitability, asset context, and business criticality to prioritize risks.

Automated remediation workflows. Bi-directional integrations with Jira, ServiceNow, and Azure DevOps enable automated ticket creation, assignment, and tracking. No-code runbooks orchestrate remediation workflows to reduce manual effort and reduce Mean Time to Remediate (MTTR).

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.

AI Exposure Management (AIEM). ArmorCode provides complete visibility, ownership, and governance for AI tools, models, agents, and AI workflows, eliminating shadow AI while enabling secure AI adoption.

Agentic AI Architecture. The ArmorCode Agentic AI Platform unifies security and business context through the Context Risk Graph, enabling natural language interaction, AI-powered risk analysis and remediation guidance. Purpose-built, role-aware AI agents assess, prioritize, remediate, and automate security workflows using this unified organizational context.

A Path Forward Without Compromise

Kenna’s end of life doesn’t mean the end of independent, risk-based vulnerability management. The principles that made Kenna effective, including normalizing data from diverse sources, prioritizing based on real-world exploitability, and aligning security and IT around actionable intelligence, remain just as relevant today.

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 security, and emerging AI risks. They need platforms that can process billions of findings, not millions. They also need automation that transforms prioritized risks into tracked remediation actions.

The emergence of frontier AI models like Claude Mythos marks another fundamental shift. AI can now discover vulnerabilities at a scale and speed no human team can match. The challenge is no longer discovering more vulnerabilities – it is operationalizing remediation before growing backlogs become growing exposure. In the AI era, security programs won’t be defined by how many findings they generate, but by how effectively they prioritize, orchestrate, and remediate the small percentage of exposures that truly matter.

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

The end of Kenna isn’t the end of independent security governance. It’s an opportunity to extend the principles that made Kenna successful across today’s broader attack surface and evolving threat landscape.

For Kenna customers looking to preserve the independence they valued while modernizing their security operations, request a demo to see how ArmorCode can support your transition to Unified Exposure Management. For a deeper dive, download our Kenna Security End-of-Life Use Case Brief.

Frequently Asked Questions

When is Kenna end of life?

Kenna reached end-of-sale on March 10, 2026, and its end of contract renewals passed on June 11, 2026. Cisco will continue technical support and software maintenance until June 30, 2028, after which Kenna reaches full end of life and the product becomes unsupported.

Why is Cisco discontinuing Kenna?

Cisco has not published a detailed rationale beyond confirming the sunset of Cisco Vulnerability Management, Vulnerability Intelligence, and the AppSec module (formerly Kenna.VM, Kenna.VI, and AppSec). Cisco has confirmed no new features, connectors, or algorithm updates will be developed, and the platform will not support newer frameworks like CVSS 4.0 or EPSS v4.

Is there a replacement for Kenna?

Cisco’s own bulletin states there is “no replacement available” from Cisco directly. Kenna customers are instead evaluating third-party alternatives, either scanner vendors adding RBVM features, or independent, scanner-agnostic platforms like ArmorCode that preserve the governance-layer architecture Kenna was built on.

What happens to my Kenna data after end of life?

Cisco has not published a data retention or export policy specific to the June 30, 2028 support cutoff. Organizations should plan to complete migration and data export well before that date, since enterprise platform migrations typically take several months to plan and execute.