The Question
Your organization has been running a vulnerability management program for years. You have Tenable, Qualys, or Rapid7 deployed. Scanners are configured. You run weekly or monthly scans, score findings against CVSS, and feed the highest scores into a patching workflow that IT operations executes on a quarterly cadence. Compliance auditors are satisfied. The CISO can produce a dashboard showing open critical CVE counts trending downward.
Now the board wants to know whether the organization is actually reducing breach risk — not just managing vulnerability backlogs. Leadership has read the Gartner CTEM guidance. They're asking why a competitor was breached despite a mature patching program. The question lands on your desk: how do we evolve what we have into Continuous Threat Exposure Management?
The instinct from many vendors is to tell you that you need a new platform. That your existing VM tools are insufficient. That CTEM requires a different architecture and a new budget cycle.
That instinct is wrong — or at least premature.
The VM-to-CTEM evolution is not a rip-and-replace. It is a capability addition sequence that makes your existing VM investment more effective at each step while building toward the full CTEM program.
Why This Matters Now
In early 2025, a mid-sized financial services firm suffered a ransomware incident that cost it an estimated $47 million in recovery costs, regulatory fines, and business interruption. Post-incident forensics revealed the attackers had entered through a VPN appliance vulnerability that had been publicly disclosed six months earlier and was listed on the CISA Known Exploited Vulnerabilities catalog. The CVE had a CVSS score of 7.2 — classified as high severity but not critical. It had not surfaced at the top of the patching queue.
The CVSS score was accurate. The appliance had a limited blast radius in isolation. What CVSS did not capture was that the appliance sat at the perimeter of a flat network segment that provided lateral movement paths to the payment processing environment. In a risk-based prioritization model that accounted for asset criticality and attack path context, this finding would have ranked as a critical remediation priority.
This is the gap that Continuous Threat Exposure Management is designed to close. CVSS was designed to score vulnerability severity in isolation. It was not designed to score exposure risk in the context of your specific environment, your specific asset topology, and your specific crown jewels. The CISA KEV catalog is the signal that CVSS was never built to produce: these vulnerabilities are being actively exploited in the wild, right now, against organizations like yours.
The financial services firm had a functioning VM program. It was measuring the wrong things, in the wrong order, with the wrong context. The evolution path is not to discard what they had — it is to add the layers of context that would have surfaced this finding correctly.
What the CURVE™ Data Shows
The 2026 Stackcurve CTEM CURVE™ Report evaluated vendors across the VM-to-CTEM evolution stack, specifically assessing how well incumbent VM platforms have extended toward full CTEM capability sets versus purpose-built CTEM platforms.
Tenable One rated highest among VM-origin platforms for completeness of CTEM evolution — combining Tenable.io vulnerability management, Tenable.asm for external attack surface discovery, and Tenable Lumin for risk-based prioritization and asset criticality scoring within a single platform. Enterprises already running Tenable have a credible path to CTEM stages 1–3 without a platform change.
Qualys TruRisk Platform similarly integrates CSAM (cyber asset management), VMDR (vulnerability management, detection, and response), and patch management into a unified risk score, making it a strong evolution path for Qualys-baseline organizations.
Rapid7 Command Platform offers a more modular evolution — InsightVM for core VM, Surface Command for EASM, and threat intelligence integrations — though the platform cohesion rated lower than Tenable and Qualys in our assessment.
For attack path analysis (Stage 4 of the evolution sequence below), purpose-built vendors — XM Cyber, Microsoft Security Exposure Management, and Palo Alto Cortex Attack Path Analysis — rated higher than any VM-origin platform in path visualization and crown jewel mapping.
The full vendor rankings are in the 2026 Stackcurve CTEM CURVE™ Report — free to download.
The Gap Most Buyers Miss
The gap most organizations miss when planning a VM-to-CTEM evolution is sequencing. They either attempt to implement CTEM capabilities all at once — which creates a sprawling, uncoordinated tool deployment that solves nothing — or they conflate CTEM with a single tool purchase. The evolution is five discrete steps, each delivering independent value before the next is added.
Step 1: Add exploitability context to existing VM findings. Enable EPSS (Exploit Prediction Scoring System) scoring alongside CVSS in your existing VM platform. Cross-reference open vulnerabilities against the CISA KEV catalog. Tenable, Qualys, and Rapid7 all support this natively. This single change — filtering your remediation queue by CISA KEV first, then by EPSS score above 0.4, then by CVSS — will transform your patching prioritization without a single new tool purchase. Implementation time: two to four weeks.
Step 2: Add external attack surface visibility. Deploy EASM capability — either through your existing VM platform (Tenable.asm, Qualys CSAM) or a standalone EASM tool — to discover internet-facing assets that are not in your current VM scan scope. This is the asset discovery problem that precedes everything else: you cannot assess exposure on assets you don't know exist. The first CTEM assessment cycle should focus exclusively on internet-facing assets. This is the highest-priority scope and the entry point for most attackers.
Step 3: Add asset criticality context. Map your VM asset inventory to business criticality. This step is organizational, not technical — it requires a conversation with business stakeholders to identify which systems support crown jewel processes. A CVE on a payment processing server is categorically different from the same CVE on a development server with no production access. Without criticality context, your VM data is risk-blind.
Step 4: Enable attack path analysis. Once you have internet-facing asset coverage and criticality context, add path-based prioritization. XM Cyber, BloodHound Enterprise (for Active Directory lateral movement paths), and Microsoft Security Exposure Management all provide attack path visualization that shows which vulnerabilities are steps in paths leading to crown jewel systems. This is where CTEM diverges most sharply from traditional VM — a medium-CVSS vulnerability on a path to a critical system outranks a critical-CVSS vulnerability with no path to anything important.
Step 5: Add validation. Deploy BAS (Breach and Attack Simulation) to validate that prioritized findings, once remediated, are actually closed — and that your security controls would block the attack paths identified in Steps 3 and 4. Pentera for network-based validation, Cymulate or AttackIQ for broader kill-chain coverage.
Questions Your Buying Team Should Be Asking
1. Does our existing VM platform natively support EPSS scoring and CISA KEV cross-referencing, and is it currently configured to surface these signals in our remediation queue? This is the first question because it determines whether Step 1 of the evolution requires any budget at all. Most Tenable, Qualys, and Rapid7 deployments have this capability enabled but not prioritized in the remediation workflow. The cost is configuration time, not new tools.
2. What percentage of our internet-facing asset inventory is covered by our current VM scan scope, and how are we discovering assets that were deployed outside the standard provisioning process? Shadow IT and developer-deployed cloud infrastructure routinely fall outside scan scope. If your EASM coverage is below 100% of known internet-facing assets, you have a discovery gap that is the first priority to close before any other CTEM capability adds value.
3. Has our organization completed an asset criticality mapping that assigns business risk scores to the systems in our VM inventory, and is that mapping current? A criticality mapping that was completed two years ago and has not been updated since a major cloud migration or acquisition is unreliable. The technical step of deploying risk-based prioritization is only as good as the business input that defines criticality.
4. When we identify an attack path from an internet-facing asset to a crown jewel system, who owns the decision to remediate versus accept risk — and what is the decision-making timeline? This is an organizational question that many security teams discover only after deploying attack path analysis. The finding is clear; the ownership is not. Defining this decision authority before deploying path analysis prevents findings from stalling in organizational ambiguity.
5. If a vendor proposes replacing our existing VM platform with a new CTEM platform, can they demonstrate that the migration plan preserves existing scan configuration, asset inventory history, and integration with our ITSM ticketing system? The VM baseline is an investment — years of tuned scan configurations, asset inventory, and integrated workflows. Any vendor proposing replacement rather than evolution needs to demonstrate a credible migration path. Platform migration risk is frequently underestimated in CTEM purchase decisions.
The Stackcurve Take
Most organizations that contact us about CTEM have a functioning VM program that is generating more data than they are acting on effectively. The problem is almost never insufficient vulnerability data. It is insufficient prioritization context — specifically, the absence of exploitability signals (EPSS, CISA KEV), asset criticality weighting, and attack path awareness that distinguishes high-breach-risk exposures from low-risk vulnerabilities occupying the same CVSS tier.
The five-step evolution sequence above is additive at every stage. Tenable One, Qualys TruRisk, and Rapid7 Command Platform have all extended toward CTEM capability in ways that allow existing customers to evolve without platform replacement. Purpose-built CTEM tools (XM Cyber, Pentera, AttackIQ) add genuine value at Steps 4 and 5 — but they build on top of the VM baseline, not in replacement of it.
The organizations that struggle with this evolution are not the ones with the wrong tools. They are the ones without a sequenced plan — deploying capabilities out of order, adding attack path analysis before they have asset criticality context, or running BAS validation before they have a remediation workflow that can act on findings.
The sequence is the strategy.
The 2026 Stackcurve CTEM CURVE™ Report covers the full VM-to-CTEM platform landscape, including head-to-head ratings for Tenable One, Qualys TruRisk, Rapid7, XM Cyber, and purpose-built CTEM platforms across all five evolution stages. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.