Cisco Kenna Security end of life: how to replace Kenna Security with modern CTEM-ready unified vulnerability management

Cisco Kenna Security’s end-of-life is not just a bittersweet feeling for me, but also a strategic and procurement problem. Kenna created the first wave of changes in vulnerability management. 

Kenna Security earned its place by forcing the industry to grow up: normalize findings, rank risk based on real-world signals, and stop pretending “critical by CVSS” is a plan. Kenna advanced the second generation of vulnerability management.

I say this with genuine respect. Back in 2019, we ran one of the largest Kenna deployments I had seen, and we loved the core idea: independent vulnerability management, scanner-agnostic ingestion, and risk scoring that tried to reflect reality.

Then reality changed.

The modern attack surface is not “hosts and patches.” It is code, libraries, build files, base images, CI pipelines, Kubernetes drift, cloud identity, runtime exposure, and the messy chain that connects them. Those assets have complex graph relationships and business organizational relationships. Without attribution, code-to-cloud context, and remediation intelligence, risk-based scoring becomes a dashboard exercise.

Cisco’s announcement makes the next step unavoidable: plan your exit, retain the architectural principles that worked, and transition to a unified vulnerability management model aligned with CTEM.

---

Kenna Security end of life: the dates that matter (and what stops improving)

Cisco has published the formal end-of-life notice for Cisco Vulnerability Management, Vulnerability Intelligence, and the Application Security Module (formerly Kenna VM, Kenna.VI, and AppSec). Together with the sunsetting of the cloud security suite , Cisco is going out of the code to cloud and vulnerability business to refocus on data center and networking business.

Key milestones:

• End-of-Life announcement date: December 10, 2025
  
• End-of-Sale (last day to buy): March 10, 2026
  
• End of renewal/change (last day to renew or extend): June 11, 2026
  
• Support will slowly degrade with the last date of support: June 30, 2028
  

Now, the part most teams miss on first read: Cisco explicitly states the platform will not get the updates you need to stay current.

Cisco says it will no longer provide new features, development, connector updates, or algorithm updates; the Cisco Security Risk Score algorithm will not change, and Cisco will not add support for CVSS v4 or EPSS v4. It also states there is no replacement available at this time. 

That matters because:

• CVSS v4.0 has been officially published (Nov 1, 2023).
  
• EPSS v4 has been released (March 17, 2025).
  

So you are looking at a risk engine that cannot track the scoring standards, which are now legacy.

---

Why Kenna Security mattered (and why it hits the ceiling in 2026)

Kenna was a statement: vulnerability management should be independent of scanners, and risk should be treated as a measurable program, not a ticket factory.

It also pushed the industry toward:

• exploitation-aware thinking
• threat intel enrichment
• program KPIs that security leaders could defend in front of a board
  

In 2019, that was already not enough for teams operating modern delivery and cloud stacks. Not because Kenna was “bad,” but because the VM category needed to expand:

• Aggregate across code, cloud, container, and infrastructure
• Attribute ownership to teams and services, business units and organizational structure, not “asset groups”
• Prioritize using exposure + reachability + exploitability, not just a variation of CVSS severity
• Remediate with actions that reduce the attack surface fast, not generic patch advice
  

Since then, I’ve had the pleasure of working with leaders like Jay Jacobs on EPSS and spending far too many happy hours discussing vulnerability data quality with Jerry Gamblin. EPSS is a great example of the industry getting sharper about probability, not panic. 

Kenna helped create that mindset. The next generation is CTEM, unifying attribution of code to cloud assets and proposing remediation. 

Why controlling Risk with a unified Vulnerability and Independent UVM matters today more than when we started

The numbers that matter

• RBVM adoption trend: Risk-Based Vulnerability Management is growing at a 7.1% CAGR [Mordor Intelligence]
• Supply chain “how common” forecast: Gartner predicted 45% of organizations would have experienced software supply chain attacks by 2025, a 3x increase from 2021.
• Supply chain blast radius (packages impacted): Sha1-hulud and react2shell have shown a rapid exploitation (1 day) with rapid adoption by 6+ threat actors
• Open-source malware surge: Sonatype reported a 156% YoY increase in malicious open-source packages, bringing the total to 704,102 since 2019.
• Breach data signaling third-party risk: Verizon’s 2025 DBIR found third-party involvement doubled to 30%.
• Vuln exploitation momentum: Verizon’s 2025 DBIR also reported vulnerability exploitation up 34%, based on 22,000+ incidents and 12,195 confirmed breaches analyzed.
• Economic impact of supply chain attacks: Cybersecurity Ventures estimates $60B (2025) rising to $138B (2031) in annual global costs.
  

---

CTEM is the new bar, and Kenna-style “risk scoring only” is not CTEM

CTEM (Continuous Threat Exposure Management) is Gartner’s push for a program that continuously reduces exposure rather than episodically reports on it. 

CTEM is commonly described as a five-phase loop (scope, discover, prioritize, validate, mobilize), with an emphasis on execution and measurement, not just visibility. 

A CTEM-aligned vulnerability management platform must do more than ingest and score:

• Scope: define what “material exposure” means (apps, crown-jewel services, internet-facing paths)
  
• Discover: unify findings across code, runtime, cloud, containers, and infra (see below the elements that form a CTEM program)
  
• Prioritize: rank by real exploitability + reachability + exposure + business impact
  
• Validate: prove what is actually reachable, deployed, and exploitable in your environment.
  
• Mobilize: drive ownership, SLA policies, security champions, and measurable remediation throughput.
  

If any of those pieces are missing, CTEM collapses into reporting.

---

The trap: “replace Kenna Security” with scanner-centric platforms

Many Kenna customers chose a scanner-agnostic VM for reasons that still hold.

Moving from Kenna to a scanner-centric “platform” often creates predictable failure modes:

1) Prioritization bias and partial telemetry

When the same vendor detects and prioritizes, the model naturally favors what the vendor can see best. Cross-tool correlation becomes secondary.

2) Deduplication breaks at the seams

Scanner outputs do not agree on asset identity, package naming, container lineage, or cloud resources. Without a true governance layer, your “one backlog” becomes five backlogs glued together.

3) Remediation stays generic

Scanners can tell you what is present. They rarely tell you the remediation that yields the biggest attack surface reduction in production:

• Which base image upgrade removes the most reachable container CVEs
  
• which builds file change collapses dozens of SCA findings
  
• Which fix is safe, given where the vulnerable code is actually called
  

4) Ownership becomes politics

Without attribution to services, repos, teams, and security champions, you end up measuring “tickets created,” not “risk retired.”

5) Vendor lock-in becomes the roadmap

Kenna’s value was independence. Replacing it with “one vendor’s worldview” is a maturity regression, not modernization.

---

What a Kenna Security alternative must look like in 2026

If you are shopping for a Kenna Security alternative, use a blunt checklist. A modern unified vulnerability management platform should provide:

Unified ingestion and normalization

• first-class support for heterogeneous tools
  
• asset identity that survives cloud ephemerality
  
• dedupe across SAST, SCA, container, cloud, VM, DAST
  

Code-to-cloud context (the missing link)

• trace vulnerabilities from repo → build → artifact → container → workload → exposed service
  
• reachability signals that separate “present” from “actionable”
  

Modern scoring that evolves

Given Cisco’s statement that Kenna’s algorithm will not change and CVSS4/EPSS v4 will not be added, you need scoring that keeps pace. 

Remediation intelligence, not patch advice

• recommendations tied to deployment context
  
• fixes that collapse duplicates and reduce exposure fastest
  
• evidence of reduction, not promises
  

Operational mobilization

• security champions and ownership mapping
  
• SLAs by business criticality and exposure
  
• metrics that measure throughput and debt burn-down
  

That is CTEM-ready vulnerability management.

---

A practical migration plan to replace Kenna Security without breaking your program

Kenna customers usually have years of tuning in:

• scoring targets and risk acceptance thresholds
  
• asset groups and business criticality
  
• workflow integration with Jira/ServiceNow
  
• executive reporting and KPIs
  

A sane transition keeps those stable while expanding coverage.

Step 1: Lock down your timeline against renewal reality

If you want zero disruption, your plan needs to be real before June 11, 2026 (last renewal date). 

Step 2: Export what matters (not just findings)

Carry forward:

• asset inventory and ownership logic
  
• risk scoring outputs and thresholds
  
• exception policies and rationale
  
• your “definition of done” for remediation
  

Step 3: Rebuild identity and attribution first

Before you migrate prioritization, migrate ownership.

If you cannot map vulnerabilities to teams and services, you will not mobilize.

Step 4: Run dual scoring for a short period

Keep Kenna-style risk targets for continuity, then layer in:

• reachability and exposure (you can adjust those in Phoenix Security)
  
• CVSS, CVSS v4, where available
  
• CTI, EPSS v4, ARGUS and Threat Centric, probability signals (you can adjust those in Phoenix Security)
  

Step 5: Expand scope into code, containers, and cloud

This is where most Kenna migrations either become transformative or become a sideways move.

---

How Phoenix Security helps Cisco Kenna customers transition to unified VM + CTEM

Phoenix Security exists because we hit these limits ourselves and built what we needed internally first, then scaled it.

If you are replacing Kenna Security, Phoenix is designed to keep what worked and extend it into modern CTEM:

• Kenna-style continuity: familiar risk-based scoring and targets, so you do not need to reinvent your operating model on day one.
  
• Unified coverage: code, SCA, containers, cloud, and vulnerability management in one governance layer.
  
• Verification and exposure validation: reduce the gap between “detected” and “reachable in production.” Phoenix Security traceability enables defining exposure and tracing exposure from runtime to code.
  
• Modern scoring: designed to align with evolving standards and to exploit probability signals with the ability to customize risk scoring methods.
  
• Remediation that reduces the attack surface: focus on plans that deliver the highest remediation-to-effort ratio. Phoenix Security focuses on the remediation that matters most e.g., which library needs to be upgraded in which build file, and which container base image needs to be upgraded where, and which file needs to be changed. 

• Security champions and attribution: Phoenix Security’s attribution and team-based structure enable a security champion program focused on remediation metrics and the most significant mistakes across teams.
  

Proof points from public case studies and published results:

• ClearBank: 98% reduction in container vulnerabilities through container throttling and remediation optimization.
  
• Bazaarvoice: drove critical vulnerabilities to zero and reduced high-risk findings by 40% within two weeks of implementation (published by Phoenix).
  
• Integral Ad Science: reported 78% reduction in active container vulnerabilities and reduced SCA-to-container noise through correlation and deduplication.
  

If you are a Cisco client planning a transition before renewal and end-of-life deadlines, Phil Moroni (Head of Sales) can put together a structured migration plan aligned to your timeline.

How Phoenix Security Can Help

Organizations often face an overwhelming volume of security alerts, including false positives and duplicate vulnerabilities, which can distract from real threats. Traditional tools may overwhelm engineers with lengthy, misaligned lists that fail to reflect business objectives or the risk tolerance of product owners.

Phoenix Security offers a transformative solution through its Actionable Application Security Posture Management (ASPM), powered by AI-based Contextual Quantitative analysis and an innovative Threat Centric approach. This innovative approach correlates runtime data with code analysis and leverages the threats that are more likely to lead to zero day attacks and ransomware to deliver a single, prioritized list of vulnerabilities. This list is tailored to the specific needs of engineering teams and aligns with executive goals, reducing noise and focusing efforts on the most critical issues. Why do people talk about Phoenix

• Automated Triage: Phoenix streamlines the triage process using a customizable 4D risk formula, ensuring critical vulnerabilities are addressed promptly by the right teams.

• Contextual Deduplication: Utilizing canary token-based traceability, Phoenix accurately deduplicates and tracks vulnerabilities within application code and deployment environments, allowing teams to concentrate on genuine threats.

• Actionable Threat Intelligence: Phoenix provides real-time insights into vulnerability’ exploitability, combining runtime threat intelligence with application security data for precise risk mitigation.

By leveraging Phoenix Security, you not only unravel the potential threats but also take a significant stride in vulnerability management, ensuring your application security remains up to date and focuses on the key vulnerabilities.