The definition
Your external attack surface is everything about your organization that is reachable or observable from the public internet without credentials: websites, APIs, subdomains, mail servers, DNS records, TLS certificates, cloud endpoints, and any port that accepts a connection. External attack surface management (EASM) is the practice of continuously discovering those assets, assessing how they are configured, and watching them for change.
The word external is doing real work in that sentence. Internal scanners and agents see your infrastructure from the inside, with credentials and network access. EASM deliberately takes the opposite vantage point — the one an attacker, a phishing kit, or an automated botnet scanner has. Whatever they can see, you should see first.
Why "management" and not just "scanning"
A one-off scan answers "what is wrong right now?" That is useful, but infrastructure drifts constantly:
- A developer spins up a preview deployment and it gets a public certificate — visible in certificate transparency logs within minutes.
- A marketing contractor points a subdomain at a SaaS tool, the contract ends, and the CNAME keeps dangling at a service someone else can claim — the classic subdomain takeover setup.
- A certificate that renewed automatically for three years silently stops renewing.
- A firewall change exposes a database port that was never meant to answer the internet.
None of these are "vulnerabilities" in the CVE sense, and none of them existed at the time of your last audit. The value of EASM is change detection: knowing the week a new subdomain appears, the month before a certificate expires, and the day a port opens — not during the incident afterwards.
What an EASM tool actually checks
Concretely, a typical external monitoring pass covers:
- TLS and certificates — chain validity, expiry dates, protocol versions still accepted (TLS 1.0/1.1 should not answer), key strength, and hostname coverage.
- HTTP security headers — HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, cookie flags, and whether plain HTTP quietly serves content instead of redirecting. See our security headers guide.
- DNS and email authentication — SPF, DKIM and DMARC policy strength, CAA records, and unexpected NS or MX changes.
- Subdomain discovery — primarily from certificate transparency logs, which record every publicly issued certificate, including ones for hosts nobody told the security team about.
- Exposed services — which ports accept connections, and what the services reveal about themselves.
- Domain health — registration expiry, lookalike/typosquat registrations, and certificates issued by CAs you do not use.
EASM vs. vulnerability scanning vs. pentesting
| EASM | Vulnerability scanning | Penetration testing | |
|---|---|---|---|
| Question answered | What do we expose, and what changed? | Do known assets have known flaws? | Can a skilled human actually break in? |
| Vantage point | Outside, unauthenticated, passive | Inside or outside, often credentialed | Adversarial, active exploitation |
| Cadence | Continuous | Weekly–monthly | Annually, typically |
| Finds unknown assets? | Yes — that is the point | No — you give it a target list | Sometimes, within scope |
These are complements, not substitutes. A vulnerability scanner cannot scan a staging server it does not know exists; EASM is how it gets on the list. A pentest report is a snapshot; EASM is the thing that tells you when the snapshot went stale.
Who needs EASM?
Historically, EASM was an enterprise category — large estates, dedicated platforms, five-figure contracts. But the underlying problem starts at exactly one domain: the day you have a website, a mail domain and a couple of DNS records, you have an attack surface that can drift. Small teams arguably need continuous monitoring more, because nobody is employed to stare at DNS all day. That is the gap lighter-weight tools (Bastion among them — see our comparison of EASM tools) now fill at small-business prices.
How to start
- Inventory what you think you have. Domains, known subdomains, mail providers, hosting.
- Let discovery correct you. Certificate transparency logs almost always surface hosts the inventory missed.
- Fix the score-movers first. Expired or weak TLS, missing HSTS, a permissive SPF record and an exposed database port outrank most CVE lists for real-world risk.
- Turn on change alerts. The steady state is quiet; you want to hear about deltas, not re-read the same clean report weekly.
Frequently asked questions
What is the difference between EASM and ASM?
They are usually the same thing. "Attack surface management" (ASM) sometimes includes internal assets, while EASM explicitly limits itself to what is visible from the public internet. Vendors use the terms interchangeably more often than not.
Is external attack surface monitoring safe to run against production?
Yes, when the checks are passive — reading HTTP headers, completing a TLS handshake, querying public DNS and certificate transparency logs. That is the same traffic browsers and mail servers generate constantly. Active exploitation and fuzzing belong in scheduled pentests, not continuous monitoring.
How is EASM different from a vulnerability scanner?
A vulnerability scanner probes a list of assets you give it for known software flaws. EASM first builds and maintains that list from the outside — discovering subdomains and services you may not know about — and monitors configuration (TLS, DNS, headers, email authentication) rather than software CVEs. Most teams eventually want both.