Continuous Threat Exposure Management: a critical review and an evidence-led operating model

A finding states that a weakness exists on an asset. An exposure states that an adversary could use it to cause a consequence that matters. The difference explains why organisations can close thousands of findings without reducing risk. We define an exposure as a tuple:

where a is an asset or identity; w a weakness, which may be a CVE, a misconfiguration, an excessive privilege, an exposed secret or a process gap; π the path by which an adversary can reach w from a position it can occupy; τ the threat evidence that the weakness class is exploited; and c the consequence for a scoped business service. A finding supplies only a and w. CTEM’s later stages exist to establish the other three, and an exposure becomes actionable only when π and c are known.

The definition deliberately includes weaknesses that have no CVE. Incident data show why. In Mandiant’s 2026 investigations, exploits led initial infection vectors at 32%, but voice phishing (11%) and prior compromise (10%) followed [2]; neither appears in a vulnerability scan, yet both are exposures of identity and process that a scoped programme can discover and reduce. Fig. 1 shows the leading vectors.

Verizon’s 2026 report, based on incidents between November 2024 and October 2025, likewise places vulnerability exploitation first at 31% of breaches [1]. Both sources describe non-random samples, so they establish the importance of exploitation, not its rate in any one population.

Gartner’s five stages fall naturally into two phases. Scoping, discovery and prioritisation diagnose exposure; validation and mobilisation act on it. Many programmes already perform each stage somewhere: asset inventory in IT, scanning in security, penetration testing through a supplier, remediation in operations. What they lack is a shared record that carries an exposure from one stage to the next. Without it, the evidence produced in validation never reaches the person deciding whether to accept the risk.

We therefore propose a single exposure decision record (EDR) at the centre of the cycle (Fig. 2). Each stage reads from and writes to it. The EDR is deliberately small: it should let an accountable owner understand the decision without opening the scanner, the test report or the ticket. Table III lists its fields; a CSV template is provided with this paper.

Stage names after Gartner [3], [4]. The central decision record is proposed by this paper. Conceptual model, not observed data.

Scoping is the stage most often skipped, because scanners make it feel unnecessary: the scope becomes whatever the tool can reach. CTEM inverts this. A scope is a business statement, such as “customer payment initiation and the identities that administer it”, combined with the adversary positions that matter: the internet, a compromised supplier, a phished employee, or an insider with standard access. This mirrors the framing of risk assessment in NIST SP 800-30, which starts from the organisation’s mission and threat sources before vulnerabilities [27], and CSF 2.0’s requirement that critical services and dependencies be understood [22].

Three properties make a scope workable. It is bounded, small enough to complete one cycle within a quarter. It is owned, with a business owner who can accept residual risk. And it is testable, meaning validation can be performed safely within it. The external attack surface and the identity plane of a critical SaaS service are practical first scopes because both are reachable by any adversary and both are commonly under-inventoried.

Discovery has two parts: finding the assets in scope and finding their weaknesses. Asset discovery should reconcile at least the configuration management database, cloud provider inventories, identity provider records, certificate transparency and external scanning, because each misses something the others see. CIS Controls 1 and 2 and CSF ID.AM set the baseline [24], [22].

Weakness discovery should cover the classes in (1), not only CVEs: misconfigurations, excessive or dormant privileges, exposed credentials and keys, and unsupported software. For CVEs, a recent change matters. Programmes have long relied on the US National Vulnerability Database to add CVSS scores and product data to each CVE. Effycace’s analysis found that NVD itself scored 83.8% of CVEs with 2023 identifiers but only 15.3% of those with 2026 identifiers (Fig. 3), and that 44.0% of exploited vulnerabilities in its data had no NVD score at all [6]. Tools that read only NVD scores will silently under-rank new vulnerabilities. Discovery must take severity from the CVE Numbering Authority, usually the vendor, and from vendor advisories.

The central empirical question for CTEM is whether any prioritisation signal can tell defenders in advance which exposures will be used. The evidence says that each signal helps and none suffices. In Effycace’s back-test across eleven quarterly windows, fixing the 10% of the backlog rated CVSS Critical would have caught 43.6% of later-exploited vulnerabilities; the same number chosen by highest EPSS would have caught 38.5% (Fig. 4). Combining the two, “Critical, or EPSS of 10% or more”, flagged 11.1% of the backlog and caught 53.1% [6]. This replicates, with current data, the earlier finding that severity alone is a weak proxy for exploitation [10], and it qualifies the common view that EPSS simply replaces CVSS [11].

Two further points shape the design. First, scores describe vulnerabilities in general, not their position in a particular environment; 11.7% of later-exploited vulnerabilities in the same data were rated only Medium or Low with EPSS below 1% [6], so reachability and consequence must carry weight of their own. Second, a single ranked list encourages teams to work from the top until capacity runs out, which hides the decision about what is left. Decision trees such as SSVC address the second problem by producing categories rather than ranks [15].

We propose a lane model that combines these lessons (Fig. 5). An exposure enters the matrix only if a path from an adversary-accessible position exists; unreachable items are recorded and monitored. Its lane is then set by exploitation evidence and consequence for the scoped service, and validation may move it one lane:

Here v = +1 when validation confirms the path, −1 when a compensating control is shown to block it, and 0 when validation is inconclusive or not performed. The target windows are proposals to be calibrated against each organisation’s change capacity; the Emergency window is set inside the two-week KEV deadline of BOD 22-01 [14] because of the exploitation speeds discussed next.

Proposed model. Thresholds follow the signals tested in EFF-RR-2026-002 [6]; target windows are proposals, not benchmarks.

CTEM is described as a cycle, and cycles have a cadence. Exploitation does not. Of 739 newly disclosed vulnerabilities later added to KEV, 52.5% were confirmed as exploited within a week of publication and 26.1% on or before the day they were published [5]. Across quarterly windows, 69.2% of the vulnerabilities confirmed as exploited were published during that same quarter, so they could not have been on any backlog ranked at its start [6]. Fig. 6 shows how old each vulnerability was when it was listed.

The distribution is bimodal. About 43% of additions arrive within a week of publication, which no monthly cycle can absorb, while about 22% concern vulnerabilities more than a year old, which a well-run cycle should already have treated. The design consequence is that CTEM needs two mechanisms: the scoped cycle for the accumulated backlog, and a fast lane triggered by events. We propose four triggers: a KEV listing or credible intelligence of exploitation for a product present in any scope; a vendor out-of-band advisory for an internet-facing product; a public exploit for a Critical vulnerability on a reachable asset; and discovery of exposed credentials or keys. A fast-lane item opens an EDR immediately, starts in the Emergency lane, and is validated in parallel with mitigation rather than before it.

Validation is the stage that distinguishes CTEM from risk-based vulnerability management. Its purpose is to replace an inference (“this is probably exploitable here”) with evidence (“we reached the payment database from the internet using this path”, or “the web application firewall blocked every variant we tried”). Validation answers three questions: whether the attack would work, whether detection and response would notice it, and whether the proposed fix closes the path. Table IV compares the available techniques.

Two rules keep validation proportionate. First, validate the top of the queue, not all of it: every Emergency and Priority exposure on a critical service, and a sample of the rest to estimate how well prioritisation is working. Second, record the result in a fixed vocabulary (confirmed, blocked by control, not reachable, inconclusive) with the method and date, because the ratio of confirmed to attempted validations is itself a measure of prioritisation precision (Section 4, component 9). Validation in production must be authorised, scoped and run under agreed rules of engagement; for regulated financial institutions in Singapore, the MAS guidelines set expectations for vulnerability assessment, penetration testing and adversarial attack simulation exercises [26].

Most exposure is closed by people outside the security team: system owners, platform engineers, application developers and suppliers. Mobilisation is the organisational work of getting validated exposures treated. It is the last stage of the cycle and, in practice, the one where programmes most often stall. Three mechanisms matter.

• Pre-agreed decision rights. Target windows by lane, and who may approve an exception at each level, are agreed with system owners in advance and approved by the risk committee. During an emergency the discussion is then about execution, not authority.
• A wider set of treatments. Patching is one option among several. Configuration change, compensating controls, segmentation, retiring the asset or redesigning the service are often faster or more durable, and validation can show that they work.
• Expiring exceptions. Every accepted exposure has an owner, a rationale, an expiry date and re-open triggers in the EDR. Accepted exposures roll up into the cybersecurity risk register and then into enterprise risk reporting, as NIST IR 8286 describes [23], satisfying CSF 2.0 ID.RA-06 on tracked risk responses [22].

Conventional programme metrics, such as findings closed or percentage of patches applied within SLA, measure effort. They can improve while exposure grows, and once they become targets they invite gaming, in the sense of Strathern’s formulation of Goodhart’s law that a measure which becomes a target ceases to be a good measure [28]. CTEM needs outcome metrics tied to scopes. The central one is the exposure window:

where t_evidence is the earliest time the organisation had evidence that exposure i was exploitable in its environment (a KEV listing, a validated path or a fast-lane trigger) and t_treated is when a fix or effective mitigation was verified. Report the median and 90th percentile per scope and lane, because means are distorted by long-lived exceptions. Table V sets out the proposed metric set; a CSV of definitions accompanies this paper.

Maturity models for security are often scored by whether practices exist. For CTEM that is the wrong test, because each practice can exist without reducing exposure. The model in Fig. 7 defines each level by the evidence a programme can produce: at Level 2, a record of which KEV items were in scope and how quickly they were treated; at Level 3, decision records per scope; at Level 4, validation results that changed lanes and treatments; at Level 5, metric trends that changed scope, investment or architecture.

Most organisations implementing CTEM begin between Levels 1 and 2. The practical goal for a first year is Level 3 for one or two critical scopes, with a fast lane operating across the whole estate. Level 4 requires validation capability, internal or contracted, and Level 5 requires at least several cycles of metric history.

Proposed model. It is not a benchmark and has not been calibrated against a population of organisations.

CTEM is not a compliance framework, and adopting it should not create a parallel reporting line. Table VI maps each stage to control objectives most organisations already report against, so that CTEM evidence can satisfy existing assurance requirements.

A hypothetical Singapore logistics company runs a customer portal used by shippers to book cargo and view invoices. Its first CTEM scope is “the customer portal, its single sign-on, and the remote-access path used by its two hosting suppliers”, owned by the head of digital channels, with the internet and a compromised supplier account as adversary positions. Table VII traces the cycle. All values are hypothetical and are chosen only to show how the stages narrow the work and change its nature.

The point of the example is the change in output. A conventional programme would report 2,400 findings and an SLA percentage. The CTEM cycle reports that one confirmed path to customer data was closed in three days, that an unknown asset was found and assessed, and that one exposure is accepted, by whom and until when.

Answering RQ1, CTEM adds little that is technically new. Asset discovery, scanning, threat-informed prioritisation, penetration testing and remediation governance all pre-date it [8], [15], [16], [20]. Its contribution is integrative: it binds those practices into one cycle, insists that scope be set in business terms, and makes validation a routine stage rather than an annual event. That contribution is real, but it is organisational, and its value therefore depends on execution more than on tooling.

Four weaknesses deserve attention. Definitional drift: because CTEM is defined by an analyst firm and implemented largely through vendor products, its meaning has widened to cover almost any exposure-related product; organisations should define it by the outputs in Table III, not by product features. Unverified claims: the forecast of a two-thirds reduction in breaches by 2026 [21] has, to our knowledge, not been tested in any transparent study, and should not be used to justify investment. Validation cost and risk: validation in production can disrupt services, and its coverage will always be partial. Data dependence: the decline in NVD enrichment (Fig. 3) shows that CTEM rests on a vulnerability-data supply chain that organisations do not control.

Table VIII answers RQ3 by assessing the proposed operating model against the criteria set out in Section 3.