CTEM (continuous threat exposure management) is a repeating program for finding, ranking and fixing the exposures that attackers could realistically use. This model has four levels, from ad hoc to measured. It is our own rubric for self assessment, not a standard, so adapt it freely.
What does CTEM actually mean?
The term comes from industry analysts and is usually described as a cycle: define scope, discover assets and exposures, prioritize, validate whether an attacker could actually use them, and mobilize fixes. Paid analyst reports define it in detail, and we have not reproduced them here. The loop idea matches the continuous monitoring approach in NIST SP 800-137, which stresses visibility into assets, threats and whether controls work.
CTEM is not a product category you can finish buying. It is a way of running vulnerability, misconfiguration, identity and exposure work as one loop with shared priorities.
Level 1: Reactive
Scoping is informal. Someone knows the main systems. Discovery is a periodic scan, often for one asset class such as servers. Priorities come from raw severity scores. Fixes happen when a ticket lands on an owner who happens to listen.
Signs you are here: you learn about assets from incidents, the backlog only grows, and nobody can say how many internet-facing services you run.
Move up by: naming an owner for the program, listing business critical systems, and getting one inventory that other teams trust.
Level 2: Organized
Scope is written down by business function. Discovery covers hosts, cloud accounts and code dependencies on a schedule. CISA's BOD 23-01 gives a concrete reference for federal agencies: automated asset discovery every 7 days and vulnerability enumeration started every 14 days. You need not copy those numbers, but a fixed cadence is the mark of this level.
Prioritization adds context: internet exposure, known exploitation and asset value. FIRST describes EPSS as an estimate of the probability that a published CVE will be exploited in the wild in the next 30 days, which is one input teams use here. Fixes have service levels by risk class and a named owner per asset.
Move up by: tracking time to fix by team, and reviewing exceptions on a calendar.
Level 3: Validated
This is where CTEM differs from ordinary vulnerability management. You test whether an exposure can be reached and used. For software, that means reachability analysis: is the vulnerable function called by your code? For infrastructure, it means checking whether a path from the internet to the asset exists and whether controls in between would stop it.
Scoping is reviewed each cycle against business change, such as an acquisition or a new product line. Findings from identity, cloud and application tools land in one queue, deduplicated, with a single risk statement. Detection and response teams feed what they see back into priority.
Move up by: running scenario exercises that start from a specific exposure and test the full chain, and by measuring how many findings validation removed from the urgent list.
Level 4: Measured and automated
Routine fixes are automated with guardrails. Low risk updates flow through pipelines. Higher risk changes request approval with evidence attached. Policies block known bad states at build and release, so some exposure never reaches production.
Leadership sees a short set of outcome measures, such as share of internet-facing assets with a named owner, median time to fix exploited issues, and recurrence of the same root cause. The program has a yearly review and adjusts scope.
Signs you are here: new exposures are mostly found by your own process before outsiders find them, and metrics are used in budget decisions.
How do you assess yourself?
Score each of the five stages (scope, discover, prioritize, validate, mobilize) from 1 to 4 separately. Most teams are uneven, for example Level 3 in code and Level 1 in cloud. Improve your weakest stage first, since the loop is only as good as its weakest link.
Where Safeguard fits
Safeguard covers the application and software supply chain slice: reachability analysis for validation, policies and gates at build, CI and release, and autonomous remediation through fix pull requests, which is off by default with categories starting on Manual. It is not a CTEM platform, and CTEM tooling is outside what we offer today.
What to do
- Score yourself on the five stages using the levels above.
- Pick the weakest stage and one change for the next 30 days.
- Fix a discovery cadence and publish it.
- Add one validation step, such as reachability for dependencies.
- Choose three outcome measures and report them monthly.
- Re-score every six months.
Quick check
Is CTEM a tool I can buy?
No. Tools support it, but CTEM is a cycle of scoping, discovery, prioritization, validation and fixing that your people and processes run.
Which level should a ten person team aim for?
Level 2 with one Level 3 habit, such as reachability checks on dependencies, is a realistic target. Higher levels need more people than the benefit justifies.
Sources
- NIST SP 800-137, Information Security Continuous Monitoring
- CISA BOD 23-01
- FIRST, Exploit Prediction Scoring System
Last reviewed: 18 October 2026.
