What is external attack surface management and how do you do it?

External attack surface management, or EASM, is the practice of continually discovering the assets your organization exposes to the internet, then checking and fixing what an attacker could reach. The loop is discover, identify the owner, assess, fix, repeat. It is a discipline first, and a product category second.

What is an attack surface?

NIST's glossary, quoting SP 800-53 Rev. 5, defines it as the set of points on the boundary of a system, component or environment where an attacker can try to enter, cause an effect on, or extract data from it. "External" narrows that to what can be reached from outside your network: domains, IP ranges, web applications, APIs, cloud storage, remote access services, and the third party services that front them.

The hard part is the word "known". A list of assets from last year's project plan is not your attack surface. Marketing sites on a forgotten domain, a test server left running after a demo, and a cloud bucket created by a contractor are all part of it.

Why do asset lists go wrong?

Because assets appear faster than documentation. Teams spin up resources through cloud consoles and code. Acquisitions bring unfamiliar domains. Old systems outlive their owners. Each of these produces an asset that exists, is reachable, and is not on any list.

CISA's Binding Operational Directive 23-01 treats this as foundational for federal agencies. It requires automated asset discovery every 7 days, and vulnerability enumeration across all discovered assets every 14 days, including roaming devices. CISA acknowledges that full vulnerability discovery across a large enterprise may not finish within 14 days, and says the process should still be started at regular intervals. The directive binds federal civilian agencies only, but the cadence is a reasonable reference for anyone.

What does a discovery loop include?

Start from seeds you know: your registered domains, known IP ranges, cloud accounts, and company names. Expand outward by looking at DNS records, certificates issued for your names, and what responds on those addresses. Each find gets classified: yours or not, who owns it, what it does, what data sits behind it.

Then assess. Is it patched? Is it meant to be public? Are admin interfaces or databases reachable? Does it still serve a purpose? Often the best fix is to switch the asset off.

A constructed example

A software firm lists 40 domains in its registry. A discovery pass from certificate and DNS data turns up 63. Of the extra 23, 14 are old campaign pages, five are staging servers, two are a partner portal run by a team nobody had contacted, and two point at a decommissioned cloud load balancer whose name could be claimed by someone else. Each gets an owner or a shutdown ticket. The dangling records are removed on day one.

How to check or apply this

1. Write down your seeds: domains, ranges, cloud accounts, brand names and subsidiaries.
2. Run discovery on a fixed schedule. Weekly is the BOD 23-01 reference point for asset discovery.
3. For every asset, record an owner, a purpose and a data classification. No owner means a shutdown candidate.
4. Check exposure: services that should be internal only, expired certificates, default pages, unpatched software.
5. Feed new assets into your vulnerability process and your change process, so tomorrow's creation is caught.
6. Track measures that show progress: unknown assets found per run, time to assign an owner, time to fix.
7. Close the loop with engineering. Make new cloud resources register themselves, so discovery confirms rather than finds.

Safeguard's asset discovery and dependency scanning can cover the part of this that lives in your code and software inventory. External scanning of domains and IP ranges is a different job, and this article does not claim it for the product.

Quick check

Sources

• NIST Glossary, attack surface
• CISA BOD 23-01, Improving Asset Visibility and Vulnerability Detection on Federal Networks

Last reviewed: 18 October 2026.