CTEM: From Visibility to Validated Risk
Continuous threat exposure management has a problem no vendor publishes its way through: almost every treatment of the cycle assumes agents, credentials and an internal estate you can instrument. This resource is about the external half of CTEM — the stages you can run from outside your network, from the position an unauthenticated attacker occupies, with no dependency on your inventory being right.
CTEM is a five-stage programme: scope, discover, prioritise, validate, mobilise. Three of those stages run externally end to end, one partially, and one decides whether any of the others mattered.
The cycle
Five stages, each with an internal assumption and an external answer
Most published treatments of CTEM make the left-hand assumptions silently. Read the right-hand column down and you have the external half; read where the two disagree and you have the argument this resource exists to settle.
| Stage | What the internal half assumes | What the external half can run |
|---|---|---|
| Scoping | A CMDB, an asset register or a cloud inventory, maintained by the organisation and handed to the programme as its starting list. | An apex domain, and everything the public registration, naming and certificate record says sits beneath it: subsidiaries, brands, acquired entities, marketing properties nobody decommissioned. Across first scans, outside-in discovery typically surfaces 30–60% more external assets than the internal inventory holds — the scoping stage is usually where the difference originates. |
| Discovery | Agents, credentialed scanners and API integrations, all of which find what they were pointed at. | Continuous outside-in discovery of what actually answers: domains and subdomains, open ports and service banners, web and API stacks, cloud storage, certificates, mobile binaries. |
| Prioritisation | Severity scores computed over an estate the scanner already trusts, with criticality inherited from the register. | Ranking by what an unauthenticated attacker could reach with a finding, on the asset it actually sits on — reachable and sensitive beats high-scored and internal every time. |
| Validation | Exploit attempts against internal hosts, run from a foothold the programme already holds. | Contextual, controlled, non-destructive validation where it is safe and authorised: whether an exposed key is live and what it opens, whether a leaked credential still authenticates, whether a service is exploitable rather than merely present. In practice 8–15% of surfaced exposures validate as genuinely exploitable, and that subset is what the remediation conversation should be about. Continuous Automated Red-Teaming is enabled gradually during onboarding, bounded to inventory already attributed to you, with the authorisation scope in writing. Not every finding is validated, and the ones that are not say so on their face. |
| Mobilisation | A ticket in the owning team's queue, on an asset the register already assigns to an owner. | Routing on assets whose owner is not written down anywhere — and for the cohort that carries your brand on infrastructure you do not own, the action is removal, not a ticket. That last cohort is why takedown sits inside the external half: see the cross-link below. |
The boundary
What the external half covers, and what it cannot see
The external half covers the outside of all five stages and the inside of none. That is worth stating plainly, because most of this market will not. 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, they need internal instrumentation, and any vendor that describes its product as covering them from the outside is describing something else.
What the external half 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. The outside half is also where an attacker without a foothold is obliged to begin, which is why it is the half that decides whether the internal programme is defending the right estate at all.
The reading path
Three articles, in this order
The order is deliberate: the external half first, then the vocabulary it sits among, then the stage practitioners get wrong most often. Each is published in full, ungated, and carries the same external-scope boundary this page does.
Start with the external half
The external half of a CTEM programme
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. The cornerstone treatment, and the piece this hub exists to frame.
Then the vocabulary
EASM, CAASM, vulnerability management, exposure management: which one do you actually need?
Four acronyms, one budget line. The side-by-side of what each category sees, what it needs and what it answers, plus the three cases that tell you which one your programme is actually missing.
Then the hardest stage
Prioritising external exposure you cannot patch this quarter
CVSS is the wrong ordering for external exposure, because it knows nothing about reachability or what an asset is worth to an attacker. What to do with the exposures you can only watch, and how to sequence the ones you cannot.
Method
What this resource is, and what it deliberately is not
A resource page that only a vendor could have written is a brochure with a glossary. The test each section here had to pass: would it still be worth reading if the reader never bought anything from us? The five-stage table and the boundary section pass it on their own; the reading path passes it because every article in it argues a position a buyer can use against us.
What is absent matters as much as what is present. The exclusions below are the framing, stated where the reader can hold us to it.
How this hub is written As of October 2026
- This is a resource, not a capability page. It exists to make the external half of the CTEM cycle legible to the people running the programme, and it would be worth reading if ShadowMap did not exist.
- The five-stage reading is written against the framework as Gartner published it: scope, discover, prioritise, validate, mobilise. Each stage is treated from outside the perimeter, the position our product occupies.
- The two figures on this page are aggregates, not case studies: the 30–60% discovery delta is observed across first scans, and the 8–15% validation rate describes where safe, authorised validation confirms real exploitability. Neither describes any customer.
Deliberately excluded
- No accuracy, false-positive or suppression figure, ours or anyone else's.
- No takedown completion time in either direction. Removal depends on counterparties nobody in this category controls.
- No customer engagement data, names or examples.
Questions this page gets asked
CTEM, and the boundary around it
What is CTEM?
Continuous threat exposure management, the five-stage programme framework Gartner introduced in 2022: scope the estate, discover exposures, prioritise them, validate whether they are real, and mobilise the organisation to act. It is a programme rather than a product category, and it spans internal and external scope deliberately, because an exposure programme that only sees one half is defending half an estate.
What is the external half of CTEM?
The stages as they can be run from outside your network, from the position an unauthenticated attacker occupies, with no agents, no credentials and no dependency on your inventory being right. Three of the five stages run externally end to end, validation runs where it is safe and authorised, and mobilisation is the stage that decides whether any of the others mattered.
Does ShadowMap do CTEM?
ShadowMap supports the external half of a CTEM programme; it does not replace the programme. CTEM spans internal ground no outside-in product can see, and the distinction matters when you write a programme's scope or an RFP. What ShadowMap runs is EASM and Continuous Automated Red-Teaming inside your CTEM programme: external discovery, prioritisation and validation, as inputs to the programme you run. A vendor that claims the whole framework from the outside is claiming the half it cannot see.
Can you run a CTEM programme without agents?
The external half, yes — that is the entire subject of this resource, and the external-half article linked below walks all five stages under that constraint. The internal stages still need instrumentation, which is why most enterprises run both halves and why the two need a single prioritisation layer between them rather than two queues that never meet.
Where this connects
The capabilities the external half runs on, and the working documents
See what the outside of your estate answers for
One apex domain is the entire input. No seed list, no allowlist, nothing to install. You get a written inventory you can lay beside your own record — the scoping stage, run against your estate, whichever programme it ends up feeding.