The external half of a CTEM programme

Continuous threat exposure management has had an unusual career for an analyst framework. Most are absorbed as vocabulary and quietly discarded as practice. CTEM was adopted as practice, largely because it described something security teams were already attempting without a name for it, and gave them a sequence for doing it deliberately: scope, discover, prioritise, validate, mobilise, and then begin again.

The difficulty arrives at implementation. Almost every published treatment of the cycle assumes agents, credentials and an internal estate you are able to instrument. That is a reasonable assumption for the half of the problem that lives inside your network. It is the wrong assumption for the half that does not — and the outside half is where an attacker without a foothold is obliged to begin.

What follows is a treatment of that external half specifically: what each of the five stages means when you have no agents, no credentials and no prior inventory to work from, where the external half is genuinely stronger than the internal one, and where it stops. If you want the framework in general rather than the external slice of it, that sits in our CTEM resource hub.

The admission that shapes everything below

We cover the outside of all five stages and the inside of none.

That sentence is worth stating early because most of this market will not state it. Once "exposure management" became the category everyone wanted to be in, the honest scope boundaries went soft — a scanner acquired a dashboard and became a programme, a credential feed acquired a severity column and became prioritisation. The result is that buyers now routinely purchase a second tool believing it covers the first, and discover the overlap eighteen months later during an incident.

An external programme cannot tell you the patch level of a server inside your network. It cannot see endpoint telemetry, lateral movement, privilege relationships inside your directory, or the segmentation between your production and corporate networks. Those are real CTEM concerns and they need internal instrumentation.

What it can do — and this is the part internal tooling structurally cannot — is run the entire cycle against the estate you did not know you had, from the position an unauthenticated attacker occupies, with no dependency on your inventory being right.

Stage one — scoping, and the word "external" doing more work than it looks

Scoping is where most CTEM programmes go wrong, because it is treated as an administrative step before the interesting work rather than as the decision that determines everything downstream.

Externally, the question is deceptively simple: what belongs to you? In a single-entity organisation with one apex domain and a central engineering function, that question has an answer someone in the room already knows. In an enterprise, it does not.

Consider what the boundary actually has to absorb. Subsidiaries acquired over a decade, some rebranded, some still operating their original domains and certificates. Regional entities registering their own infrastructure under local corporate cards. Joint ventures where the brand is yours and the hosting is not. Marketing microsites commissioned by an agency and never decommissioned. Product teams in a decentralised engineering organisation spinning up cloud accounts against a departmental budget, entirely legitimately, entirely outside the process that would have registered them.

Every one of those is externally reachable, externally attributable to your brand, and absent from the scan range that vulnerability management was pointed at.

Then there is the boundary most scoping exercises exclude and should not: your vendors. A supplier's external posture is part of your exposure, because their compromise becomes your incident and their credentials frequently open your systems. Assessing a vendor with the same outside-in method used on your own estate produces something a questionnaire cannot — current, observed evidence rather than an attested answer from eleven months ago. In practice this is what makes vendor-incident response fast: when a supplier is breached, an organisation with an already-assessed external picture of that supplier responds substantially faster than one starting from a questionnaire archive, on the order of 60–80% faster in our customer base.

The practical scoping decision is therefore not "which domains do we monitor" but three separate questions with three different answers: which entities are in the legal boundary, which of those are in the monitoring boundary, and which are in the validation boundary — the narrower set against which authenticated testing is contractually authorised. Conflating the last two is how vendors end up testing things they should not.

Stage two — discovery, without consulting the inventory

Internal discovery reconciles the inventories you already hold. External discovery must assume you hold none.

The methodological difference matters more than it sounds. A process that begins from your asset register can only ever refine your asset register. A process that begins from a seed — a company name, one or two apex domains, a set of legal entities — and reconstructs the estate from public evidence produces an inventory that is genuinely independent of your own. Certificate transparency logs, passive DNS, registration records, autonomous system and cloud IP attribution, public code hosts, mobile app stores. The same sources an attacker uses, because there is no other outside-in source of truth.

The value of that independence shows up as a number. Across our customer base, outside-in discovery typically surfaces 30–60% more internet-facing assets than the organisation's own inventory contained. That gap is not a criticism of anyone's CMDB hygiene; it is a structural property of large organisations, and it is the reason the discovery stage cannot be satisfied by better internal reconciliation.

External discovery also extends past infrastructure in a way internal discovery has no route to. Once the boundary is established, the same attribution logic applies to exposures that live entirely outside your perimeter: source code and secrets published to public repositories, identity exposure in stealer logs and breach corpora, impersonating and typosquatted domains, and the material circulating on criminal forums and channels. Our own collection across this last category holds over 12 billion records and roughly 41 terabytes of retained source material, drawn from 466 dark-web and breach-forum sources and 778 Telegram channels, spanning 26 stealer families — retained permanently, so that improved parsers can be re-run across historical data rather than only forward.

Concretely, in a first thirty days, that surface typically produces between five and fifteen secrets that are still live, and somewhere between 200 and 800 stealer-log credentials attributable to the organisation. Neither of those is a number your internal scanners were ever positioned to return.

Stage three — prioritisation, and why CVSS is the wrong ordering

CVSS is a good score being asked to do a job it was not designed for.

It describes the intrinsic severity of a vulnerability in the abstract: how bad this class of flaw is when present. That is genuinely useful for patch policy across a known estate. It is close to useless as an ordering function for external exposure, for a reason that becomes obvious the moment you list what external findings actually consist of.

A leaked API key has no CVE. A typosquatted domain with valid TLS and a login page cloned from your customer portal has no CVSS vector. A working credential in an employee's browser store is not a vulnerability at all in the traditional sense. A vendor with an expired certificate and an exposed administrative interface is not something you can patch. A forgotten staging environment running an application three major versions behind is scored identically whether it holds production data or nothing.

Externally, four different inputs determine what should be worked first, and none of them is intrinsic severity:

• Is it live? Does the key still authenticate, does the host still respond, is the credential still valid?
• Is it reachable? Is there an unauthenticated path to it from the internet, or is it behind controls that make the theoretical severity irrelevant?
• Is it yours? Attribution confidence is a priority input. A high-severity finding on an asset that turns out to belong to a similarly named company is not a finding.
• Has it been used, or is it being targeted? Whether the exposure class, the sector or the specific infrastructure appears in active adversary activity. Our platform maintains 1,000+ curated threat-actor profiles precisely so this question has an answer rather than an intuition.

Ordering by those four produces a materially different queue than ordering by score, and the difference is usually the difference between a queue that gets worked and a queue that becomes a quarterly appendix. This is the stage every published CTEM treatment skips, and it deserves its own treatment — we give it one in prioritising external exposure you cannot patch this quarter.

One operational note on how the reordering is done, because "AI-powered prioritisation" is a claim worth being precise about. In ShadowMap, contextual review assigns findings a verdict — Confirmed Exposure, Needs Review, Likely False Positive, Benign — and demoted items move to a filtered queue that remains fully searchable. Nothing is deleted, because a filter you cannot inspect is indistinguishable from a tool that lost your data. Equally, several capabilities that vendors commonly market as AI are deterministic here and described as such: universal search, automated mitigation and the action centre are rules and workflows, not models. We publish no accuracy percentage for the review layer, because a single figure across every capability and radically different finding types would be a marketing number rather than a measurement.

Stage four — validation, and the limits of what can honestly be proven

Validation is the stage that separates an exposure programme from a feed, and it is also the stage where claims should be read most sceptically.

The premise is sound: a finding that has been demonstrated to be real is worth more than a finding that has been inferred, because it removes the triage step where a human spends an afternoon establishing whether a report is worth acting on. In practice, of everything surfaced across a customer's external estate, roughly 8–15% is validated as genuinely exploitable. That proportion is the actual working queue, and knowing it is a fundamentally different position than holding an unranked list.

The important discipline is what validation does not attempt. Ours is contextual, controlled and non-destructive, conducted within an authorised scope established contractually and configured during onboarding rather than switched on at go-live. It establishes whether an exposed key is live and what it opens. It establishes whether a leaked credential still authenticates against a surface within scope, and records the outcome as a state — confirmed working, inconclusive, rejected, or deliberately not tested. That last state exists because a credential belonging to your customer, or to an employee's personal account on a third-party service, is real exposure that nobody should be attempting to authenticate. Reporting it as untested is the correct answer.

It does not run public exploit code against production. It does not attempt authentication outside authorised scope. And it does not claim that everything in every category has been validated before it reached you — that is not achievable simultaneously across phishing detection, brand monitoring, threat-actor tracking and infrastructure discovery, and a vendor asserting it is describing an aspiration.

Validation of external exposure also does not replace a scoped human red team. It answers "is this specific artefact usable", which is a narrower and more mechanical question than "can a skilled adversary achieve an objective against this organisation".

Stage five — mobilisation, which decides whether any of the above mattered

Mobilisation is where the majority of exposure programmes quietly fail, and it fails for organisational reasons rather than technical ones. A validated, correctly ordered finding that reaches nobody with the authority to fix it has produced no security outcome whatsoever. It has produced a report.

Externally this problem is harder than it is internally, because external findings frequently belong to people who do not work in security and may not work for you. A typosquatted domain is a legal and brand matter. A leaked key in a public repository belongs to a developer in a product team who may not know the repository is public. A forgotten marketing microsite belongs to an agency whose contract ended. A vendor's exposed interface belongs to the vendor, and reaches them through procurement.

What makes this workable is unglamorous and mostly infrastructural: every finding carries a state that reflects real-world progress rather than platform activity; findings are assignable to named owners including owners outside the security team; SLA policies attach to severity so that ageing is visible rather than discovered at audit; and every state transition, suppression and accepted-risk decision is recorded in an audit trail that survives the person who made it. Suppression in particular has to be first-class — an exposure management programme that cannot record "we have seen this, we have decided to accept it, here is who decided and when" will re-litigate the same findings indefinitely.

The other half is integration. Findings that require a security analyst to copy them into the system where work actually happens will lose to findings that arrive there automatically, every time. Eighty-plus integrations exist for that single reason, and their purpose is to make the ticketing system, not the exposure platform, the place the work is done.

Where mobilisation is built properly, the measurable effect is on elapsed time rather than finding volume: customers typically reach action on high-severity findings 40–60% faster than they did through a report-and-triage cycle. That is the number worth holding a programme to, because it is the only one that describes whether the cycle closed.

What the external half does not cover

Stated plainly, so that nobody buys this expecting the other half.

An external programme has no visibility into internal hosts, endpoint telemetry, patch levels, lateral movement, privilege escalation paths within your directory, insider activity, or the effectiveness of your internal controls. It cannot tell you whether an attacker who obtained a foothold could move from a workstation to a domain controller. It cannot tell you whether the working credential it surfaced was actually used — that answer lives in your authentication logs, and the correct sequence is to identify the credential here, then look there for a successful login you were not expecting.

You need an internal programme. Vulnerability management, endpoint detection, identity governance and internal validation are not optional, and no external platform substitutes for them. Anyone selling you one as a replacement for the other is selling you a gap. The distinction between these categories, and how to work out which one you are actually missing, is set out in EASM, CAASM, vulnerability management and exposure management.

Running the external half without a full CTEM programme in place

A reasonable objection at this point is that CTEM is a programme, the programme spans both halves, and running one half is running half a programme.

That is true and it is still the right sequence, for three reasons.

First, the external half is the only half an attacker can reach without already having compromised you. It is the entry surface by definition, and it is the surface most likely to contain assets nobody is currently accountable for.

Second, it requires nothing deployed. There are no agents to roll out, no credentials to provision, no change advisory board, no negotiation with an infrastructure team about scanning windows. The prerequisite is a list of legal entities and domains. That means the external half can be running while the internal programme is still in procurement — which is frequently the real situation, rather than the tidy sequential one the framework implies.

Third, and least comfortable, the external half tends to reveal how accurate the internal programme's scope actually is. When outside-in discovery returns 30–60% more assets than the register held, the finding is not really about the external estate. It is about how much of your internal programme was assessing an incomplete list.

The practical starting point is narrow. Scope one legal entity and its apex domains rather than the full group. Run discovery and reconcile it against whatever inventory you hold, and treat the delta — not the total — as the first result. Take one high-value exposure class where validation is decisive, usually live secrets or working credentials, and run it end to end through assignment, remediation and closure. That single closed loop establishes whether the mobilisation stage works in your organisation, which is the thing most likely to break and the thing least likely to be tested by a feature evaluation.

Then widen the boundary. Programmes fail from scoping too broadly on day one far more often than from starting too small. If you are at the point of evaluating platforms for this, our evaluation guidance covers what a proof of concept should actually be testing, and the platform overview sets out how the capabilities map onto the five stages described here.

Where is your programme actually strong? The External Exposure Maturity Model scores five levels across seven capability areas — attack surface, data exposure, identity exposure, brand, validation, vendor risk and the operating layer — using observable behaviours rather than aspirational language, plus the three moves that most reliably advance a level and an honest account of what the top level costs. → Get the maturity model

Related: CTEM resource hub · The ShadowMap platform · Prioritising exposure you cannot patch