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 model describes.
Three things that change
What you count. Vulnerability management counts CVEs on hosts the scanner can reach. CTEM counts any exposure an attacker could use: an over-privileged service account, a forgotten subdomain, a SaaS integration with write access, a misconfigured storage bucket. Half of the exposures that matter never had a CVE.
How you rank. CVSS tells you how bad a vulnerability could be in the abstract. CTEM ranks by whether it is exploitable in your environment, whether it is being exploited in the wild right now, and what an attacker reaches if they use it. A CVSS 9.8 on an isolated test box ranks below a CVSS 6 on a domain controller’s path.
Whether you prove it. Vulnerability management stops at “the scanner says so.” CTEM validates: run the exploit safely, simulate the attack, check whether the endpoint agent fires. Validation is the stage most programs skip and the one that most changes remediation priorities.
What does not change
Patching still has to happen. Asset inventory still has to be maintained. The scanner still runs. 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.
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.