What is external attack surface management (EASM)? EASM vs vulnerability scanning.
External attack surface management continuously discovers every internet-facing asset you own and tests it. How EASM differs from vulnerability scanning and pentesting, and how to start this week.
External attack surface management (EASM) is the practice of continuously discovering, inventorying, and testing every asset an organisation exposes to the internet, from the attacker's point of view. The attack surface includes domains and subdomains, IP addresses, web applications, APIs, cloud storage, certificates, third-party services, and, increasingly, AI endpoints. The defining property of EASM is that it starts with discovery rather than with a list you provide, because the assets that cause incidents are usually the ones nobody remembered to list.
The term was popularised by industry analysts around 2021, but the problem is older: every organisation that has shipped software for more than a year has hosts it forgot. This post explains what EASM covers, how it differs from vulnerability scanning and penetration testing, and how to get a working programme running without buying an enterprise platform.
What counts as your external attack surface?
- Domains and subdomains, including those registered by marketing, acquired companies, and individual engineers for a demo.
- Web applications and APIs on every one of those hosts, including staging, preview, and internal tools that drifted public.
- Cloud resources that answer on the internet: storage buckets, serverless endpoints, managed databases with public access, container registries.
- Certificates and DNS records, which both reveal assets (certificate transparency) and create risk (dangling CNAMEs).
- Third-party services that carry your brand or data: SaaS subdomains, CDN configurations, payment and support widgets.
- Code and artefacts reachable from the surface: JavaScript bundles, source maps, public repositories, package registries.
- AI endpoints: chat routes, model-serving APIs, agent tool interfaces, and the retrieval services behind them.
If you can reach it from an internet connection with no credentials, it is on the surface, whether or not it appears in your asset inventory. For a field guide to the ones most often missed, see Five surfaces every AI product team forgets to scan.
How does EASM work?
- Seed. Start from what you know: primary domains, company names, known IP ranges, cloud accounts.
- Discover. Expand the seed through passive sources (certificate transparency, DNS, search engines, code hosting) and active enumeration (subdomain brute force, port scanning, route inference from JavaScript).
- Fingerprint. Identify what each asset is: technology stack, framework version, hosting provider, exposed services, whether it is an AI endpoint.
- Test. Run safe, read-only checks against each asset for the exposure classes that matter: configuration files, debug endpoints, missing headers, open storage, leaked secrets, known CVEs, LLM risks.
- Prioritise. Rank by likelihood and impact on this target, chaining findings into attack paths rather than counting them.
- Monitor. Repeat on a schedule and report the diff: what appeared, what changed, what was fixed.
Step six is what separates a programme from a project. The surface moves with every deployment, and the value of EASM is in seeing the change the day it happens, not in a report that was accurate last quarter.
EASM vs vulnerability scanning vs penetration testing
| Vulnerability scanning | Penetration testing | External attack surface management | |
|---|---|---|---|
| Starting point | A list of assets you provide | An agreed scope | Discovery from the attacker's view |
| Coverage | Known hosts only | Scoped hosts, deeply | Every reachable asset, including unknown ones |
| Frequency | On demand or periodic | Annual or per release | Continuous, with diffs |
| Depth | Signature and version based | Human-driven, finds logic flaws | Behavioural and signature checks, verified |
| Output | Finding list | Report with exploitation narrative | Living inventory plus prioritised findings and changes |
| Best for | Patch management on known infrastructure | Deep assurance on critical systems | Finding what you forgot, catching drift |
The three are complementary. Vulnerability scanning keeps known infrastructure patched. Penetration testing goes deep on what matters most. EASM makes sure the other two are looking at the whole picture, and it catches the staging server that appeared on a Tuesday afternoon between annual pentests. The category of tool that does the EASM job for modern stacks is described in What is an AI security scanner?.
Why does attack surface drift happen?
Nobody plans to expose a staging database. Drift is the sum of ordinary decisions: a preview deployment per pull request that never gets torn down, a marketing microsite on a new domain, a cloud bucket created for a one-off export, a DNS record left behind after a vendor was dropped, an acquired company's infrastructure nobody inventoried, an internal dashboard whose ingress rule was loosened for a demo. Each is reasonable in isolation. Collectively they make the asset inventory wrong within weeks of being written.
The AI wave accelerated this. Model endpoints, notebooks, evaluation dashboards, and demo apps are stood up by people whose job is to ship quickly, on tooling that defaults to public, often outside the platform team's view.
What should an EASM programme produce?
- A living inventory of every external asset, with owner, purpose, and last-seen date.
- A prioritised finding list where the top item is the most likely cause of an incident, with evidence you can replay.
- A change feed: new hosts, new endpoints, new findings, closed findings, per scan.
- Alerts when something high-impact appears, routed to the people who can fix it.
- Evidence for audits: dated reports showing coverage and remediation over time, mapped to controls where relevant. See the minimum scan before an audit.
How do you start EASM in a week?
- Day 1. List every domain the company owns, including ones registered by marketing, legal, and acquisitions. Check the registrar accounts, not just memory.
- Day 2. Enumerate subdomains for each via certificate transparency and DNS. Resolve them and note which answer.
- Day 3. Fingerprint each live host and run the ten-minute external checklist on each.
- Day 4. Identify AI endpoints and run injection and leakage probes against them, or hand that to a scanner built for it.
- Day 5. Prioritise: anything unauthenticated with data behind it first, then leaked secrets, then stale hosts, then headers.
- Day 6. Assign owners. Every asset without an owner is a finding in itself.
- Day 7. Schedule the whole thing to repeat, and route the diff to a channel someone reads.
Frequently asked questions
What is the difference between attack surface management and vulnerability management?
Vulnerability management finds and fixes weaknesses in assets you already track. Attack surface management starts earlier, by discovering which assets exist and are reachable from the internet, then feeds them into testing. Most serious external exposures are on assets that were not in the inventory.
What is the difference between EASM and ASM?
Attack surface management (ASM) covers internal and external assets, including endpoints, identities, and cloud configuration. External ASM (EASM) is the subset visible from the public internet, assessed from an attacker's point of view with no credentials.
How often should the external attack surface be scanned?
Daily for production domains, and immediately after deployments. The surface changes with every release; weekly or monthly scans leave exposures live for most of their lifetime.
Do I need an enterprise platform to do EASM?
No. Small teams can start with certificate transparency lookups, DNS enumeration, and a scheduled external scanner. The essential properties are discovery you did not seed by hand, verified findings, and a repeating schedule with diffs.