The Question
The security team has been running Tenable or Qualys for years. Vulnerability scans run weekly. The critical CVEs get patched. The compliance audits pass. The CISO asks: do we need CTEM, or do we already have it?
This question surfaces in nearly every enterprise security planning cycle right now. Gartner named CTEM a top security and risk management trend beginning in 2022, and the market has responded with a flood of vendor claims — most of which position existing vulnerability management tools as CTEM-ready with a software update. The enterprise security leader trying to make a real investment decision is navigating genuine category confusion.
The answer to the CISO's question is almost always: you have the data collection layer, but not the analytical framework that makes it a CTEM program. Vulnerability management tells you what is broken. CTEM tells you what an attacker would do with it. These are not the same question, and answering the second one requires a fundamentally different set of inputs, prioritization logic, and operational processes than the first.
CTEM does not replace vulnerability management — it provides the context that makes vulnerability management decisions correct, by adding attacker perspective to the asset-centric view that VM provides alone.
Why This Matters Now
In January 2024, Ivanti disclosed critical vulnerabilities in its Connect Secure VPN appliances — CVE-2023-46805 and CVE-2024-21887 — with CVSS scores of 8.2 and 9.1 respectively. Both were being actively exploited in zero-day campaigns targeting government agencies and critical infrastructure before patches were available. The Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive requiring federal agencies to disconnect affected products.
What made this incident instructive for the CTEM discussion is what happened next: organizations that had mature vulnerability management programs knew they had Ivanti Connect Secure appliances. They had CVE data. What many did not have was the attack path context to understand that their Ivanti appliances were the single authentication gateway for their entire remote workforce — meaning exploitation did not lead to one compromised device, it led to authenticated access to everything behind that gateway.
The CVSS score told security teams the vulnerability was high severity. The CTEM question — what does exploitation of this vulnerability enable an attacker to reach, in what sequence, with what downstream impact — was not answerable from vulnerability scan data alone. Organizations that had mapped their authentication dependencies, their network segmentation, and their blast radius from gateway compromise responded faster and more effectively than those working from CVE lists.
The 2024 Verizon Data Breach Investigations Report found that 14 percent of confirmed breaches involved vulnerability exploitation as the initial access vector. Of those exploited vulnerabilities, a disproportionate share carried CVSS scores below the thresholds many organizations used as their prioritization cutoffs — because the relevant characteristic was not technical severity, it was position in the network and proximity to high-value targets.
What the CURVE™ Data Shows
The 2026 Stackcurve CTEM CURVE™ Report evaluated 22 vendors across five CTEM capability dimensions: attack surface discovery, vulnerability prioritization, attack path analysis, validation, and remediation workflow integration.
The central finding: the vendors that score highest on CTEM program outcomes are not always the vendors with the broadest vulnerability scanning coverage. Tenable One leads in integrated context — its Lumin risk scoring combines asset criticality, exposure context, and threat intelligence into a prioritized exposure score that operationally reduces the remediation backlog more than raw scan coverage does. Qualys TruRisk takes a similar approach with business risk quantification built directly into its prioritization output.
On the attack path analysis dimension — the capability that most cleanly separates CTEM from VM — XM Cyber and Pentera score highest, with Cymulate competitive in validated exploitation scenarios. Palo Alto Cortex Xpanse leads in external attack surface discovery, identifying externally exposed assets that internal scanning tools miss by design.
The vendors most commonly deployed in enterprises calling their program "CTEM" without the attacker-perspective analysis layer are traditional VM platforms — Tenable.io and Qualys VMDR — running without the context modules that enable CTEM-level prioritization. These platforms can underpin a CTEM program, but not without the additional configuration and integration work that moves them from asset-centric scanning to attacker-centric analysis.
The full vendor rankings are in the 2026 Stackcurve CTEM CURVE™ Report — free to download.
The Gap Most Buyers Miss
CVSS Was Not Designed to Answer the Question CTEM Asks
The Common Vulnerability Scoring System measures the technical severity of a vulnerability in isolation. A CVSS 9.8 score means the vulnerability is technically critical — typically: it is remotely exploitable, requires no authentication, has low complexity, and results in complete compromise of confidentiality, integrity, and availability. What it does not measure: whether there is a working exploit in active use, whether the vulnerable system is internet-facing, whether the system is accessible from an attacker's initial foothold, or whether exploitation leads anywhere interesting from an attacker's perspective.
An organization with a CVSS 9.8 vulnerability on a system that is air-gapped, has no lateral movement path to any business-critical asset, and has no working public exploit faces less actual risk from that vulnerability than it faces from a CVSS 5.5 vulnerability on its internet-facing authentication proxy that has an active Metasploit module and sits directly in front of the finance system.
CVSS-only prioritization systematically produces the wrong remediation order.
The Exploitability Gap Is Measurable
CISA's Known Exploited Vulnerabilities (KEV) catalog, launched in November 2021, publishes CVEs with confirmed active exploitation. As of early 2026, the KEV catalog contains over 1,200 entries. The median CVSS score of KEV entries is lower than the median CVSS score of non-KEV high-severity vulnerabilities — meaning that the vulnerabilities attackers are actually using are, on average, less severe by CVSS rating than the vulnerabilities security teams are prioritizing based on CVSS alone.
The Exploit Prediction Scoring System (EPSS), developed through the FIRST organization, provides a probability score for whether a CVE will be exploited in the next 30 days, calibrated against actual exploitation telemetry. Applying EPSS as a secondary filter after CVSS dramatically concentrates remediation effort on vulnerabilities with active exploitation probability rather than theoretical severity.
Attack Path Context Is the Differentiating Input
The insight that drives CTEM's value proposition: a vulnerability's risk is not intrinsic to the vulnerability — it is a function of the vulnerability's position in the attacker's path to a target. Two identical CVEs on two different systems carry different remediation priority based entirely on what the attacker can reach after exploitation.
Attack path analysis tools — XM Cyber's attack path management, Pentera's automated penetration testing, Microsoft Security Exposure Management's enterprise attack graph — map the chain from initial access positions to crown jewel assets, identifying which vulnerabilities represent links in viable attack chains versus which exist in dead ends.
Questions Your Buying Team Should Be Asking
1. Does your current vulnerability management workflow incorporate exploitability data from CISA KEV and EPSS, or does it prioritize exclusively on CVSS score?
If the answer is CVSS-only, the organization is making remediation decisions without the most operationally relevant input available. CISA KEV is free, maintained by the federal government, and reflects actual attacker behavior. EPSS is free and updated daily. A program that does not incorporate both is not practicing CTEM-grade prioritization regardless of what tools are deployed.
2. Can your current toolset produce an attack path from an assumed external compromise to your three most critical business assets?
This question separates CTEM capability from vulnerability management capability. The answer requires: knowledge of the external attack surface, network topology and segmentation data, identity and access relationships, and a graph model of the environment. Most vulnerability scanners cannot produce this output. If the answer is "no," the gap is in attack path analysis capability, not in scanning coverage.
3. How does your vulnerability prioritization change when a new CVE is added to CISA KEV?
A mature CTEM program has an automated workflow triggered by KEV additions: identify all instances of the newly listed CVE in the environment, apply asset criticality and exposure context, and generate a prioritized remediation task. If the answer is "we check manually" or "we wait for the next scan cycle," the operational process is not yet CTEM-grade.
4. What percentage of your open vulnerability backlog has been validated as exploitable in your specific environment?
The distinction between "this vulnerability exists" and "this vulnerability is exploitable given our network segmentation, patch state, and compensating controls" is where remediation effort is either focused or wasted. Breach and attack simulation tools — Pentera, Cymulate, AttackIQ — validate this distinction at scale. If the answer is zero percent, the remediation queue may contain significant effort directed at unexploitable vulnerabilities.
5. Who owns remediation, and how are CTEM findings connected to their workflow?
CTEM programs frequently stall not because the security analysis is wrong but because the remediation process is broken. Security owns the finding; IT operations owns the patch deployment; neither has a shared SLA or escalation path. If findings from your exposure management tooling do not flow automatically into ServiceNow or Jira tickets with defined owners and due dates, the program has an operationalization gap that no additional scanning capability will fix.
The Stackcurve Take
Vulnerability management and CTEM are not competitors — they are sequential layers of the same program. The organization that abandons its VM tooling in favor of a CTEM platform loses its foundational data collection. The organization that calls its VM program a CTEM program because it runs regular scans is missing the attacker-perspective analysis layer that makes the data actionable.
The practical path for most enterprises: start with the prioritization layer. Take your existing Tenable or Qualys scan data and add CISA KEV filtering, EPSS scoring, and asset criticality context. This single operational change — moving from CVSS-only to a layered prioritization model — concentrates remediation effort more effectively than any increase in scanning coverage. It does not require a new platform purchase. It requires a new prioritization workflow.
The attack path analysis and validation stages are where purpose-built CTEM vendors — XM Cyber, Pentera, Cymulate — deliver capability that traditional VM platforms cannot. But these capabilities build on a prioritization foundation. Organizations that invest in attack path analysis before fixing their prioritization process get sophisticated analysis of the wrong attack paths.
CTEM is a program discipline, not a product category. The buyers who understand this make better vendor selection decisions than the buyers evaluating tools before they have defined the operational workflow the tools need to support.
The 2026 Stackcurve CTEM CURVE™ Report covers the full vendor landscape across all five CTEM capability dimensions, with detailed scoring on how each platform performs at each stage of the Gartner CTEM model. 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.