What is external attack surface management?
Most organisations cannot list everything they expose to the internet. EASM exists because you cannot secure, patch or test an asset you do not know you own.
Updated 8/8/2026 · The Tool Money Lab editorial team · Foundation · 9 min read
← Cybersecurity Learning Centre
- EASM is discovery-first: it finds internet-facing assets from the outside, the way an attacker would, rather than reading your inventory.
- The value is in the assets nobody declared — forgotten subdomains, staging environments, marketing microsites, shadow cloud accounts.
- A vulnerability scanner tests what you point it at. EASM decides what to point it at, then keeps re-deciding as things change.
- Dangling DNS records are the classic EASM finding: a subdomain still resolving to a decommissioned service can often be claimed by someone else.
- EASM produces an inventory and an exposure list. It does not fix anything, and it does not test internal networks.
The inventory problem
Ask a security team to list every internet-facing asset the organisation owns and you will get a confident answer covering the production estate. What the answer typically omits is everything created outside the normal path: a campaign microsite a marketing agency stood up on its own hosting, a staging environment exposed for a client demo three years ago, an S3 bucket serving a legacy download, a subdomain pointed at a SaaS trial that lapsed.
None of that appears in the CMDB because nobody filed a ticket. It does appear in DNS, in certificate transparency logs and in the results of anyone scanning your domain — which is the asymmetry EASM was built to close. Attackers enumerate what exists; defenders enumerate what they remember.
The consequence is not theoretical. Unpatched forgotten hosts are one of the most reliable ways into an otherwise well-run organisation, precisely because nobody is monitoring, patching or testing them.
How EASM discovery works
EASM platforms start from something you certainly know — a company name, a primary domain, an IP range — and expand outward using publicly observable data, then verify what they find.
- DNS enumeration: brute-forcing and inferring subdomains, then resolving them to see what is live.
- Certificate transparency logs: every publicly trusted TLS certificate is logged, so hostnames appear there even when nothing links to them.
- IP and ASN mapping: identifying address ranges associated with the organisation and probing what listens on them.
- Service fingerprinting: identifying the software and version behind each open port or endpoint.
- Technology and third-party detection: spotting SaaS platforms, CDNs and hosting providers that your assets depend on.
- Attribution: deciding which discovered assets are actually yours, which is the step that separates a useful platform from a noisy one.
EASM, vulnerability scanning and pen testing are different jobs
These three appear in the same procurement conversations and answer different questions. Buying one while believing you bought another is a common and expensive mistake.
| Capability | Question it answers | Input | Typical output |
|---|---|---|---|
| EASM | What do we expose to the internet, including things we forgot? | A company name, domains, IP ranges | A continuously updated asset inventory with exposures and ownership signals |
| Vulnerability scanning | Which known weaknesses exist on these specific assets? | A list of targets you supply | Severity-rated findings mapped to known vulnerabilities and misconfigurations |
| Penetration testing | What could an attacker actually achieve here? | A scoped, authorised set of targets | Exploit-verified findings, chained attack paths, business impact |
The findings EASM produces that nothing else does
Some exposure classes are only visible when you look from outside with fresh eyes rather than testing a known list.
Dangling DNS records are the headline example. A CNAME still pointing at a cloud service you no longer use can sometimes be claimed by whoever registers that service name next — which hands a stranger a hostname on your domain, complete with the trust your brand carries. It is a configuration hygiene issue, invisible to a scanner pointed only at production.
The others are less dramatic but more common: expired or misissued certificates, administrative interfaces and dashboards reachable from the open internet, default or debug endpoints left enabled, forgotten development environments running years-old software, and third-party subdomains inherited through an acquisition nobody reconciled.
What EASM will not do
EASM is an identification capability. It does not patch, configure, block or remediate, and its output creates work rather than reducing it — which is why buying it without assigning remediation ownership reliably produces a dashboard nobody acts on.
It is also external by definition. Internal network exposure, endpoint hygiene, identity misconfiguration and insider risk sit outside its scope. And attribution is genuinely hard: expect to spend real time in the first weeks confirming or rejecting assets the platform believes are yours, particularly if you share hosting or infrastructure with partners.
Finally, discovery is not depth. Knowing a staging server exists is the beginning; someone still has to decide whether it should exist, and something still has to test it properly.
When a business actually needs it
The threshold is not company size — it is estate complexity. Two signals matter more than headcount: whether more than one team can create internet-facing infrastructure, and whether anything was inherited through acquisition, agency work or a migration.
A ten-person company with one domain, one host and one deployment path can maintain an accurate inventory in a spreadsheet. A hundred-person company with three business units, two acquisitions, an external marketing agency and multiple cloud accounts almost certainly cannot, and its real attack surface is meaningfully larger than its documented one.
If you are early, do the cheap version first: enumerate your own DNS records and certificate transparency logs, and reconcile the results against what you believe you run. The gap you find is the business case.
FAQ
No. A scanner tests targets you supply. EASM works out what the targets are in the first place and keeps that list current, which is why the two are usually bought together or bundled.
The point of EASM is to test whether that belief is true. Most organisations that run discovery for the first time find assets missing from their inventory, and those are exactly the neglected ones.
Discovery relies largely on publicly available data such as DNS and certificate transparency logs. Active testing beyond that requires authorisation, which is why reputable platforms make you verify ownership before probing an asset.
When a DNS record still points at a third-party service you no longer control, someone else can sometimes register that service name and serve content on your subdomain. It is a common EASM finding and usually a quick fix once identified.
Only what is externally observable, such as a publicly readable storage bucket or an exposed management interface. Auditing cloud permissions and configuration properly is the job of a cloud security posture tool.
Initial results usually arrive within hours to a few days. The slower part is attribution — confirming which discovered assets are genuinely yours — and that is human work regardless of platform.
Someone with authority to decommission things. Most of the value is in removing exposure rather than defending it, and that requires a decision-maker rather than a monitor.
This guide is deliberately vendor-neutral. When you are ready to evaluate products, these are the TTML pages that continue the topic.
Glossary:zero trust
Our reviews are based on vendor documentation, publicly available product information, independent testing where available, and ongoing editorial updates. We do not sell rankings. Where a page carries affiliate links we may earn a commission at no additional cost to you, and that relationship never changes the conclusion — see our affiliate disclosure and review methodology.
- Last reviewed
- Reviewed by
- The Tool Money Lab Editorial Team — independent software research
- Evidence sources
- Vendor Documentation · Public Standards Documentation (NIST CSF Identify function)
Stay Ahead of AI
Receive our weekly Intelligence Brief. Independent AI reviews, comparisons, new tools and practical recommendations delivered every Friday.
- ✓ New AI tools
- ✓ Honest reviews
- ✓ Best AI deals
- ✓ New comparisons
- ✓ Industry trends
- ✓ No spam.