Two Acronyms, One Objective

Attack Surface Management (ASM) and Continuous Threat Exposure Management (CTEM) both aim to reduce cyber risk. They're often mentioned together — sometimes interchangeably — but they represent fundamentally different scopes and capabilities.

Understanding the distinction matters because choosing the wrong framing leads to the wrong investment. Organizations that treat ASM as "good enough" leave critical gaps in their security posture. Those that understand CTEM as the larger framework know exactly where ASM fits — and where it stops.

What ASM Does — and Doesn't Do

Attack Surface Management platforms focus on discovery: finding all assets, services, and exposures visible from an attacker's perspective. A typical ASM solution:

Discovers external-facing assets: domains, subdomains, IP ranges, cloud services, SaaS applications, exposed APIs
Inventories the attack surface: ports, services, technologies, SSL certificates, DNS records
Monitors for changes: new assets appearing, services exposed, configurations modified
Alerts on known exposures: CVEs in detected software versions, misconfigurations, expired certificates

This is valuable and necessary. Many organizations don't know the full extent of their attack surface. Shadow IT, cloud sprawl, and M&A activity create exposure that internal asset inventories miss.

But discovery is only the first step. Knowing that a service exists and has a CVE doesn't tell you:

Is the vulnerability actually exploitable in your environment?
Does an attacker have a viable path from this asset to critical targets?
Has the remediation you applied actually closed the exposure?
Did last week's network change reintroduce a previously fixed vulnerability?

These questions require validation, prioritization, remediation tracking, and verification — capabilities beyond ASM's scope.

The CTEM Framework

CTEM, as defined by Gartner, is a five-phase continuous program:

Phase 1: Scoping

Define what matters. Not just "all external assets" but business-critical systems, crown jewels, regulatory scope, and operational boundaries. For OT/ICS environments, scoping extends to Level 0-3 of the Purdue Model — assets that ASM typically can't see because they're not internet-facing.

Phase 2: Discovery

Identify all assets, exposures, and potential attack paths within scope. This overlaps with ASM but goes deeper — internal discovery, OT protocol enumeration, identity mapping, and configuration analysis.

Phase 3: Prioritization

Rank exposures by actual business risk, not just CVSS score. Prioritization considers exploitability in context, attack path analysis, business impact of the target asset, active threat intelligence, and compensating controls. A CVSS 9.8 on an isolated test server ranks below a CVSS 6.5 on a directly reachable HMI controlling critical processes.

Phase 4: Validation

Prove whether exposures are genuinely exploitable. Safe exploitation testing, attack simulation, and control validation confirm that theoretical vulnerabilities translate to real risk — or don't. This is the phase that ASM lacks entirely.

Phase 5: Mobilization

Drive remediation through integrated workflows. Assign tickets, track resolution, define SLAs by risk tier, and verify that fixes actually work. Mobilization closes the loop — turning findings into action and action into verified risk reduction.

The Comparison

| Capability | ASM | CTEM | |---|---|---| | External asset discovery | ✅ Core capability | ✅ Included in Phase 2 | | Internal asset discovery | ❌ Out of scope | ✅ Full internal + OT | | Continuous monitoring | ✅ Surface-level changes | ✅ Deep configuration + exposure | | Vulnerability detection | ✅ Known CVEs from versions | ✅ Contextual exploitability | | Attack path analysis | ❌ No path modeling | ✅ Dynamic attack graphs | | Exploitation validation | ❌ Not performed | ✅ Safe, protocol-aware validation | | Remediation tracking | ⚠️ Basic alerting | ✅ Full workflow integration | | Verification of fixes | ❌ Not performed | ✅ Re-validation post-remediation | | OT/ICS protocol support | ❌ IT-focused | ✅ Modbus, DNP3, OPC UA, etc. | | Business risk scoring | ⚠️ Limited context | ✅ Asset criticality + path analysis |

Why ASM Alone Falls Short for Critical Infrastructure

For organizations operating critical infrastructure — energy, water, transportation, manufacturing — ASM addresses a narrow slice of the risk picture:

Visibility without context: ASM tells you a substation's engineering workstation has an exposed RDP service. It doesn't tell you that RDP → local admin → PLC programming software → Level 1 control = a complete attack path to physical process manipulation.

Discovery without validation: ASM identifies a CVE in your historian server's web interface. It doesn't verify whether the vulnerability is exploitable given your specific configuration, network segmentation, and authentication controls.

Alerting without action: ASM generates findings. CTEM generates findings, prioritizes them by business impact, validates exploitability, assigns remediation workflows, and verifies the fix. The difference between a report and a risk reduction.

ASM as a CTEM Component

ASM isn't wrong — it's incomplete. The best CTEM implementations incorporate ASM capabilities as their discovery engine while adding the validation, prioritization, mobilization, and verification layers that turn discovery into measurable risk reduction.

The question isn't "Do we need ASM or CTEM?" It's "Are we stopping at discovery, or closing the full exposure management loop?"

For critical infrastructure operators where unvalidated assumptions create safety risks, the answer is clear.