External attack surface management (EASM) is the practice of continuously discovering the internet-facing assets an organization owns, such as domains, hosts, certificates, cloud services and APIs, then assessing and shrinking what an outsider could attack. Its core output is an inventory with owners, not a vulnerability report.
What counts as the attack surface?
NIST's glossary defines an attack surface as the set of points on the boundary of a system, a system element or an environment where an attacker can try to enter, cause an effect on, or extract data from it. Externally, that means anything reachable from the internet without first being inside your network.
In practice the list is longer than the one in your CMDB: forgotten subdomains, test environments, storage buckets, exposed admin panels, old marketing sites, third-party SaaS tenants with your name on them, code repositories, and mail or DNS records pointing at services you no longer run.
Why does a separate discipline exist?
Because the inventory is wrong. Teams launch things through credit cards, acquisitions and quick projects, and ownership leaves with the person. An internal scanner only checks what it has been told about. Outsiders do not need that list.
EASM flips the starting point. You begin with a few known seeds, such as your registered domains and company names, and expand outward using public data: DNS records, certificate transparency logs, IP ranges, and what responds on ports. Then you reconcile what you find against what you thought you had.
The term itself is used by different groups in different ways, and no single standard fixes its scope. Judge any tool or service by what it actually does, not by the label.
A constructed example
A company runs a campaign site at promo.example.com in 2022 and the agency winds the project down. The DNS record is left behind and points to a hosting account that was cancelled. If another party can register that hosting name, they can serve content under the company's domain. This is a subdomain takeover, and nobody was attacked through a vulnerability in code.
Discovery by DNS enumeration finds the dangling record. Review assigns it to marketing. The fix takes ten minutes: remove the record. Without discovery it could sit there for years.
What does a good process include?
Discovery is the first step, but ownership is what closes the gap. Each asset needs a team that can answer "why does this exist?" and "who patches it?" Assets without an owner become candidates for removal.
Next comes risk review. Check what each exposed service reveals, whether it needs to be public, which software and version it runs, whether authentication is required, and whether certificates and DNS are healthy.
Then prioritization. Not every open port matters. Weigh exposure of sensitive data, access to administrative functions and known exploited vulnerabilities.
Finally, change tracking. A weekly diff of new and removed assets is more useful than a quarterly report, because new exposure usually comes from new deployments.
What are the limits?
Discovery by external signals misses assets that show no public footprint, and it can misattribute shared hosting to you. It does not test application logic, and it will not find a flaw in code that you serve behind a login. Treat it as one control alongside code scanning, cloud configuration review and penetration testing.
Scanning also has rules. Only probe assets you own or have permission to test.
How to check or apply this
- List your seeds: registered domains, brand names, IP ranges, cloud accounts and subsidiaries.
- Enumerate DNS records and certificates for each seed, including historical certificates.
- Compare results against your inventory and flag unknown assets.
- Assign an owner to every asset. Unowned and unneeded assets get decommissioned.
- Check each exposed service: is authentication on, is the software supported, does it need to face the internet?
- Clean dangling DNS records and expired service links.
- Feed new findings into the ticketing system and repeat on a schedule.
Quick check
Is EASM the same as a vulnerability scan?
No. A vulnerability scan checks known assets for known flaws. EASM first finds the assets you did not know about, then reviews their exposure.
How often should discovery run?
Often enough to catch new deployments before attackers do. Continuous or weekly runs are common starting points. Choose a cadence that matches how fast your teams ship.
Sources
- NIST Computer Security Resource Center glossary, attack surface
- CISA #StopRansomware Guide, on reducing exposed entry points
Last reviewed: 18 October 2026.
