CTEM’s five stages show where exposure management breaks down

At a glance

What this is: This is an explainer of CTEM’s five stages, centred on how the Exposure Clock surfaces vulnerabilities that appear after the last assessment.

Why it matters: It matters to IAM and security teams because exposure validation, asset context, and remediation prioritisation all depend on accurate identity, privilege, and change control across systems.

👉 Read Hadrian’s explanation of CTEM and the Exposure Clock

Context

CTEM, or continuous threat exposure management, is a governance model for measuring and reducing exposure as environments change. The problem is not simply finding vulnerabilities, but validating which ones matter, where they sit in the environment, and whether remediation work is keeping pace with new risk.

For identity-led programmes, the same gap appears when asset visibility, privilege context, and configuration drift are treated as separate issues. Once cloud assets, service accounts, and externally reachable services move faster than review cycles, the exposure programme becomes a lagging indicator rather than a control loop.

Key questions

Q: How should security teams run CTEM in fast-changing environments?

A: They should treat CTEM as a continuous decision cycle, not a quarterly report. Start with reliable asset discovery, then validate which exposures are externally reachable, privilege-bearing, or linked to sensitive systems. The goal is to reduce the time between discovery, prioritisation, and remediation so the programme reflects current risk rather than last month’s state.

Q: Why does context matter so much in exposure management?

A: Context turns a long list of assets into a risk picture. Without it, teams cannot tell whether a finding is a harmless service or a high-value entry point linked to privileged identity or sensitive data. Context is what lets teams reduce false positives and focus on exposures attackers can actually use.

Q: What do security teams get wrong about periodic pentesting?

A: They often assume a pentest is a durable snapshot of exposure. In reality, code, dependencies, and identity-linked permissions change constantly, so findings age quickly. Periodic testing is still useful, but only as one layer. It fails when organisations treat it as continuous assurance rather than a point-in-time control.

Q: How do security teams decide which exposure to fix first?

A: Use exploitability, reachability, business criticality, and identity privilege together. A lower-severity issue can outrank a higher-severity one if it is internet-facing, easy to chain, or linked to a high-value identity path. Prioritisation should reflect attack likelihood, not just scanner severity.

Technical breakdown

What the five CTEM stages are trying to control

CTEM is usually described as a cycle rather than a point-in-time assessment. The stages are exposure discovery, scope validation, prioritisation, mobilisation, and validation. Together they are meant to answer a practical question: which exposures are real, which are most exploitable, and which can be reduced first. The model matters because raw vulnerability counts do not reflect business context, internet reachability, or privilege relationships. In modern environments, that context often depends on identity and access data, not just asset scanning.

Practical implication: map exposure findings to ownership, reachability, and privilege context before assigning remediation work.

Why the Exposure Clock changes the validation problem

The Exposure Clock concept shows that risk accumulates between assessments. Each new asset, configuration change, or externally exploitable weakness increases the gap between what was last validated and what is true now. That creates a governance problem for teams relying on periodic pentests or scheduled reviews, because the environment can change materially before the next validation cycle. In identity-heavy environments, the same issue affects accounts, tokens, and permissions that outlive their intended scope.

Practical implication: treat post-assessment drift as a first-class exposure signal, not just an operations issue.

How CTEM depends on identity context and attack surface data

Exposure management becomes materially stronger when it connects asset state to identity context. A vulnerability on an internal system is not the same as the same issue on an internet-facing host with privileged credentials or reachable secrets. CTEM therefore depends on understanding which assets are exposed, which identities can reach them, and which paths an attacker could use after initial access. That is where IAM, PAM, and NHI governance intersect with broader security posture management.

Practical implication: join exposure data with identity and privilege data before deciding what counts as high impact.

NHI Mgmt Group analysis

CTEM becomes meaningful only when exposure is tied to ownership and privilege context. A vulnerability count without asset context is just inventory noise. The operational question is whether a team can distinguish a theoretical finding from one that is reachable, privileged, and exploitable in the current environment. For identity programmes, that means exposure management must understand service accounts, machine access, and delegated privileges as part of the attack surface.

Exposure drift is the control gap CTEM is designed to surface. The longer the gap between assessment and validation, the more likely the environment has changed underneath the programme. That is especially true where cloud assets, tokens, and workload identities can be created faster than review cycles can close them. Practitioner conclusion: shorten the time between discovery and validation, or accept that risk scores will age out quickly.

Asset context is becoming inseparable from identity context in modern exposure programmes. A route into a system is not just a technical path, but a permissions path. That means CTEM should increasingly be read alongside IAM, PAM, and NHI governance, because the question is not only what is exposed, but what identities can reach it and what they can do once there. Practitioner conclusion: unify exposure and identity telemetry before prioritising remediation.

CTEM will not replace traditional vulnerability management unless organisations change the decision loop. Periodic scanning still has value, but it is no longer enough to answer which exposures deserve immediate attention. The field is moving toward continuous validation, faster scoping, and more explicit linkage between attack surface changes and risk ownership. Practitioner conclusion: restructure remediation queues around validated exposure, not scan cadence.

What this signals

Exposure management is moving from periodic review to continuous decision-making. Teams that still rely on snapshot assessments will miss the window in which findings become actionable. The practical shift is toward validating change as it happens, especially where cloud workloads, service accounts, and delegated access can alter exposure faster than review cycles can react.

Identity context will determine whether CTEM matures or stalls. If exposure programmes cannot see who or what can actually reach a vulnerable asset, they will keep producing low-confidence queues. The 52 NHI Breaches Analysis shows how often access and persistence failures turn technical exposures into incidents, which is why access-path context matters as much as asset context.

Exposure drift is the programme signal to watch. The more frequently assets, permissions, and configurations change, the less useful a static risk score becomes. That is where identity lifecycle discipline, including offboarding and privilege review, starts to function as exposure control rather than just governance hygiene.

For practitioners

• Map exposures to business ownership Link each finding to a system owner, service owner, and remediation path so exposure scoring reflects accountability rather than raw scanner output.
• Combine exposure and identity telemetry Correlate internet reachability, asset criticality, and access paths from human and non-human identities before classifying an issue as high impact.
• Shorten validation cycles for fast-changing assets Revalidate externally exposed systems, credentials, and cloud workloads after material change events instead of waiting for the next scheduled assessment.
• Prioritise remediation by exploitability and reachability Use reachable attack paths, privilege exposure, and internet exposure to sort findings ahead of severity-only queues.

Key takeaways

• CTEM is only useful when it connects vulnerabilities to current asset and identity context.
• The Exposure Clock illustrates a core governance problem: risk accumulates faster than periodic validation can clear it.
• Teams should prioritise validated, reachable, and privilege-linked exposures ahead of scan queues.

Key terms

• Continuous Threat Exposure Management: Continuous Threat Exposure Management is the ongoing process of finding which assets, identities, and paths are actually reachable from the current environment. It moves risk assessment away from static inventories and toward live exposure, so security teams can prioritise what an attacker or misuse path can reach now.
• Exposure Clock: A way of measuring how much risk has accumulated since the last assessment or validation cycle. It highlights the gap between a point-in-time view and the current state of the environment, which is especially important where assets, identities, and configurations change quickly.
• Exposure Drift: Exposure drift is the gap between the state a security team last validated and the state the environment has reached since then. In fast-changing cloud and identity-heavy environments, that gap can be large enough to make a previous pentest result unreliable for operational decisions.

What's in the full article

Hadrian's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of the five CTEM stages and how Hadrian maps them into an exposure workflow.
• Practical guidance on using the Exposure Clock to monitor vulnerability accumulation between assessments.
• Operational detail on asset context, validation, and prioritisation that teams need once they move from strategy to implementation.

👉 The full Hadrian post covers the five CTEM stages and how the Exposure Clock is meant to be used.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical enterprise terms. It gives identity and security practitioners a shared foundation for governing access, lifecycle control, and privilege risk.