Blog
State of CTEM vendor coverage, Q3 2026: what 17 vendors actually cover
Across 17 vendors and five CTEM stages, 43 of the 85 scores are a 2, 35 are a 1 and 7 are a 0. Ten vendors score at least 1 on every stage. None scores 2 on all five. Scoping is the most common gap, and validation is the most uneven stage. Everything below is counted from our own dataset.
This is a data study, not a league table. We do not rank the vendors, and a higher total does not mean a better fit for your programme. The purpose is to show where the market’s coverage is thick and where it is thin.
Stage by stage
Discovery, prioritisation and mobilisation are close to universal: no vendor scores 0 on any of them. Validation splits the field almost evenly, and scoping is where most vendors stop at partial. Scoping has the lowest stage total (14 of a possible 34) and prioritisation the highest (30).
| Stage | Score 2 | Score 1 | Score 0 | Stage total (max 34) |
|---|---|---|---|---|
| Scoping | 2 | 10 | 5 | 14 |
| Discovery | 11 | 6 | 0 | 28 |
| Prioritisation | 13 | 4 | 0 | 30 |
| Validation | 7 | 8 | 2 | 22 |
| Mobilisation | 10 | 7 | 0 | 27 |
Each row sums to 17. Across all 85 scores, 2 accounts for 50.6 percent, 1 for 41.2 percent and 0 for 8.2 percent.
Where the gaps are
The gap stage is scoping. Fifteen of 17 vendors score 1 or 0 there, and five score 0, which is more than any other stage. Validation is next: ten score 1 or below, two score 0. Seven vendors have at least one 0 in total: five on scoping and two on validation, with no overlap between them.
Scoping is hard to sell as a product feature, so this is not surprising. Agreeing what is in scope and how critical it is depends on people and process, and most products contribute asset context rather than a criticality model. The rubric reserves a 2 for a criticality model in the product itself. Two vendors clear that bar: Falcon Exposure Management and Microsoft Security Exposure Management.
A second pattern: no vendor scores 2 on both scoping and validation. The two that score 2 on scoping score 1 on validation, and all seven that score 2 on validation score 1 or 0 on scoping. In this dataset, the products strongest at proving exploitability and the products strongest at agreeing scope are different products.
How the totals distribute
Totals run from 4 to 9 out of a possible 10, with a median of 8 and a mean of 7.12. No vendor scores below 4 and none reaches 10. Seven of the 17 sit on 8 exactly, which makes it the most common total, and the spread below that is thin.
| Total (0 to 10) | Vendors |
|---|---|
| 0 to 3 | 0 |
| 4 | 2 |
| 5 | 2 |
| 6 | 1 |
| 7 | 2 |
| 8 | 7 |
| 9 | 3 |
| 10 | 0 |
Ten vendors sit at 8 or 9. Four sit at 4 or 5, and all four score 1 on mobilisation. Nine vendors score 2 on exactly three stages, which is the most common profile: 2 on three stages, and 1 or 0 on the other two. Eight vendors score 2 on discovery, prioritisation and mobilisation together.
Totals compress towards the top because the rubric measures presence, not depth. A vendor with partial coverage on every stage totals 5. The interesting information is in which stages hold the 2s, not in the sum.
Patterns by category
Every vendor carries two or three editorial category labels, so the groups below overlap and their counts do not add to 17. Only categories with four or more vendors are shown, because groups of one or two say little. Read the rows as tendencies in this sample, not as properties of a product class.
| Category | Vendors | Mean total | Validation 2 / 1 / 0 | Scoping 2 / 1 / 0 |
|---|---|---|---|---|
| Exposure platform | 11 | 7.73 | 3 / 6 / 2 | 2 / 8 / 1 |
| Validation | 8 | 7.38 | 7 / 1 / 0 | 0 / 5 / 3 |
| Attack surface management | 5 | 6.60 | 2 / 3 / 0 | 1 / 2 / 2 |
| Vulnerability management | 5 | 7.00 | 1 / 3 / 1 | 0 / 4 / 1 |
| Attack path analysis | 4 | 8.00 | 0 / 4 / 0 | 1 / 3 / 0 |
Three things stand out. First, all seven vendors that score 2 on validation carry the Validation label, and only one Validation-labelled vendor scores below 2. The label and the score agree, which is a useful check on the rubric.
Second, exposure platforms are the broadest group (11 vendors), but six of them score 1 and two score 0 on validation. Being a platform is not the same as owning the test-and-prove step. The four attack path analysis vendors all score 1 on validation: that fits the rubric’s 1, which covers modelled or inferred exploitability rather than native testing.
Third, the eight Validation-labelled vendors are weakest on scoping: none scores 2, and three score 0. Two breach and attack simulation vendors score 0 on scoping and 2 on validation. If you buy for validation, expect to bring your own scope.
To compare products head to head, see Pentera and XM Cyber, Wiz and Tenable One or Cymulate and Picus Security.
Methodology
Each vendor is scored 0, 1 or 2 on each of the five stages, from public documentation only. A 2 means full, 1 partial and 0 none, and a 2 is reserved for what the product does natively today, not a services engagement or a roadmap item. The definitions below are the same ones published on /vendors.
| Stage | 2 | 1 | 0 |
|---|---|---|---|
| Scoping | Helps agree what is in scope and its business criticality, with a criticality model in the product. | Contributes scope or asset context, but agreeing scope and criticality is left to you or to another tool. | No scoping capability. |
| Discovery | Collects several sources natively, beyond CVEs. | Narrow, or mostly ingests sources from other products. | No discovery capability. |
| Prioritisation | Ranks by attack path, reachability and business impact. | Adds context such as exploitation intelligence or asset criticality, but no attack-path reasoning. | Severity score (CVSS) and asset count only. |
| Validation | Native active testing that attempts the exploit or attack and records proof. | Modelled, inferred or on-demand. | No validation capability. |
| Mobilisation | Assigns a fix owner and a date, and re-tests before the ticket closes. | Tickets, owners or workflow, but no re-test. | No mobilisation capability. |
All 17 entries are editorial. Every score was last reviewed on 2026-09-20. The counts in this post were computed by script from the dataset, and nothing here comes from another source. The same data is published at /data, including a CSV of the stage scores.
Limitations
Read the numbers with these limits in mind. The scores are a desk review of public documentation. None of the 17 entries is hands-on: no product was deployed or tested. What a vendor says it does is not the same as what it does in your environment.
The rubric measures whether a capability exists, not how well it works. Two vendors scoring 2 on validation may differ a great deal in safety, breadth and evidence quality. A 17-vendor sample is small and was chosen by us, so it is not the whole market and the percentages describe this sample only. Category labels are editorial and overlap.
Documentation changes faster than a quarterly review. If a score is wrong, tell us and we will fix it and log the change.
How to cite
The dataset is the CTEE Stage Coverage Matrix, released under CC BY 4.0, so you may reuse it with attribution. Cite the version, which is the latest review date in the data, not only the site. The current version is 2026-09-20.
CTEE. Stage Coverage Matrix, version 2026-09-20. https://ctee.org/data (accessed [date]).
If you quote a number from this post, cite the matrix, not the post, and say which stage and score you counted. The rubric on /vendors is the definition of what each score means.
Changelog
- 2026-09-30: first published as a draft. Scores in the dataset were last reviewed on 2026-09-20. All counts computed from that version.
Where to go next
Use this study to decide which stages to ask hard questions about, then use the vendor evaluation checklist to run those questions in a demo. If you are unsure which stage matters most for you, the assessment will show your weakest one. Browse every score on /vendors.