Exposure Management and CTEM Guide

Vulnerability programmes produce far more findings than any team can fix, and the CVE list leaves out many of the weaknesses attackers actually use: misconfigurations, over-privileged identities and leaked credentials. Exposure management widens the lens from "which CVEs do we have" to "what could an attacker reach, and what would it cost us", and then proves the answer before asking anyone to fix it. Continuous threat exposure management (CTEM) is the programme model most often used to run it. This guide covers the five CTEM stages, how exposure differs from vulnerability, attack paths and choke points, identity exposures, validation, mobilisation and ownership, metrics and maturity. It is for vulnerability management leads, security architects and CISOs building or reviewing a programme, and it is vendor-neutral.

Key takeaways

• An exposure is broader than a vulnerability. It includes misconfigurations, excessive permissions, exposed secrets and missing controls, judged by whether an attacker can reach and use them.
• CTEM is a cycle, not a product. Scoping, discovery, prioritisation, validation and mobilisation repeat on a fixed cadence, one business-defined scope at a time.
• Prioritise on evidence of exploitation and reachability. KEV, EPSS and attack path position beat severity scores alone, and choke points let one fix close many paths.
• Identity is usually the shortest path. Standing privilege, unowned service accounts and leaked NHI secrets turn a foothold into domain or cloud control without a single CVE.
• Mobilisation is where programmes fail. Without named owners, agreed timeframes and a route for risk acceptance, validated findings sit in a queue like any other.

Exposure versus vulnerability

A vulnerability is a flaw in software, usually with a CVE. An exposure is any condition an attacker can use to reach something that matters: an unpatched CVE, but also a storage bucket readable by anyone, an admin interface on the internet, a service account in Domain Admins, an access key in a public repository, or an EDR agent missing from a server. The NSA and CISA list of the ten most common misconfigurations (advisory AA23-278A) shows how much sits outside the CVE world: default configurations, "Improper separation of user/administrator privilege", weak or misconfigured MFA, "Poor credential hygiene" and unrestricted code execution all appear next to poor patch management.

Exposure management does not replace vulnerability management; it consumes its output. Scanning, SLAs and patch verification are covered in the Vulnerability Management Guide, and handling actively exploited flaws in the Zero-Day and Exploited Vulnerabilities Guide.

The five CTEM stages

CTEM is a term coined by Gartner for a five-stage cycle. The stages are widely used across the industry; the descriptions below are practical rather than a restatement of any analyst text.

Scoping

Pick scopes the business recognises and that fit in one cycle (often a quarter): the external attack surface, a crown-jewel application and its supporting infrastructure, the identity plane (Active Directory, Entra ID, the IdP, privileged and service accounts), a SaaS estate, or a group of suppliers with access. For each, record the critical assets that define impact, mapping to NIST CSF 2.0 ID.AM-05: "Assets are prioritized based on classification, criticality, resources, and impact on the mission". Attack path tools and prioritisation depend on this list; Microsoft's exposure management documentation, for example, warns that paths may not be representative "if you don't fully define critical assets".

Discovery

Discovery joins sources that usually live in separate teams: external attack surface and certificate data (see the Attack Surface Management Guide), authenticated vulnerability scans, cloud posture findings, identity posture (group memberships, role assignments, MFA status, stale accounts), secret scanning across code and collaboration tools, EDR and logging coverage gaps, and SaaS configuration. Normalise each finding to an asset and an owner. A finding with no owner is itself an exposure, because nobody will fix it.

Prioritisation: exploitability, reachability, impact

Prioritisation combines three questions: is this being exploited or likely to be, can an attacker reach it from a realistic entry point, and what does it lead to? No single score answers all three.

CISA says organisations "should use the KEV catalog as an input to their vulnerability management prioritization framework". A workable rule: anything on KEV or with high EPSS that is internet-reachable or on an attack path to a critical asset goes to the top, then choke points, then the rest by SSVC outcome. CISA defines Act as needing supervisory and leadership attention with remediation "at the earliest opportunity", and Attend as remediation ahead of the normal schedule.

Attack paths and choke points

An attack path chains exposures: a phishable user, a workstation where a privileged account has logged on, a cached credential, a group membership granting admin on a server, a service account with rights to the domain. Microsoft's documentation describes paths as combining "assets and techniques to show end-to-end paths" from an entry point to critical assets, and choke points as "critical assets where multiple attack paths intersect". Open-source tools such as BloodHound Community Edition use "graph theory to reveal hidden and often unintended relationships within Active Directory and Entra ID". The value for prioritisation is that removing one choke point in the attack graph (a group membership, a stale delegation, an over-privileged service principal) can close dozens of paths at once, which is a better use of a change window than patching low-reachability CVEs. Paths are dynamic: a logon or a group change creates or removes them, so analysis must be refreshed every cycle.

Where identity fits: identity exposures

Many of the shortest attack paths contain no CVE. They abuse ATT&CK T1078 Valid Accounts (default, domain, local and cloud accounts) and T1552 Unsecured Credentials, including T1552.001 Credentials In Files and T1552.004 Private Keys. AA23-278A notes "Service accounts are enticing targets for malicious actors", often with elevated permissions and open to Kerberoasting. Treat identity exposures as first-class findings in every CTEM cycle.

Identity posture tooling and graph analysis are covered in the ISPM Guide, and secret storage in the Secrets Management Guide.

Validation: proving exploitability

Security validation answers three questions for each shortlisted exposure: can an attacker actually reach and use it here, would existing controls prevent or detect it, and what would the impact be. It is also what makes mobilisation work, because owners accept evidence more readily than scores.

CISA and NSA "recommend continually testing your security program, at scale, in a production environment" against ATT&CK techniques. BAS is the usual engine for that; see the Breach and Attack Simulation (BAS) Guide. Record the result of every validation, including "not exploitable here because control X stopped it", since that is evidence the control earns its cost.

Mobilisation and ownership

Mobilisation turns validated exposures into changes. It needs agreement in advance, not escalation after the fact.

• Named owners: every asset, identity and SaaS tenant in scope has an accountable owner (CSF 2.0 GV.RR-02: roles and responsibilities "are established, communicated, understood, and enforced"). For non-human identities, see the NHI Ownership Guide.
• Agreed timeframes: map priority to remediation windows signed off by IT leadership before the first cycle, aligned with the Act, Attend and Track outcomes.
• Fix, mitigate or accept: where a fix is not possible, record a compensating control (segmentation, conditional access, removing a group membership) and an expiry date. The NCSC puts it plainly: the organisation "must own the risks of not updating", and that is "a senior-level risk decision".
• Work in the owners' systems: raise changes in the tools IT and engineering already use, grouped by fix (one change removing a choke point) rather than by finding.
• Close the loop: re-validate after the change and feed the result into the next cycle (CSF 2.0 ID.RA-06: risk responses are "chosen, prioritized, planned, tracked, and communicated").

Implementing a CTEM programme

1. Baseline. Measure the current backlog, mean time to remediate KEV items and the share of findings with an owner. This is the comparison point for everything later.
2. Pick a pilot scope. One scope with an engaged business owner, often the external attack surface or the identity plane, and a cycle of 8 to 12 weeks.
3. Agree the rules first. Prioritisation criteria, remediation windows, the exception process and who signs off risk acceptance.
4. Run one full cycle. Discovery, prioritisation to a shortlist small enough to validate (tens, not thousands), validation, mobilisation. Track what was fixed, mitigated and accepted.
5. Review and adjust. Were validated findings disputed? Did fixes close the paths? Tune criteria before widening. If the pilot generates more work than owners can absorb, narrow the scope rather than lowering the bar.
6. Add scopes in rotation. Run scopes on staggered cycles so validation capacity is used evenly, and keep continuous monitoring (KEV, leaked secrets, new internet-facing assets) running between cycles.

Choosing an approach and programme maturity

Small organisations rarely need a dedicated exposure platform. A combined asset and identity inventory, KEV and EPSS feeds on scanner output, an open-source attack path tool for the directory and an annual penetration test give most of the value, run by one owner on a quarterly cycle. Large organisations usually need an aggregation layer (often sold as unified exposure management) that de-duplicates findings across scanners, cloud, identity and SaaS tools and maps them to owners; the decision is less about features than whether it integrates with the CMDB, identity sources and ticketing already in place. Buy validation (BAS, or the wider adversarial exposure validation category) after prioritisation works, not before: validating an unprioritised list wastes it. Treat any single exposure score a platform produces as a sorting aid: ask which inputs drive it and check it against KEV status and attack path position.

Metrics and reporting

Report outcomes, not finding counts. Useful measures:

• Validated exposure closure time: median days from validation to fix or approved mitigation, by priority.
• KEV exposure window: days KEV-listed vulnerabilities stay open on reachable assets.
• Attack paths to critical assets: count of paths and choke points per scope, cycle on cycle.
• Standing privilege and exposed secrets: privileged accounts without just-in-time elevation, and valid leaked secrets open longer than 24 hours.
• Control effectiveness: share of BAS scenarios prevented or detected for the techniques in scope.
• Ownership coverage: share of assets and identities in scope with a named owner, and exceptions past their expiry date.

For executives and risk committees, present each cycle as: the scope, the few paths that could reach critical assets, what was fixed, what was accepted and by whom, and what remains. That framing answers the question boards actually ask, which is whether the most likely routes to serious harm are closing. See the Cyber Risk Quantification Guide for expressing it in financial terms.

Framework mapping

Common failure patterns

• Rebranding the backlog: the same CVE list with a new dashboard, no scoping and no validation. Nothing changes except the vocabulary.
• Ignoring non-CVE exposures: remote access without MFA is not a vulnerability in a scanner's sense, yet the Change Healthcare breach started with one Citrix login without MFA.
• Forgotten scopes: test tenants, legacy apps and supplier-held access fall outside every scope. In the Midnight Blizzard breach a forgotten test tenant and an OAuth app led to executive mailboxes.
• Leaked secrets treated as low severity: a valid key is a working entry point. The Private-CISA GitHub leak left AWS GovCloud admin keys in a public repository for six months.
• Validation without mobilisation: proven attack paths reported but never assigned, because no owner or timeframe was agreed before the cycle.
• Stale critical asset lists: attack path results look clean because the systems that matter were never tagged as critical.

Practitioner checklist

• Define CTEM scopes with business owners and a critical asset list for each.
• Bring identity, cloud, SaaS and secret findings into discovery alongside CVE scans.
• Prioritise with KEV, EPSS and SSVC outcomes plus attack path position, not severity scores alone.
• Run attack path analysis on the directory and cloud every cycle and track choke points.
• Treat standing privilege, overprivileged NHIs and valid leaked secrets as top-tier exposures.
• Validate the shortlist with BAS, targeted testing or validity checks before assigning work.
• Agree owners, remediation windows and a senior sign-off route for risk acceptance before the first cycle.
• Re-validate after fixes and feed results into the next cycle.
• Report closed paths, KEV exposure window and control effectiveness rather than finding counts.

Standards and references

• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: Exploit Prediction Scoring System (EPSS)
• NSA and CISA: Top Ten Cybersecurity Misconfigurations (AA23-278A)
• OWASP: Non-Human Identities Top 10
• NCSC: Vulnerability management
• NIST: SP 800-40 Rev. 4 Guide to Enterprise Patch Management Planning

Related NHI Mgmt Group resources: Attack Surface Management Guide · Vulnerability Management Guide · Breach and Attack Simulation (BAS) Guide · Zero-Day and Exploited Vulnerabilities Guide · ISPM Guide