A working definition of CTEM
Gartner defines CTEM as a five-stage program: scope, discover, prioritise, validate, mobilise. In practice CTEM is a program-level discipline that consolidates attack-surface visibility, exposure prioritisation, validation through attack emulation, and remediation orchestration into one continuous loop. CTEM is not a single product; it is the workflow that ties EASM, CAASM, BAS, pentest-as-a-service, and vulnerability prioritisation together.
The five stages, decoded
- Scope. Pick the business surface that matters — a brand, a product, a region — and define what assets fall inside the program.
- Discover. Find every asset and exposure in that scope via EASM, CAASM, cloud configuration, identity, and code-level scanning.
- Prioritise. Combine technical severity (CVSS, EPSS, KEV) with business context (asset criticality, blast radius, compensating controls) into one queue.
- Validate. Prove which exposures are reachable and exploitable in your specific environment via BAS, automated pentest, or red-team review. This is the stage that separates CTEM from classic VM.
- Mobilise. Drive remediation through the right team's existing tooling — Jira / Linear / GitHub for engineering, ITSM for IT, with SLAs by priority tier.
CTEM vs EASM vs vulnerability management
These overlap heavily and the vendors have made the boundaries even fuzzier.
- EASM is the discovery-and-monitoring layer for internet-facing assets. It is an input to CTEM, not a substitute.
- CAASM aggregates internal asset inventory; another input.
- Classic vulnerability management is the scan-and-patch workflow. CTEM keeps it but adds the validate stage so you do not waste cycles patching things that are not actually reachable.
- BAS / Breach and Attack Simulation (Pentera, AttackIQ, Cymulate, Picus, SafeBreach, XM Cyber) provides the validate-and-prove-exploitability layer.
- PTaaS (HackerOne Assessments, Cobalt, Synack) extends validation with humans.
CTEM vendors in 2026
Two camps. Suite plays that bundle multiple CTEM stages into one platform, and best-of-breed stacks that you assemble:
- Suite plays. Tenable One, CrowdStrike Falcon Exposure Management, Rapid7 Exposure Command, Qualys VMDR + ETM, Microsoft Defender External Attack Surface Management + Defender for Endpoint vulnerability management.
- Best-of-breed EASM + ASM: CyCognito, IONIX, CYRISMA, Bitsight Attack Surface, runZero, watchTowr, Hadrian.
- BAS / validation: Pentera, XM Cyber, AttackIQ, SafeBreach, Cymulate, Picus.
- Prioritisation / orchestration: Vulcan Cyber, Nucleus Security, Phoenix Security, ArmorCode.
- PTaaS: HackerOne Assessments, Cobalt, Synack, Bugcrowd Penetration Testing.
Common pitfalls running a CTEM program
- Buying a tool, calling it a program. CTEM is workflow plus governance. Without an owner the scan results become noise.
- Skipping the validate stage. The hardest stage to staff but the one that delivers the biggest noise reduction.
- Misaligned remediation incentives. Engineering owns the fix; security owns the queue. Without shared OKRs the SLA is theoretical.
- Over-rotating on dashboards. CTEM produces beautiful charts. The metric that matters is mean-time-to-remediate for KEV-listed exposures on tier-0 assets.
A pragmatic rollout sequence
- Start with EASM coverage of one brand or business unit — the smallest scope that has real exposure.
- Stand up a prioritisation layer (Vulcan, Nucleus, or an in-platform module) and unify findings from EASM + cloud + vulnerability scanners.
- Add validation via BAS or automated pentest. Even one quarterly run materially changes the prioritisation queue.
- Wire remediation tickets into the owning team's existing system. Avoid a separate security-only ticket queue.
- Publish SLA performance monthly. The act of publishing changes behaviour faster than the tool change does.