Many vulnerability management teams are being told to "become a CTEM programme" without anyone defining what changes in their scope, staffing, budget or metrics. Vulnerability management (VM) is an operational discipline that finds known flaws on known assets and drives them to closure within agreed windows. Continuous threat exposure management (CTEM) is a governance cycle that decides, scope by scope, which exposures of any kind could hurt the business, proves which ones are real, and gets the right owners to act. This guide compares the two as operating models: what each assumes, how each is built, how each fails, and what it costs to move from one to the other. It is written for VM leads, security operations managers and CISOs deciding whether, and how far, to extend a VM function. The stage-by-stage CTEM method is covered in the Exposure Management and CTEM Guide and is not repeated here.
Key takeaways
- VM is a production line; CTEM is a decision cycle. VM measures throughput against SLAs on a list of findings. CTEM chooses a business scope each cycle and measures whether the exposures that matter in it were reduced.
- Scope is the real difference. Gartner, which coined the term, says CTEM scoping "extends beyond the focus of typical vulnerability management programs". The additions that matter most in practice are identity weaknesses, misconfigurations, exposed secrets and attack paths, none of which carry a CVE.
- CTEM does not replace VM. Scanning coverage, patch pipelines and KEV deadlines remain the foundation. CTEM sits above them and changes the order in which work is done and who is asked to do it.
- Validation and mobilisation are the new costs. Proving exploitability needs testing capacity, and mobilisation needs agreed cross-team workflows. Budgets that buy a platform but no people for these two stages produce a relabelled VM programme.
- Change the metrics or nothing changes. If the team is still judged on findings closed and mean time to remediate across everything, it will keep behaving like a patch queue whatever the programme is called.
The short answer
Keep vulnerability management if your main problem is coverage and hygiene: assets not scanned, patches late, no owner for findings, KEV entries missing their deadlines. Fix that first, because no prioritisation model helps when you cannot see the estate. Move to CTEM when VM runs reliably but still cannot answer "which of our open exposures would an attacker actually use to reach something important?", and when your real incidents start from valid accounts, exposed credentials or misconfigured cloud and SaaS services rather than unpatched software. A small organisation can adopt the CTEM cycle with existing staff by running one narrow scope a quarter. A large organisation usually needs a small exposure management function above several remediation teams, with validation capacity and executive sponsorship for mobilisation.
Side by side
| Dimension | Vulnerability management | CTEM |
|---|---|---|
| Core question | Which known flaws exist on our assets, and are they fixed on time? | Which exposures in this business scope could an attacker realistically use, and are the right ones being reduced? |
| Unit of work | Finding: a CVE or configuration check on one asset | Exposure: any weakness, including identity, misconfiguration, secret or path, judged in the context of a scope and its critical assets |
| Scope | All scannable assets, continuously | A business-defined scope per cycle (external surface, crown-jewel application, identity plane, SaaS estate) |
| Prioritisation | CVSS, KEV, EPSS, SSVC, asset criticality | The same signals plus reachability, attack path position, compensating controls and business impact |
| Validation | Rarely; the scanner result is accepted | Required stage: breach and attack simulation, penetration testing or manual confirmation that an exposure is exploitable here |
| Remediation route | Tickets to asset owners with SLA due dates | Mobilisation: agreed actions with business and technical owners, including compensating controls and documented risk acceptance |
| Cadence | Continuous scanning, fixed SLA clocks | Repeating cycles per scope, often quarterly, with continuous discovery underneath |
| Typical owner | VM team within security operations or infrastructure | Exposure management lead reporting to the CISO, coordinating VM, identity, cloud and application teams |
| Main standards | NIST SP 800-40 Rev. 4, SP 800-53 RA-5 and SI-2, CIS Control 7, ISO/IEC 27001:2022 Annex A 8.8 | No formal standard; Gartner's five stages, with mapping to NIST CSF 2.0 ID.RA and SP 800-53 RA-3, RA-7 and CA-8 |
| Headline metric | SLA compliance, mean time to remediate, scan coverage | Validated exposures on critical paths reduced per cycle, time from validation to fix |
Vulnerability management: threat model and operating model
Threat model: the attacker exploits a known flaw in software you run, most visibly a public-facing application (ATT&CK T1190 Exploit Public-Facing Application). The defence is speed and completeness: know every asset, know every flaw, and close the window before the flaw is weaponised. NIST SP 800-40 Rev. 4 frames patching as "a critical component of preventive maintenance", and notes that business owners and security managers often disagree about how much it is worth, which is why VM needs policy-backed SLAs.
Operating model in words: an asset inventory feeds authenticated scanners and agents; findings are enriched with severity, KEV status and EPSS; tickets go to platform and application owners with due dates; a rescan closes them; exceptions follow a risk acceptance route. The NCSC's vulnerability management principles are a good summary of a mature VM function: update by default, respond to active exploitation, identify your assets, triage what updates cannot fix, treat not updating as "a senior-level risk decision", and verify and review regularly.
Prioritisation signals:
- KEV: CISA lists a CVE only with reliable evidence of exploitation in the wild and a clear remediation, and says organisations "should use the KEV catalog as an input to their vulnerability management prioritization framework". BOD 22-01 binds US federal civilian agencies only, but CISA strongly encourages others to adopt KEV remediation as a requirement.
- EPSS: FIRST says EPSS "should never be treated as a risk score"; it covers the threat component only. Its user guide suggests patching high-EPSS, high-CVSS issues first and investigating high-EPSS, low-CVSS issues for their role in chained attacks.
- SSVC: CISA's decision tree uses exploitation status, technical impact, automatability, mission prevalence and public well-being impact to reach Track, Track*, Attend or Act.
These signals rank CVEs well. They do not see weaknesses that have no CVE, and they do not ask whether a vulnerable asset sits on a route to anything important. The Vulnerability Prioritisation Guide covers the signals in depth.
CTEM: threat model and operating model
Threat model: CTEM assumes the attacker takes the cheapest route to impact, whatever it is. That route is often a valid account (T1078 Valid Accounts) obtained from a leaked secret or a service without MFA, a misconfigured storage bucket, an over-privileged service principal or a forgotten internet-facing system. The NSA and CISA joint advisory on the top ten misconfigurations found by their red and blue teams makes the point: its list includes default credentials, improper separation of privilege, weak or misconfigured MFA, overly permissive share ACLs, poor credential hygiene and unrestricted code execution. Only one item, weak patching practices, is what a VM programme is built to measure.
Operating model in words: an exposure management lead agrees a scope for the cycle with a business owner, such as "customer payments platform" or "Entra ID and on-premises directory". Discovery pulls together VM findings, external attack surface data, cloud and SaaS posture, identity posture and secret scanning for that scope. Prioritisation ranks exposures by exploitability, reachability to the scope's critical assets and impact. Validation tests the top of the list. Mobilisation takes confirmed exposures to the owning teams with agreed fixes, compensating controls or signed risk acceptance. Gartner stresses that you "can't wholly rely on the promise of automated remediation" and recommends documenting "cross-team approval workflows"; mobilisation is where most of the CTEM effort, and most of the political work, sits.
What CTEM adds to the VM data set:
- Identity exposures: standing privilege, stale and orphaned accounts, service accounts with interactive rights, missing MFA. See the ISPM Guide.
- Configuration exposures: cloud and SaaS settings that are wrong but not vulnerable; see the Cloud Security Posture Management (CSPM) Guide.
- Unknown assets: internet-facing systems no inventory lists; see the Attack Surface Management Guide.
- Attack paths: chains of individually minor weaknesses that reach a critical asset; see Attack Path Management vs Vulnerability Management.
- Exposed secrets and non-human credentials: API keys in repositories, long-lived tokens, service principal secrets.
Where each one breaks
| Failure mode | Model | What happens | Control |
|---|---|---|---|
| Severity-only queue | VM | Teams work thousands of "critical" findings on isolated systems while an exploited medium on an edge device waits | KEV first, then EPSS and SSVC, then reachability |
| Coverage gaps hidden by good SLA numbers | VM | SLA compliance looks high because unscanned assets produce no findings | Report scan coverage against the asset inventory alongside SLA metrics |
| Identity and configuration out of scope | VM | The server scans clean while the service account on it holds domain-wide rights | Feed identity and posture findings into one risk register |
| CTEM as a rebadged scanner | CTEM | A platform is bought, dashboards change, but there is no scoping, no validation and no mobilisation | Fund people for validation and mobilisation, not only tooling |
| Scoping everything | CTEM | The first cycle covers the whole estate and reproduces the VM backlog with new labels | Narrow, business-recognised scopes that fit one cycle |
| Critical assets undefined | CTEM | Reachability and path analysis rank exposures against the wrong targets | Agree crown jewels with business owners before prioritising, per NIST CSF 2.0 ID.AM-05 |
| Validation skipped | CTEM | Owners dispute findings, and the programme loses credibility | Validate the top of each shortlist and attach the evidence to the action |
| KEV deadlines dropped "because CTEM" | CTEM | Known exploited flaws outside the current scope wait for their cycle | Keep KEV and emergency patching as a continuous VM duty outside the cycle |
The operating model and budget decision
Moving a VM team to CTEM is mostly a change in who does what, not a tool swap. The table shows where cost and effort move.
| Capability | Stays in VM | New or expanded for CTEM | Budget implication |
|---|---|---|---|
| Asset discovery and scanning | Yes, unchanged | Extended to external surface, SaaS and identity sources | Additional data sources and integration effort |
| Prioritisation | KEV, EPSS, SSVC banding | Reachability and business context per scope | Analyst time and, often, attack path or exposure tooling |
| Validation | Rare | Breach and attack simulation, targeted testing, purple teaming | Test capacity, internal or bought; see the Breach and Attack Simulation (BAS) Guide |
| Remediation coordination | Tickets and SLA chasing | Mobilisation with identity, cloud, application and business owners | A named exposure lead and executive sponsorship; the scarcest resource |
| Reporting | Operational dashboards | Scope-level risk reporting to leadership | Modest, but needs agreed risk language |
- Small organisations (one to three VM staff): do not buy a CTEM platform first. Use existing scanner, cloud posture and identity tooling, pick one scope a quarter, validate the top ten exposures manually or with a scoped external test, and run mobilisation as a monthly meeting with the owners.
- Mid-sized organisations: add an exposure analyst role above the VM operators, bring identity posture data into the same register, and budget for recurring validation.
- Large organisations: create an exposure management function with its own lead, keep VM as an operational team underneath, and give the function authority to set priorities across remediation teams. Without that authority, CTEM produces reports nobody acts on.
Gartner's widely quoted prediction is that organisations prioritising security investment through a CTEM programme would be "3x less likely to suffer a breach" by 2026. Treat it as an analyst forecast, not measured evidence, and build your own business case on validated exposures closed and incidents avoided in your own scopes.
Worked scenario
A mid-sized insurer runs a mature VM programme: 97 per cent scan coverage, critical findings fixed in 14 days, a backlog of around 20,000 medium findings. A tabletop shows that its most plausible breach starts with a contractor account without MFA on a SaaS claims platform. Nothing in the VM programme would have flagged it.
- Scope: the first CTEM cycle takes "claims processing", covering the SaaS platform, its integrations, the identity provider and the on-premises document servers. The claims director signs off the critical assets: claims data and payment approval.
- Discover: VM findings for the servers are joined with SaaS posture, identity posture (external accounts, MFA status, admin roles) and secret scanning of the integration repositories.
- Prioritise: of roughly 1,400 exposures in scope, 31 sit on a plausible route to the critical assets. Twelve have no CVE: missing MFA on external accounts, an integration token with write rights stored in a repository, an admin role held by a shared mailbox.
- Validate: a scoped test confirms that the token and two of the identity weaknesses lead to payment approval; several high-CVSS findings on the document servers turn out to be unreachable from any starting point the test assumed.
- Mobilise: the identity team enforces MFA and removes the shared mailbox's role in a week; the integration owner rotates the token and moves it to a vault; the server findings return to the normal VM queue with their usual SLAs.
The VM programme did not get worse; it simply could not see the exposures that mattered. The numbers here are illustrative.
Decision criteria
- Is scanning coverage above your target, and are KEV deadlines met? If not, invest in VM first.
- Do your incidents and test findings start mostly from credentials, misconfigurations and unknown assets? If yes, VM alone is measuring the wrong thing.
- Can you name critical assets with business owners? Without them, CTEM prioritisation has nothing to aim at.
- Do you have, or can you buy, validation capacity? Without it, CTEM is risk-based VM with a new name; see the Risk-Based Vulnerability Management Guide.
- Will leadership back cross-team mobilisation? If identity, cloud and application teams can ignore exposure actions, start with sponsorship before tooling.
- Will metrics change? Agree new measures with leadership before the first cycle.
Detection and measurement
Keep VM operational metrics and add CTEM outcome metrics; do not merge them into one score.
| Metric | Programme | What it shows |
|---|---|---|
| Authenticated scan coverage of inventoried assets | VM | Whether the foundation is complete |
| KEV remediation within deadline | VM | Response to active exploitation |
| Validated exposures on paths to critical assets, start versus end of cycle | CTEM | Real reduction in reachable risk per scope |
| Median time from validation to fix or accepted compensating control | CTEM | Whether mobilisation works |
| Share of prioritised exposures with no CVE | CTEM | Whether scope genuinely extends beyond VM |
| Recurrence of closed exposures in later cycles | CTEM | Whether fixes address root causes |
For VM metric definitions see Vulnerability Management Metrics, and for a self-assessment of the VM foundation use the Vulnerability Management Health Check.
Framework mapping
| Framework | Vulnerability management | CTEM additions |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 vulnerabilities identified, validated and recorded; PR.PS-02 software maintained commensurate with risk | ID.AM-05 asset prioritisation; ID.RA-05 risk informs prioritisation; ID.RA-06 risk responses prioritised and tracked |
| NIST SP 800-53 Rev. 5 | RA-5 Vulnerability Monitoring and Scanning; SI-2 Flaw Remediation; CM-8 System Component Inventory | RA-3 Risk Assessment; RA-7 Risk Response; CA-8 Penetration Testing; PM-16 Threat Awareness Program |
| CIS Controls v8.1 | Control 7 Continuous Vulnerability Management | Control 18 Penetration Testing for validation |
| ISO/IEC 27001:2022 Annex A | 8.8 Management of technical vulnerabilities | 5.7 Threat intelligence; 8.9 Configuration management |
| MITRE ATT&CK v20 | T1190 Exploit Public-Facing Application | T1078 Valid Accounts and other techniques that need no CVE |
Common failure patterns
- Announcing CTEM and keeping VM metrics: the team is still rewarded for closing findings, so scoping and validation never happen.
- Buying the platform before naming the owner: an exposure management tool without a lead and sponsorship becomes another dashboard.
- Letting the cycle delay emergencies: KEV and critical edge-device flaws wait for "their" scope; emergency patching must stay continuous.
- Leaving identity to another team's report: identity exposures are tracked elsewhere and never compete for priority with CVEs.
- Treating validation as a yearly penetration test: annual tests cannot keep up with quarterly cycles; see CTEM vs Penetration Testing.
- No exit for accepted risk: exposures accepted in one cycle are never revisited; record an expiry and owner, as the Remediation SLAs and Vulnerability Exceptions Guide describes.
Practitioner checklist
- Confirm VM foundations first: inventory, authenticated scan coverage, SLAs and KEV handling.
- Name an exposure management owner with authority across remediation teams.
- Agree critical assets and business owners for the first scope.
- Choose a narrow first scope that fits one cycle, ideally one where identity or configuration risk is suspected.
- Bring identity, cloud, SaaS and secret findings into the same register as VM findings.
- Budget validation capacity, internal or external, for every cycle.
- Document cross-team mobilisation workflows and risk acceptance with expiry dates.
- Keep KEV and emergency patching continuous and outside the cycle.
- Agree new CTEM outcome metrics with leadership before the first cycle report.
- Review each cycle for recurring exposures and fix the root cause.
Standards and references
- NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning
- CISA: Known Exploited Vulnerabilities
- CISA: Stakeholder-Specific Vulnerability Categorization
- NSA and CISA: Top Ten Cybersecurity Misconfigurations
- NCSC: Vulnerability management
- FIRST: EPSS User Guide
- CIS: Control 7 Continuous Vulnerability Management
- Gartner: How to Manage Cybersecurity Threats, Not Episodes
Related NHI Mgmt Group resources: Exposure Management and CTEM Guide, Vulnerability Management Guide, CAASM vs CTEM, Exposure Management Buyer's Guide, Vulnerability Management Policy Template.