Attack surface management (ASM) tools discover what you expose to the internet. Continuous external red teaming goes further: it tests whether those exposures are exploitable, chains them into attack paths, and proves the blast radius. The first tells you what exists. The second tells you what an attacker can do with it.
- ASM maps assets. EASM does it from outside the network. Neither proves whether a finding is exploitable or chains findings into a path.
- CTEM (Continuous Threat Exposure Management) adds a process: scoping, discovery, prioritization, validation, mobilization. Gartner coined the term.
- The gap is validation. Scanning finds the lock. Red teaming picks it, walks through the building, and shows you what's on the other side.
- Unit 42 found that organizations add an average of 300 new services a month to their external attack surface; 32% of new high or critical exposures come from these new services.
- Cylent's analysis of the CISA KEV catalog for 2026: 282 additions, +32% over 2025. Median time to the KEV list: 4 days. 27% added the same day or earlier. Most of those same-day additions are network and security appliances — the devices that sit on the perimeter.
What is attack surface management?
A category of tools that discover and inventory what your organization exposes. ASM started as an internal concept — cataloging servers, applications and endpoints. The "external" variant, EASM, shifted the perspective: instead of asking "what do we own?" it asks "what can someone on the internet see?"
Microsoft describes its Defender EASM product as a tool that "continuously discovers and maps your digital attack surface to give you an external view of your online infrastructure." What it discovers: domains, IP address blocks, hosts, email contacts, ASNs and Whois organizations.
That inventory is genuinely useful. You can't defend what you don't know about. CISA's Binding Operational Directive 23-01, which applies to US federal civilian agencies, requires automated asset discovery every 7 days and vulnerability enumeration every 14 days. The directive's rationale: "continuous and comprehensive asset visibility is a basic pre-condition" for managing risk.
The problem isn't what ASM finds. It's what it doesn't do with what it finds.
What does ASM miss?
The question it was never designed to answer: is this actually exploitable? An ASM tool will tell you that a Grafana instance is exposed to the internet. It won't tell you that anonymous access is on, that the Viewer role lets you read the database connection string, and that you can send arbitrary SQL through its proxy. It sees the door. It doesn't try the handle.
Here's what falls outside the scope of a typical ASM or EASM platform:
- Business-logic flaws and access-control errors. These require understanding what the application does, not just that it exists.
- Leaked credentials in context. ASM may alert on a credential leak. It won't tell you that the leaked token still works, that it gives write access to 232 private repositories, and that one of those repositories contains a cloud key from 2018 that opens your production storage.
- Supply chain and CI/CD. Pipelines don't appear in a port scan. Neither do pull-request triggers that exfiltrate publishing tokens.
- Mobile apps and their embedded secrets. An ASM tool scans what answers on the internet. It doesn't decompile the APK in the app store and check whether a server-side API key is compiled into the client.
- AI tools and what they index. No ASM platform checks what your internal AI assistant can surface from Slack and wikis.
- The path between findings. ASM reports findings in isolation. An attacker chains them: a low-severity exposed service leads to a credential, the credential leads to a repository, the repository leads to a production key.
Each of these is a real finding from our engagements. None of them is something an ASM tool would flag on its own.
What is CTEM and how does it differ?
Gartner's name for a continuous process, not a tool. Continuous Threat Exposure Management (CTEM) describes five stages: scoping, discovery, prioritization, validation and mobilization. The idea is that exposure management should be a cycle, not a project.
The important word in CTEM is "validation." Gartner's framework explicitly calls for testing whether exposures are exploitable, not just listing them. That's the stage most organizations skip — and the stage where the results change.
| Stage | What it asks | Who typically does it |
|---|---|---|
| Scoping | What matters to the business? | Security leadership |
| Discovery | What is exposed? | ASM / EASM tools |
| Prioritization | Which exposures carry the most risk? | Vulnerability management + threat intelligence |
| Validation | Is this actually exploitable? What does the path reach? | Penetration testing / red teaming |
| Mobilization | Can we fix it, and did the fix work? | Engineering + retesting |
CTEM is a useful framework. Where it gets stuck is that stages 1–3 are products you can buy, and stage 4 requires someone to actually attack your systems. Most CTEM implementations end up heavy on discovery and light on validation.
How do ASM, EASM, CTEM and continuous external red teaming compare?
The table below lays it out across ten capabilities. This is based on what we see in the field — from our own engagements and from what clients show us when they switch to continuous testing.
| Capability | ASM / EASM | CTEM (full process) | Continuous external red teaming |
|---|---|---|---|
| Asset discovery | Domains, subdomains, IPs, web interfaces | Same, with business-context scoping | Same, plus shadow GitHub orgs, browser extensions, mobile apps — from a company name |
| Known CVEs | Detected, auto-correlated | Detected, prioritized by exploitability context | Detected, and exploited to prove the path |
| Unknown vulnerabilities | Not covered — no CVE, no finding | Included if validation stage runs | Live testing: SQLi, SSRF, IDOR, auth logic, business-logic flaws |
| Exposed secrets | Credential-leak alerts | Credential monitoring | Found, used, and the blast radius proved |
| CI/CD and supply chain | Not covered | Scoped if included | Tested: pwn requests, workflow injection, runner token abuse |
| Mobile apps | Limited (web-facing APIs only) | Scoped if included | Decompiled and tested: embedded keys, API abuse |
| AI tools and shadow code | Not covered | Not covered | Tested: what AI assistants and shadow code expose |
| Change tracking | New subdomains and hosts | Continuous process, tool-dependent | Continuous monitoring of what's reachable + JS builds, repo commits, CI workflows |
| Signal quality | Alert queue, triage needed | Prioritized queue | Validated findings with request and response per hop |
| Human validation | Dashboard | Process owner coordinates | A named red-team operator validates every finding |
The bottom row is the one to sit with. An ASM platform gives you a dashboard. CTEM gives you a process. Continuous external red teaming gives you a person — an experienced operator who attacks the same surface an adversary would, and confirms what's real before it reaches your desk.
What changes when you test from the outside?
You find the things that sit between the cracks. Three examples from our work:
In August 2026, Cylent flagged an exposed and exploitable Metabase instance at a client, three days before CVE-2026-72898 (CVSS 10.0) was published. An ASM tool would have found Metabase after the advisory. The exposure existed before the advisory — and so did the attacker. Metabase described the incident in its post-mortem.
At a global B2B payments platform, a senior product leader uploaded four internal codebases to a personal public account to give their AI coding assistant context. Inside that code was a live SQL injection vulnerability (CVSS 8.8). The company's perimeter ended at that personal account, and no inventory system knew it existed. Full write-up on Cylent Labs.
An annotation server for a physical-infrastructure monitoring vendor was open to the internet with open self-registration and no email verification. Every vulnerability that "requires an account" became reachable by anyone. From a single free account: 35 projects, proprietary ML models, and task names that encoded hardware deployment locations. Detailed on Cylent Labs.
In our capability comparison across 11 dimensions — asset inventory, business context, change monitoring, known CVEs, unknown vulnerabilities, exposed secrets, CI/CD and supply chain, threat intelligence, contextual learning, human red team, and signal quality — ASM tools match continuous external red teaming on one row (known CVEs). The rest is either deeper or only available through testing.
This week
- Run
nmapor your EASM tool against your domains and compare the results to your asset inventory. What shows up that isn't in the CMDB? - Pull your CISA KEV exposure list. For each appliance on it: is it directly reachable from the internet?
- Check whether anonymous access is enabled on any Grafana, Kibana, or monitoring dashboard. "Read-only" is not harmless.
- Ask your EASM vendor: does the platform test for exploitability, or only detect known CVEs?
- Search your organization's name on GitHub. Include personal accounts. Look at what's public.
- List every AI tool with access to internal chat or wikis. Ask what it would return for "where are our secrets?"
FAQ
What is the difference between ASM and EASM?
ASM (attack surface management) is the broad category — inventorying and managing all assets. EASM (external attack surface management) focuses specifically on what's visible from outside the network: domains, subdomains, IPs, web interfaces. EASM takes the attacker's perspective on discovery, but stops at discovery.
Does EASM replace penetration testing?
No. EASM discovers what's exposed. Penetration testing proves what's exploitable. They answer different questions and complement each other. EASM without testing gives you a list of assets. Testing without EASM might miss assets entirely.
What is CTEM?
Continuous Threat Exposure Management. A framework Gartner defined with five stages: scoping, discovery, prioritization, validation and mobilization. It's a process model, not a product. The critical stage — validation through actual testing — is where most implementations fall short.
How does continuous external red teaming differ from a pentest?
A pentest is a point-in-time engagement. Continuous external red teaming runs the same adversarial methodology on an ongoing basis, at the speed of AI agents with a human operator validating every path. Findings arrive as they're confirmed, not in a quarterly report.
Can ASM detect zero-day vulnerabilities?
No. ASM tools rely on known vulnerability databases. If there's no CVE, there's no finding. Detecting unknown vulnerabilities requires active testing — fuzzing, business-logic analysis, and creative exploitation — which is what red teaming provides.
The bottom line
ASM, EASM and CTEM are useful. They solve the discovery problem. But discovery is not the problem that gets you breached. What gets you breached is the path from a discovered asset to something that matters — and that path only becomes visible when someone actually walks it.
The attack surface adds 300 new services a month on average. CISA requires federal agencies to discover assets every 7 days and enumerate vulnerabilities every 14. If nobody is testing whether those assets are exploitable, the inventory is a map without roads.
My question: your ASM tool says you have 4,000 exposed assets. How many of them has anyone actually tried to break into?
Sources
- CISA, Binding Operational Directive 23-01 (October 3, 2022)
- Microsoft, What is Microsoft Defender External Attack Surface Management? (Defender EASM overview)
- Unit 42, 2024 Attack Surface Threat Report (August 14, 2024, 265 organizations)
- Gartner, Strategic Roadmap for Continuous Threat Exposure Management (August 26, 2025)
- Metabase, August 2026 Security Vulnerability: What happened? — attacks seen three days before the advisory
- Cylent, KEV analysis (October 30, 2026, CISA KEV catalog + cve.org): 282 additions in 2026, +32%; median 4 days to KEV; 27% same-day; same-day additions mostly appliances
- Cylent, Shadow Code — personal public repo, four codebases, SQLi CVSS 8.8
- Cylent, CVAT self-registration — open annotation server, 35 projects, proprietary models