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 holds for the half of the problem that lives inside your network, and it fails for the half that does not. The outside half is where an attacker without a foothold has to begin.

This piece covers the external half: 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 stronger than the internal one, and where it stops. The framework as a whole sits in our CTEM resource hub.

The scope boundary

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

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 internal tooling cannot, is run the whole cycle against the estate you did not know you had, from the position an unauthenticated attacker occupies, without depending on your inventory being right.

Stage one: scoping, and how much the word "external" has to cover

Scoping is where most CTEM programmes go wrong. It gets treated as an administrative step to clear before the interesting work, and everything downstream depends on it.

Externally, the question sounds 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.

Look at what the boundary 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 instead of an attested answer from eleven months ago. It also shortens vendor-incident response: when a supplier is breached, an organisation that already holds an external picture of that supplier responds roughly 60–80% faster than one working from a questionnaire archive, measured across 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. That last one is 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.

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. The gap is normal in large organisations, and it is why the discovery stage cannot be satisfied by better internal reconciliation.

External discovery also extends past infrastructure. Internal discovery has no route there at all. 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. It is retained permanently, so improved parsers can be re-run across the history and not only against new data.

In the 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. Internal scanners were never positioned to return either number.

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 useful for patch policy across a known estate. It is close to useless as an ordering function for external exposure, and the reason is obvious once you list what external findings 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. 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 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 wasted work.
• 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 so this question has an answer instead of an intuition.

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

One operational note on how the reordering is done, since "AI-powered prioritisation" covers several different mechanisms here. 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. Several capabilities that vendors commonly market as AI are deterministic here: universal search, automated mitigation and the action centre are rules and workflows, not models.

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

Validation is the stage that separates an exposure programme from a feed.

A finding that has been demonstrated to be real is worth more than one that has been inferred, because it removes the triage step where a human spends an afternoon establishing whether a report is worth acting on. Of everything surfaced across a customer's external estate, roughly 8–15% is validated as exploitable. That proportion is the working queue, and knowing it is worth considerably more than 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, not 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 trying to authenticate. Reporting it as untested is the right answer.

It does not run public exploit code against production. It does not attempt authentication outside authorised scope. And not every category is validated before it reaches you: phishing detection, brand monitoring, threat-actor tracking and infrastructure discovery cannot all be validated at once.

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 most exposure programmes quietly fail, and it fails for organisational reasons, not technical ones. A validated, correctly ordered finding that reaches nobody with the authority to fix it produces a report and no security outcome.

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 plumbing: every finding carries a state that reflects real-world progress, not platform activity; findings are assignable to named owners including owners outside the security team; SLA policies attach to severity so that ageing is visible instead of 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 a security analyst has to copy into the system where work happens will lose to findings that arrive there automatically, every time. Eighty-plus integrations exist for that one reason: the ticketing system, not the exposure platform, should be where the work is done.

Where mobilisation is built properly, the measurable effect shows up in elapsed time, not 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 to hold a programme to, because it is the only one that describes whether the cycle closed.

What the external half does not cover

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: 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. The distinction between these categories, and how to work out which one you are missing, is set out in EASM, CAASM, vulnerability management and exposure management.

Running the external half without a full CTEM programme in place

CTEM is a programme that spans both halves, and running one half is running half a programme.

Start with the external half anyway, 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, and the one 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. So the external half can be running while the internal programme is still in procurement, which is frequently how it goes.

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

The practical starting point is narrow. Scope one legal entity and its apex domains, not 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 stage most likely to break and the least likely to show up in 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 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 instead of aspirational language, plus the three moves that most reliably advance a level and what the top level costs. → Get the maturity model

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