Traditional vulnerability management finds and fixes software flaws on the assets you know about, usually on a scan cycle and in order of severity. Continuous Threat Exposure Management (CTEM), a model Gartner introduced in 2022, is broader. It runs in repeating cycles of five stages (scoping, discovery, prioritization, validation and mobilization) and covers any exposure an attacker could use, including misconfigurations, excessive permissions and forgotten internet-facing services. CTEM doesn't replace vulnerability management. It puts it inside a wider program, and a small team can adopt most of its ideas without buying anything new.
What is traditional vulnerability management?
Most vulnerability management programs follow a familiar loop. Maintain an asset inventory, scan it on a schedule, rank the findings by severity, send them to IT for patching, and rescan to confirm the fix.
That loop works, and it remains essential. But it has built-in limits:
- It sees what the scanner sees. Assets missing from the inventory, SaaS applications and cloud services often fall outside scan scope.
- It is centered on CVEs. A misconfigured storage bucket, a stale admin account or an overly broad firewall rule may never show up as a scanner finding.
- It produces volume. Severity-based ranking tends to create long lists with no clear sense of which items actually lead somewhere dangerous.
- It rarely asks "could this really be exploited here?" A critical finding behind three layers of controls gets the same urgency as one on an open login page.
- Remediation is often handed off, not owned. Security produces the list and IT receives it, which is where many programs stall.
What is Continuous Threat Exposure Management?
CTEM is a program model, not a product category. Gartner introduced it in 2022 as a way to organize security work around exposures rather than individual vulnerabilities.
An exposure is anything that gives an attacker a usable path toward something you care about. That includes unpatched software, but also misconfigured cloud resources, weak identity setups, shadow IT, exposed credentials and risky third-party connections.
The word "continuous" refers to cycles, not constant scanning. Each cycle takes a defined scope, works through all five stages, and then starts again, often with a different scope.
What are the five stages of CTEM?
1. Scoping
Decide what this cycle will cover, starting from business priorities rather than technical boundaries. A scope might be "our internet-facing attack surface," "everything that could reach the customer database," or "our main cloud tenant." Business stakeholders should help choose, because they know which systems and data matter most.
2. Discovery
Find the assets in scope and the exposures on them. That means more than running a vulnerability scan. It includes finding unknown assets, checking configurations, reviewing identities and permissions, and mapping how systems connect.
3. Prioritization
Rank exposures by how likely they are to be used and how much damage they would cause. Useful inputs include known exploitation (for example, whether a vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog), exploit prediction scores, internet exposure, asset criticality, and whether the exposure sits on a realistic attack path. The goal is a short list, not a sorted long one.
4. Validation
Test whether the top exposures can actually be exploited in your environment, and whether your existing controls would stop or detect the attempt. Validation might be a targeted penetration test, an adversary emulation exercise, or a careful manual check. It also tells you whether your response processes would react fast enough.
5. Mobilization
Get the fixes done. Mobilization covers agreeing on owners, communicating why each fix matters, working through approval and change processes, and handling exposures that can't be fixed quickly. It is the stage that turns findings into reduced risk, and the one most programs underinvest in.
How is CTEM different from vulnerability management?
| Traditional vulnerability management | CTEM | |
|---|---|---|
| Scope | Assets in the scanner's inventory | A business-defined scope, chosen per cycle |
| What counts | Mostly software vulnerabilities with CVEs | Any exploitable exposure, including configuration, identity and third-party paths |
| Cadence | Scheduled scans, often weekly or monthly | Repeating cycles, each with its own scope |
| Prioritization | Severity score, sometimes adjusted for asset value | Exploitability, business impact and attack paths |
| Validation | Rarely, beyond rescanning | Built in, testing whether an exposure is really exploitable |
| Remediation | Tickets handed to IT | Mobilization with agreed owners and cross-team buy-in |
| Success measure | Findings closed | Exposure reduced in the areas that matter most |
The biggest shift is in the question being asked. Vulnerability management asks "what is broken?" CTEM asks "what could an attacker actually use against us, and which of those should we deal with first?"
Does CTEM replace vulnerability management?
No. Scanning, patching and tracking remediation are still necessary, and they become part of CTEM's discovery, prioritization and mobilization stages.
What changes is the framing around them. A mature vulnerability management program with risk-based prioritization and good ownership already covers a good deal of CTEM. The main additions are business-driven scoping, non-CVE exposures, validation, and a deliberate focus on getting fixes through other teams.
How can a small or mid-sized team adopt CTEM without buying a platform?
You don't need a dedicated exposure management product to work this way. Most of CTEM is process, and the tools you already have can support the first few cycles.
Start with one narrow scope
Pick a single, well-bounded scope for your first cycle. Your internet-facing attack surface is a good choice for most organizations. It's finite, attackers can reach it directly, and problems there tend to be serious.
Plan on cycles of roughly a quarter, so you can finish one before starting the next.
Discover with the tools you already have
For an external scope, you can build a solid picture from:
- DNS records and registrar data for every domain you own
- Certificate transparency logs, which often reveal forgotten subdomains
- Your existing vulnerability scanner, pointed at external IP ranges
- Open-source network scanners such as Nmap to confirm which ports and services are exposed
- Your cloud provider's built-in configuration and security checks, to find publicly accessible storage or services
For identity-related exposures, review privileged group membership, stale and shared accounts, and service accounts with broad permissions. For SaaS, check external sharing settings and third-party app integrations.
Prioritize with free signals
Combine CISA's KEV catalog, FIRST's Exploit Prediction Scoring System (EPSS), internet exposure and your own asset criticality ratings. Then do something scanners can't: sketch the likely attack paths on a whiteboard.
An exposed remote access service with weak authentication that lands on a flat internal network deserves more attention than a higher-scoring flaw on an isolated system. Aim to end the stage with a top ten, not a top thousand.
Validate in proportion to your resources
Validation doesn't have to mean a large red team engagement. Options that fit a smaller budget include:
- Manually confirming that an exposed service is reachable and that the vulnerable version is really running
- Scoping your next penetration test around the top exposures from this cycle
- Running small, controlled exercises mapped to MITRE ATT&CK techniques, to see whether your logging and alerting would notice the activity
Treat validation like any other change. Get approval, agree on a time window, and avoid testing that could disrupt production.
Mobilize through existing channels
Push fixes through the change management and ticketing processes IT already uses rather than inventing a parallel one. What makes CTEM mobilization different is the conversation. Explain the attack path and the business impact to system owners, not just the CVE and score.
Agree on remediation timelines with each owner and record exceptions with an expiry date when something can't be fixed quickly.
Close the loop and pick the next scope
At the end of each cycle, confirm what was fixed, note what was accepted as risk, and record anything you learned about gaps in your inventory or monitoring. Then choose the next scope, perhaps a critical internal application or your main cloud environment.
What are the common mistakes when adopting CTEM?
- Renaming the scan program. Calling the monthly scan report "CTEM" changes nothing. Without scoping, validation and mobilization, it's the same program.
- Scoping too broadly. "Everything" is not a useful scope for a small team. You'll never finish a cycle.
- Skipping validation. Without it, prioritization rests on assumptions about what attackers could do.
- Leaving mobilization to chance. If the output is still a list emailed to IT, the fixes will move at the same speed as before.
Frequently asked questions
Is CTEM a product we need to buy?
No. CTEM is a program model. Various products market themselves as supporting it, but the stages can be run with existing tools, open-source utilities and disciplined process, especially at small and mid-sized scale.
How often should a CTEM cycle run?
There's no fixed rule. Many teams find a quarterly cycle manageable, with urgent issues like newly exploited vulnerabilities still handled immediately through normal processes. Several scopes can run at once as the program matures.
Do we need a penetration test for the validation stage?
Not always. A penetration test is one way to validate, but manual checks, configuration reviews and small controlled exercises also count. Save deeper testing for the exposures where the answer really matters.
How does attack surface management relate to CTEM?
External attack surface management, which means finding and monitoring your internet-facing assets, supports the discovery stage. It's a useful input, but it covers only part of what CTEM asks for.
Key takeaways
- Vulnerability management remains the foundation. CTEM widens the lens to all exploitable exposures and adds scoping, validation and mobilization.
- Gartner's five stages are scoping, discovery, prioritization, validation and mobilization, run in repeating cycles.
- Start with one narrow scope, such as your internet-facing attack surface, and finish a full cycle before expanding.
- Use free signals like CISA KEV and EPSS, plus your own view of asset criticality and attack paths, to keep priority lists short.
- Put the most effort into mobilization, because exposure only goes down when fixes are made.