Blog
CTEM vs vulnerability management: what actually changes
Most organisations that say they have adopted CTEM have done one of two things: bought a new dashboard for their existing scanner, or added “exposure” to the name of the vulnerability management team. Neither is wrong, but neither is the change Gartner’s CTEM model describes.
The short answer
Vulnerability management finds and fixes known software flaws on assets you already track. CTEM is a wider, repeating cycle: it scopes by business impact, finds exposures that are not CVEs, ranks them by likelihood and consequence, proves the important ones are exploitable, and makes sure someone fixes them. Vulnerability management becomes an input to CTEM, not a rival.
What each one measures
Vulnerability management measures the state of software on hosts the scanner can reach: how many vulnerabilities, how severe, how old. CTEM measures exposure: how many ways an attacker could reach something the business cares about, how many of those are proven, and how quickly they are closed. One counts findings. The other counts outcomes.
Vulnerability management counts CVEs. The CVE Program exists to “identify, define, catalog publicly disclosed cybersecurity vulnerabilities”, so anything that is not a publicly disclosed flaw never appears in the count. An over-privileged service account, a forgotten subdomain, a SaaS integration with write access and a misconfigured storage bucket are all exposures. Most will never get a CVE, because they are configuration and identity problems rather than software defects.
CTEM counts all of them, and it does not stop at counting. The measures that matter are validated exposures still open and the time taken to close them, which is why the metrics leadership will actually read look so different from a scanner report.
Scope: assets versus attack paths
The scope of vulnerability management is usually an asset list: every server, endpoint and container the scanner is pointed at. The scope of CTEM is a slice of the business, such as a revenue process or the external attack surface, agreed with the person who owns it. Scoping is a stage of its own, and the scanner has no equivalent.
An asset-based scope treats a developer’s test VM and a payments database as equal members of one inventory. A business-based scope starts from the question “what would hurt if it stopped or leaked?” and works backwards to the systems, identities and third parties on the path to it.
It also decides what gets found. A scanner sees what it can reach. A scoped cycle asks which sources see the scope at all (cloud inventory, identity systems, DNS, certificate logs, the CMDB) and chases the gaps.
You do not need to scope the whole estate. One bounded slice with a named business owner is enough for a first cycle, and the 90-day plan is built around exactly that.
Prioritisation: severity versus likelihood and impact
Vulnerability management typically ranks by CVSS. CTEM ranks by whether an exposure can be exploited in your environment, whether it is being exploited now, and what an attacker reaches if they use it. CVSS becomes one input among several. It answers “how bad could this be in general”, not “how bad is it here”.
FIRST, which maintains CVSS, is explicit about this. Its user guide says CVSS Base scores “are designed to measure the severity of a vulnerability and should not be used alone to assess risk”. The base score ignores threat and environment. A CVSS 9.8 on an isolated test box ranks below a CVSS 6 on the path to a domain controller.
Two public sources help with “is it being exploited”:
- CISA’s Known Exploited Vulnerabilities catalogue. CISA describes it as “the authoritative source of vulnerabilities that have been exploited in the wild” and recommends using it as an input to your vulnerability management prioritisation framework. If something is on it, someone has already used it.
- EPSS. FIRST’s Exploit Prediction Scoring System estimates the probability that a published CVE will be exploited in the wild in the next 30 days, and is meant to help you focus limited remediation effort where attacks are most likely. It ranks likelihood across CVEs. It does not know what your network looks like.
Neither knows your business. Reachability and business impact come from your own scoping and discovery work: can an attacker reach the system, and what sits behind it? Exploitation evidence tells you what is urgent in the world. Your context tells you what is urgent for you. Ranking needs both, and a spreadsheet is a fine way to start.
Verizon’s 2025 Data Breach Investigations Report found that exploitation of vulnerabilities was the initial access vector in 20 percent of breaches with a known vector (excluding error and misuse), and that only about 54 percent of the edge-device vulnerabilities it studied were fully remediated, taking a median of 32 days (Verizon, 2025 DBIR).
Validation: proving it
Vulnerability management stops at “the scanner says so.” CTEM validates: it tests whether a specific exposure is actually exploitable from a realistic attacker position, and what it reaches, before anyone commits remediation effort. The result is either a proven path or a documented downgrade, and both are useful.
Validation is the stage most often skipped, because it takes real engineering effort. It can be a scoped penetration test on the top ten items, a safe exploitation attempt, an attack-path analysis, or a simulation that checks whether detection fires. It is not the same as a breach and attack simulation programme, which tests controls against known techniques; BAS versus CTEM validation covers where the two overlap and where they do not.
Skipping validation leaves remediation priorities resting on a score instead of proof. Teams patch items that were never reachable and spend goodwill on tickets that get disputed, while a low-scoring exposure that chains into something valuable sits at the bottom of the queue.
Mobilisation: who fixes it
Vulnerability management usually ends with a report or a ticket queue and an implicit hope that the right team picks it up. CTEM’s last stage, mobilisation, makes closure someone’s named job: an owner per exposure class, an agreed date, a route for exceptions, and a verification step after the fix is applied.
The gap here is organisational more than technical. Security finds the exposure, but infrastructure, platform, application and identity teams fix it, and they have their own priorities. A list of ten validated, business-relevant items with a signed scope behind it is harder to ignore than a raw findings list.
Practical elements of mobilisation:
- Fix owners named at scoping, not discovered at ticket time.
- Service levels by exposure class, not one number for everything. An exposed admin interface and a stale test certificate do not carry the same urgency.
- A decision route for risk acceptance, so “we will not fix this” is a recorded choice by someone with the authority to make it.
- Re-testing. A ticket closed is not an exposure closed. Verify.
CTEM and vulnerability management side by side
The two are not opposed. CTEM includes vulnerability management and adds stages around it. The table below compares them across eight dimensions, from what counts as a unit of work to what you report upwards, so you can see which differences your own programme already covers.
| Dimension | Vulnerability management | CTEM |
|---|---|---|
| Unit of work | A vulnerability, usually a CVE | An exposure, including misconfigurations, identities and third-party access |
| Scope | Assets the scanner can reach | A business-agreed slice, defined in a scoping stage |
| Discovery | Scheduled scans | Multiple sources reconciled, with unknowns chased |
| Prioritisation | Mostly CVSS severity | Exploitability, active exploitation, reachability and business impact |
| Proof | Scanner finding | Validated as exploitable, or downgraded with evidence |
| Ownership | Security raises tickets | Fix owners named up front, with tracked, verified closure |
| Rhythm | Scan cycle and patch windows | Repeating cycle with a defined scope per pass |
| What you report | Counts and ageing of findings | Validated exposures open and time to verified closure |
What to keep from your vulnerability management programme
Almost all of it. Patching still has to happen. Asset inventory still has to be maintained. The scanner still runs, and its output is your largest single discovery source. CTEM sits on top of these and decides where effort goes. If your remediation capacity is two hundred fixes a month, CTEM is the process that picks the right two hundred.
Keep the people, too. Whoever runs vulnerability management today knows the estate and which teams answer tickets, and is the natural program lead for a first cycle.
What to change is smaller than most vendors imply: a scoping conversation, more sources than the scanner, ranking by exploitation evidence and reachability, validation of the top of the list, and named fix owners. That is a process change first and a tooling question second.
If you do end up buying, the tools guide explains what each category covers, and the vendor directory lists what specific products claim.
A one-cycle test
Take last month’s remediation list. For each item, ask: could we show the attack path to something the business cares about? Did anyone verify it was exploitable? Was the fix owner named and the closure tracked? If the answer is mostly no, the program is vulnerability management with a new name. That is a fine starting point. It is just not the finish.
How to start
Start with one bounded scope, not a platform. Pick a system slice with an obvious business owner, reconcile the sources that see it, rank the exposures by hand, validate the top ten and track them to verified closure. Report what happened.
Three practical next steps:
- Take the two-minute quick check for a first read on your weakest stage.
- Use the assessment to score all five stages and see which is furthest from where it needs to be.
- Follow How to start a CTEM program in 90 days for the week-by-week plan, and look at the maturity model to see what “Defined” looks like.
FAQ
Is CTEM just vulnerability management with a new name?
No, though it is often implemented that way. The difference is the process around the scanner: business-based scoping, sources beyond the scanner, ranking by exploitability and impact, validation and named ownership of fixes. If none of those exist, you have vulnerability management, which is a sound base rather than a failure.
Do I need to replace my vulnerability scanner to do CTEM?
No. The scanner stays as a discovery source and as the record of software flaws. What changes is what happens to its output. Most first cycles run on existing tools.
Does CVSS still matter under CTEM?
Yes, as one input. FIRST says Base scores should not be used alone to assess risk. Combine severity with exploitation evidence such as the CISA KEV catalogue and EPSS, then add reachability and business impact from your own scoping.
How long does it take to move from vulnerability management to CTEM?
One cycle on a narrow scope can be run in about 90 days, as set out in the 90-day plan. Extending it across the estate takes longer and is done scope by scope.
Next
If the one-cycle test came back mostly no, How to start a CTEM program in 90 days is the path from a renamed scanner to a real cycle. The only CTEM metrics leadership will read shows what you can report once validation and mobilisation are producing evidence, and the assessment will tell you which of the changes above is furthest away.