The Question
Your CTEM program has been running for eighteen months. The quarterly CISO board report shows open vulnerability count down twenty-two percent year over year. Mean time to remediate is fourteen days, down from twenty-six. The compliance dashboard is green. The board asks: is the organization safer from a breach than it was eighteen months ago?
You do not have a clean answer.
The metrics you are presenting measure activity and operational efficiency. They do not measure the outcome the board is asking about: the probability that an attacker who reaches your perimeter can successfully compromise a crown jewel system. Vulnerability count measures the backlog. MTTR measures how fast you work through it. Neither metric captures whether the right items are being remediated, whether the remediations are actually closing exposure paths, or whether your controls would stop an attack if one materialized today.
This is the CTEM metrics problem. Most programs inherit their measurement frameworks from traditional vulnerability management — frameworks designed to demonstrate program activity to compliance auditors, not to answer the risk question that security programs exist to address.
CTEM metrics that measure what you're doing rather than what you're preventing are metrics that satisfy the reporting requirement without informing the risk decision.
Why This Matters Now
In early 2026, a manufacturing conglomerate with a documented, mature vulnerability management program suffered a ransomware incident that encrypted production systems across three facilities. The post-incident review found that the security program had been reporting strong metrics for two years: open vulnerability count declining, MTTR improving, compliance posture clean.
What the metrics did not show: seventeen CISA KEV vulnerabilities had been open on internet-facing OT systems for an average of forty-one days at the time of the breach. The attack path from the initial intrusion point to the production systems ran through an Active Directory misconfiguration that had been identified by the CTEM platform's attack path analysis module but had not been remediated because it was not a "vulnerability" in the traditional VM taxonomy — it was a configuration finding that had not been routed to the patching workflow.
The organization's metrics were measuring the right things in the wrong category. The findings that mattered — CISA KEV on internet-facing systems, AD attack paths to crown jewels — were either being measured inconsistently or not at all. The metrics that were being measured consistently — aggregate open count, aggregate MTTR — masked the specific exposures that led to the breach.
The post-incident CISO presentation to the board included a slide that the security team acknowledged should have been a standing dashboard metric for the previous two years: the percentage of CISA KEV vulnerabilities open on internet-facing systems older than 7 days. On the day of the breach, it was 89%.
What the CURVE™ Data Shows
The 2026 Stackcurve CTEM CURVE™ Report assessed CTEM platforms specifically on their ability to produce and report the metrics that measure breach risk reduction rather than remediation activity.
Tenable One and Qualys TruRisk both support CISA KEV exposure tracking, attack path coverage reporting, and risk-score-weighted mean exposure age as native dashboard metrics. Both platforms allow custom KPI configuration that can surface the six metrics detailed below as executive-facing views.
XM Cyber rated highest for attack path closure rate measurement — providing clear before/after visibility on attack path status as remediations are completed, making it the strongest platform for the single metric most directly correlated with breach risk reduction.
Cymulate and AttackIQ rated highest for BAS validation pass rate measurement over time, with trend dashboards that show control effectiveness improvement or degradation across kill chain stages. This is the metric that tells you whether your security posture is improving — not whether your vulnerability backlog is shrinking.
Microsoft Security Exposure Management (included in Microsoft Defender for Cloud) provides a unified exposure score that incorporates asset criticality, attack path exposure, and active exploitation signals into a single risk index — a useful board-level metric that abstracts the underlying complexity into a directional signal.
The full vendor rankings are in the 2026 Stackcurve CTEM CURVE™ Report — free to download.
The Gap Most Buyers Miss
The gap most buyers miss is the difference between metrics that measure process compliance (are we running the program?) and metrics that measure risk outcomes (is the program working?). The former satisfies audit requirements. The latter answers the CISO's actual question.
The problem with open vulnerability count. Open vulnerability count is a measure of the backlog, not the risk. An organization with 50,000 low-EPSS vulnerabilities on internal development systems has a lower breach probability than an organization with 200 vulnerabilities on internet-facing payment systems with CISA KEV overlap. Aggregate count without risk weighting is data, not intelligence.
The problem with aggregate MTTR. Mean time to remediate measures operational efficiency. An organization that remediates 1,000 low-priority findings in 10 days while 15 CISA KEV findings on internet-facing systems age past 60 days has excellent MTTR and catastrophic exposure risk. MTTR must be segmented by risk tier to be meaningful.
CTEM metrics that measure what matters:
CISA KEV exposure rate on internet-facing assets. What percentage of CISA KEV CVEs are present on internet-facing systems in your environment, and what is the average age of open findings? This is the single most direct indicator of ransomware and nation-state exposure risk. The target is zero open CISA KEV findings on internet-facing systems older than 7 days. This metric is calculable from any VM platform with CISA KEV integration and EASM coverage.
Critical exposure coverage. What percentage of the enterprise attack surface — internet-facing assets plus crown jewel systems — has been assessed for exposure in the last 30 days? A coverage gap is not a finding; it is a blindspot. An organization with 85% coverage has 15% of its highest-priority scope that may contain exposures it cannot see.
Attack path closure rate. For attack paths to crown jewel systems identified in the current CTEM cycle, what percentage have been validated as closed versus open? This is the most direct measure of breach risk reduction available in a CTEM program. A path that is closed is an attack scenario that has been eliminated. An increasing closure rate over time is the core evidence that CTEM is working.
BAS validation pass rate. When BAS simulates prioritized attack scenarios, what percentage are blocked by existing controls? An increasing pass rate over successive BAS cycles demonstrates that defense controls are improving against realistic attack techniques. A flat or declining pass rate indicates that remediation activity is not translating into control improvement.
Time to validate remediation. After a finding is marked as remediated in the ITSM system, how quickly is the fix validated by BAS rescan or targeted vulnerability rescan? A finding closed in a ticket but not validated by independent testing is an assumption, not a confirmation. This metric tracks the gap between assumed remediation and confirmed remediation.
Mean exposure age weighted by risk score. The average age of open exposures in the environment, weighted by their CTEM risk score. Unlike aggregate MTTR, this metric captures the aging of the highest-risk findings specifically. An increasing weighted mean exposure age indicates that high-risk findings are aging faster than they are being remediated — a trend signal that aggregate MTTR will not surface.
Questions Your Buying Team Should Be Asking
1. Can our CTEM platform produce a real-time dashboard view of CISA KEV exposure on internet-facing assets specifically, including the age of each open finding — and is this view currently accessible to the CISO and security leadership without manual report generation? If the answer is that this requires a manual export and spreadsheet analysis, the metric is not operationalized. CISA KEV exposure on internet-facing systems is a tier-1 risk signal that should be a persistent, real-time dashboard metric, not a periodic report.
2. Do we currently measure attack path closure rate — and if so, are we tracking it as a trending metric over successive CTEM cycles rather than as a point-in-time count? A point-in-time attack path count tells you how many paths exist today. A trending closure rate tells you whether your CTEM program is making progress against them over time. The trend is the signal. Organizations that measure attack path count without tracking closure rate are measuring the problem, not the solution.
3. What is our current BAS validation pass rate for the attack scenarios most relevant to our threat profile — and has it improved, declined, or remained flat over the past four quarters? This question surfaces whether the remediation activity the program has been conducting is translating into actual control improvement against realistic attack techniques. A CTEM program that produces excellent MTTR metrics but a flat BAS pass rate is optimizing for speed of ticket closure rather than reduction of attacker success probability.
4. When we present CTEM metrics to the board or executive team, are we presenting risk outcome metrics (CISA KEV exposure rate, attack path coverage, pass rate trend) alongside or instead of activity metrics (open count, MTTR)? The audience for board metrics is not the audit committee — it is decision-makers who need to understand whether the security investment is reducing breach risk. If the board presentation is exclusively activity metrics, leadership cannot answer the question "are we safer than last year?" with confidence.
5. Do we have a defined measurement of the gap between findings marked as remediated in our ITSM system and findings confirmed as remediated by independent validation — and what percentage of "closed" findings have been independently validated in the last 90 days? Assumed-closed findings are a common source of false confidence in CTEM programs. A finding that was patched but where the patch failed to deploy, or where the vulnerability was remediated on one instance but not others in an auto-scaling group, will show as closed in the ticketing system and remain open in the actual environment.
The Stackcurve Take
The organizations running the most effective CTEM programs we assess have made a deliberate choice to report on outcome metrics rather than activity metrics — and to hold themselves accountable to targets that measure breach risk, not remediation throughput.
The measurement shift requires platform support: CTEM tools must natively produce CISA KEV exposure rates, attack path closure rates, and BAS validation trends in dashboard form. Tenable One, Qualys TruRisk, XM Cyber, and Cymulate all provide this capability. The gap is more often a measurement philosophy problem than a tooling problem — programs that have been reporting CVE counts and MTTR for years face internal resistance to metrics that might show the program in a less flattering light.
That resistance is worth overcoming. A board that understands the CISA KEV exposure rate and BAS pass rate trends is a board that can make informed security investment decisions. A board that sees only open count and MTTR is a board that knows whether the program is busy, not whether it is working.
The 2026 Stackcurve CTEM CURVE™ Report covers CTEM measurement frameworks, platform reporting capabilities, and the metrics that correlate most strongly with breach risk reduction outcomes. 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.