A working definition of EASM
EASM platforms continuously discover internet-facing assets associated with your organization, fingerprint the technologies running on them, and surface exposures — open ports, expired certificates, misconfigurations, known CVEs, leaked secrets. The "external" qualifier matters: EASM looks at your infrastructure the way an attacker would, from the outside in, with no credentials and no agent installed.
This is different from vulnerability management, which assumes you already know what assets exist and scans them with credentials. EASM answers the question that has to come first: what do we even own?
How discovery actually works
Modern EASM platforms combine several discovery techniques and stitch the results into a single asset graph:
- Seed expansion from a starting set of domains, IPs, and brand terms
- Passive DNS history (every hostname that ever resolved to your IP space)
- Certificate transparency logs (every SSL certificate ever issued for your domains and lookalikes)
- WHOIS and registration metadata
- Internet-wide scan data (Shodan, Censys, FullHunt indexes)
- Cloud provider account enumeration once credentials are added (for AWS, Azure, GCP attribution)
- Code repositories, paste sites, and JavaScript bundle parsing for embedded hostnames and tokens
Coverage and attribution quality vary wildly by vendor. The cheapest products lean on Shodan and certificate transparency, which is enough to find your obvious public services but misses anything spun up under a non-corporate domain or in a developer's personal cloud account. Better products invest heavily in attribution — the human or ML logic that decides "this asset belongs to you" — because the false-positive cost is the difference between a useful daily review and an ignored noise queue.
EASM vs. CAASM vs. vulnerability management
The three categories overlap and the marketing makes them sound interchangeable. They are not.
- EASM: external view, no agents, focused on discovery and exposure of internet-facing assets
- CAASM (Cyber Asset Attack Surface Management): inventory aggregation across internal sources (EDR, MDM, CMDB, cloud), the "single pane of glass" view
- Vulnerability management: deep, credentialed scanning of known assets, focused on CVE remediation workflow
A mature program uses all three: EASM finds the unknowns, CAASM stitches the knowns into one inventory, and vulnerability management drives the remediation queue. If you can only afford one and you have a sprawling environment with M&A history, start with EASM — you almost certainly cannot remediate what you cannot see. Pair EASM findings with continuous dark web monitoring so newly leaked assets surface quickly.
Evaluating an EASM platform
- Run a 14-day proof of concept with your real domain set. Compare the unknown-asset count against your CMDB
- Sample 30 random assets the platform attributed to you. Confirm ownership manually — anything below 90% precision is unworkable
- Check the freshness of detections (CVE feeds, certificate expirations) — older than 7 days is a red flag
- Verify the platform follows redirects and walks JavaScript-rendered content; modern apps hide a lot of surface in SPAs
- Confirm export and API: you will want to push asset data into your SIEM, ticketing, and CAASM
- Ask about deduplication — multiple hostnames pointing at the same IP should count as one finding, not three
Common deployment pitfalls
The most common reason EASM rollouts stall is the lack of a clear owner for newly discovered assets. The platform finds 400 unknown subdomains; nobody knows whose they are; the report ends up in a shared inbox and is forgotten. Solve this organizationally before the technical rollout: every discovered asset must map to a named owner inside two weeks, or it gets a takedown ticket.