McAfee Vulnerability Manager, BeyondTrust Enterprise Vulnerability Manager, and now Cisco Vulnerability Management has given up. Another one bites the dust. The history of vulnerability management (VM) is a graveyard of vendors who tried to expand into the space, only to realize it is the “easiest-looking hard category” to crack.
Even after 25 years, the “Big Three” Tenable, Qualys, and Rapid7 continue to reign supreme. Contrast that with EDR, Identity or any other category where five or more hardcore competitors battle for dominance. In VM, many claim to compete (think MSFT, CRWD), but most remain a side show or a mere checkbox. They neither have the breadth nor the depth. In this post, I explore why this category is so deceptively difficult to disrupt, where the incumbents are vulnerable, and why the path to scale now requires alignment with the industry’s biggest players or the newest players.
Why Vuln Management is the Easiest, Hard Category to Crack
Vulnerability Management (VM) is deceptively simple in theory but brutal in execution. It is not a category where you can “MVP” (Minimum Viable Product) your way to the top.
While startups and enterprises have successfully nibbled at the edges for e.g focusing on prioritization (as Kenna Security did well) or remediation orchestration (as ServiceNow VR does well) they eventually hit a wall. To dominate this space, you must own two additional aspects: Vulnerability Signatures (content) and the sensors or scanner to detect vulnerabilities. Without these you are always at the mercy of someone else’s telemetry.
The Kenna-Cisco Cautionary Tale
The fatal mistake Cisco made in its acquisition of Kenna was a classic “spreadsheet-over-substance” error. My guess is they looked at revenue and customer counts through a business school lens, assumed the product was a complete VM solution. However, they soon realized that Kenna lacked its own proprietary scanning engine and signature library. And what they had in hand was a wrapper for VM solution, not a VM solution at all.
To make the platform truly functional at scale, Cisco likely found itself at a crossroads: either partner with the “Big Three” legacy vendors to access their sensors and signatures essentially paying their competitors or build a quarter-century’s worth of content and sensors from scratch. As the original Kenna team departed, the product was left as a “hollow skeleton,” lacking the deep technical depth required to compete in a complex enterprise environment. The only best option remaining was to cut your losses and run ;).
Why is content and sensors key to Vuln Mgmt?
In most categories being modern is an advantage, but in Vulnerability Management (VM), however, antiquity is a superpower. The vulnerability signatures content have been built over 25 years, and they are hard to replicate. Why does that matter in today’s age? Because it’s just not a database, it’s institutional memory.
Look deep into any large enterprise, university, or government agency, and “dinosaur” systems will inevitably emerge. Windows 2000, Server 2008, and ancient Unix builds often run the most critical, “untouchable” infrastructure. These organizations cannot decommission these assets; instead, they pay for Extended Security Updates (ESU) bespoke, expensive patches for End-of-Life software. Since these vendors have been around for a long time, they naturally support all the dinosaurs and their offspring.
Legacy issues aren’t confined to old hardware or software. In the world of containers and DevSecOps, old, vulnerable libraries are frequently “packaged forward” into modern images. A brand-new Kubernetes pod might be running a 10-year-old library with a well-documented flaw. Without a deep, historical library of content, modern scanners miss these “zombie” vulnerabilities hidden in plain sight.
Your VM tool must possess the “long tail” of signatures required to audit these legacy systems, modern systems and everything in between. Otherwise it risks providing a false sense of security.
I am not saying this is the only key value prop of a VM tool, but these small details matter a lot especially when dealing with large enterprise accounts.
And then there are sensors. The way you detect vulnerabilities is completely different on container image vs traditional on prem system, To do this well, a vendor must have a dedicated sensor for each form factor. Agents for persistent monitoring of workstations. Network Scanners for the “un-agentable” legacy hardware. Side-scanning or API-based sensors for ephemeral cloud workloads. If you don’t own the sensor for a specific environment, you risk missing an entire category of risk.
To be a true VM solution one should be able to assess risk accurately across every possible attack surface. And doing that is hard.
Rip & Replace in Vulnerability Management is a Bitch
If that wasn’t hard enough winning new business in VM when there is an established player is not trivial.
In the world of enterprise security, few things are as painful as replacing an incumbent Vulnerability Management (VM) vendor. Even if you have the “finest” product on the market, you aren’t just fighting a competitor, you are fighting organizational inertia, which is in a league of its own.
Unless a tool fails catastrophically during a crisis (like Log4Shell) or reports such erroneously high false positives that someone’s job is put at risk, companies simply don’t switch.
Here is why:
Muscle Memory. Enterprise VM is not just a tool; it is a sprawling set of established processes. Over years, organizations build rigid workflows around how vulnerabilities are reported, triaged, and handed off to IT for patching. Bringing in a new vendor risks throwing all that operational “muscle memory” out the window.
The Data Discrepancy Gap. The biggest hurdle to a “Rip and Replace” is the reporting delta. If you switch from Vendor A in Q1 to Vendor B in Q2, the numbers will change. And in a corporate environment, a change in numbers requires an explanation:
If the vulnerability count goes up: Leadership asks, “Were we insecure this whole time? Why did the previous tool miss this?”
If the vulnerability count goes down: The patching teams ask, “Were we chasing false positives for the last three years? Did we waste thousands of man-hours on pointless work?”
If you are the decision maker you loose either way. It’s best to keep your head down, suffer through the pain, wait for a crisis and then strike when the time is right.
Inertia is the ultimate incumbent. In VM, the best product doesn’t always win. The product that is already integrated into existing systems and requires the least amount of changes usually wins.
The Vulnerability Management Vendor’s Vulnerability
The pun is intended, because even though the VM category is notoriously difficult to disrupt, the incumbents are far from safe. The same “antiquity” that acts as a superpower is also becoming a weight. Here are the core challenges threatening the VM giants today.
The Democratization of Signatures via AI
For decades, the competitive differentiator for VM vendors was their massive, manually curated signature libraries. AI is changing that. When vulnerability signature creation and real-time exploitation can be automated, the “25-year head start” begins to lose its luster. If an AI can analyze a patch and generate a detection script in seconds, the proprietary library becomes a commodity.
The Explosion of AI-Generated Code
We are entering an era of “coding agents” where billions of lines of code are being generated at a velocity humans cannot match. A traditional VM is built to track software written by humans. How does a legacy vendor maintain a “long tail” of coverage when the volume of new, machine-written software is expanding exponentially? The sheer scale of tracking vulnerabilities in non-human-authored code will break traditional, manual research models.
Legacy Architecture vs. AI-Native Architecture
Legacy VM tools are deterministic, and the future may require probabilistic heuristics driven by AI. Instead of a one-size-fits-all model they may have to transition to one-size-fits-one to deliver custom outcomes to their customers.
The Achilles’ Heel: Transitioning from a rigid, deterministic engine to a flexible, AI-native platform is not a trivial update; it’s a total rebuild.
Outcome over Output: Legacy products have become notoriously bloated and complex. A new generation of users will instinctively choose a tool that is easier to use and delivers outcomes (actual risk reduction) rather than just outputs (a 500-page PDF of vulnerabilities).
Death By Add-Ons vs Solutions
Perhaps the biggest vulnerability are the VM vendors themselves. Many VM vendors have stopped listening to their customers. If they did, Kenna would have no reason to exist. Yearly contract renewals have devolved from strategic partnerships into “What else can I sell you?” sessions.
The Typical Conversation:
Customer: “My team is drowning in manual work. Can you fix this specific workflow issue?”
Vendor: “I’ll log a feature request. But while I have you, have you seen our new $10,000-a-year Threat Intel add-on? Or our new AI-wrapper module?”
When vendors prioritize “the next shiny object” (SOAR, specialized AI modules, etc.) over fixing the core user experience, they breed deep customer frustration. In a market where inertia is the only thing keeping customers from leaving, that frustration is a ticking time bomb.
The Strategic Exit: Get Bought or Get Rebuilt
For the “Big Three” and other legacy VM players, the window of opportunity is narrowing. As AI commoditizes their historical advantage, there are only two sustainable paths forward: integration into the massive data ecosystems or a radical AI-native pivot.
The Hyperscale Exit: Playing a Bigger Game
The most logical “way out” for a legacy vendor is to get acquired by a Hyperscaler (AWS, Azure, Google Cloud) or a Data Intelligence giant like Databricks. In late 2025, Databricks officially moved into the arena with its Data Intelligence for Cybersecurity platform. These data giants don’t want to build 25 years of “dinosaur” signatures from scratch, but they do have the AI infrastructure to process that telemetry at a scale no standalone vendor can match.
By aligning with a hyperscaler, a VM vendor can transform its “institutional memory” into a feature of a much larger, automated security fabric. This year Google bought Wiz to shore up their cyber security solutions. So the interest is definitely there.
The Defensive Pivot: Acquire to Survive
If they choose to stay independent, incumbents must aggressively acquire or partner with AI-native startups to shore up their defenses. ServiceNow recently acquired Armis for 7.75B. Although IMHO they would have been better off one buying one of the big three. For roughly 8B any one of them would have happily obliged.
Transitioning a legacy product into an AI-native powerhouse requires more than a branding update or a press release; it requires investment, patience, and a deeply technical AI-native team and architecture.
Closing Thoughts
The window is closing. As AI-native offensive tools begin exploiting vulnerabilities at “machine speed,” a legacy scanner that waits for a human to write a signature will become a liability. The market is shifting from “Vulnerability Management” to “Continuous Exposure Management.” The question isn’t whether the category will change, but who will have the courage to jump into the new era first.