Skip to main content
Program & Strategy

What is External Attack Surface Management (EASM)?

Also: EASM · external attack surface management · attack surface management

Definition

External Attack Surface Management (EASM) is the continuous, outside-in discovery, inventory, and risk assessment of an organization's internet-facing assets so security teams can find and fix exposures the same way an attacker would find them. It answers a single, urgent question: what of ours is reachable from the public internet right now, and which of those things are dangerous?

Reviewed by Aakash Harish

Security Research Contributor, Legba

Reviewed 2026-05-28

In depth

EASM is an emerging market category that Gartner introduced in 2021 to describe products that identify risks coming from internet-facing assets and systems an organization may be unaware of. The defining trait is the vantage point: EASM looks at you the way an external attacker does, with no agents, no API keys into your tooling, and no prior knowledge of your inventory. It starts from a seed (a domain, a brand name, a known IP block) and recursively expands outward to map everything connected to you.

A complete EASM workflow has three stages that run on a loop rather than once a quarter. First, discovery: continuously finding public-facing assets as soon as they surface on the internet, including domains, subdomains, IP addresses, TLS certificates, exposed services, and cloud endpoints. Second, inventory and attribution: deduplicating those findings and attributing each asset to your organization so you have a real-time, owned-asset register rather than a pile of unattributed hits. Third, risk assessment: evaluating whether each discovered asset is risky or behaving anomalously, then prioritizing remediation. The UK's NCSC frames the same loop as identifying, monitoring, and reducing vulnerabilities within assets that are accessible from the internet.

The category exists because the modern attack surface is not a curated list anyone maintains by hand. Marketing teams stand up landing pages, engineers spin up cloud buckets and staging environments, acquisitions bring in unknown domains, and contractors register subdomains that point at services nobody tracks. These become shadow IT: assets that are exposed but absent from the CMDB. EASM's job is to surface exactly this unknown-unknown layer, because an attacker only needs one forgotten asset, while a defender has to know about all of them.

It is important to differentiate EASM from two adjacent disciplines it is constantly confused with. CAASM (Cyber Asset Attack Surface Management) sees all assets, internal and external, but does so primarily through API integrations with existing tools such as CMDBs, EDR agents, vulnerability scanners, and cloud platforms; it consolidates data you already have rather than discovering things from the outside. CAASM is therefore only as complete as the tools it ingests from, which means it cannot see shadow IT that no internal tool has recorded. Vulnerability management, by contrast, assumes the asset list is already known and goes deep on enumerating CVEs against those known hosts; it answers 'which vulnerabilities exist on assets we manage,' not 'which internet-facing assets do we even have.' EASM is the discovery and outside-in lens that feeds both: it finds the asset CAASM and vuln scanners did not know to ask about, then hands it off for deeper internal correlation and patching.

EASM also sits inside the larger arc Gartner now describes as Continuous Threat Exposure Management (CTEM), where EASM is the scoping-and-discovery engine and validation tools confirm whether discovered exposures are actually reachable and exploitable. In practice, mature programs do not pick EASM versus CAASM versus vulnerability management. They run EASM for outside-in discovery, CAASM for internal consolidation, and vulnerability management for depth, then unify the output so the same exposed Redis instance or dangling DNS record is seen, attributed, validated, and remediated once.

Why it matters

If you cannot see an internet-facing asset, you cannot patch it, monitor it, or decommission it, and attackers scan the entire IPv4 space in hours looking for exactly that blind spot. The expensive breaches rarely start at the hardened front door you defend every day; they start at the forgotten staging server, the cloud bucket a contractor left public, or the subdomain still pointing at a deprovisioned service. Every one of those is invisible to a CMDB-driven inventory and to a vulnerability scanner pointed only at known hosts, which is precisely why an exposed asset can sit live and unowned for months. NIST defines the attack surface as the set of boundary points where an attacker can try to enter, affect, or extract data from a system, and the brutal arithmetic is that your defenders must cover the whole boundary while an attacker needs one point on it. EASM closes that asymmetry by giving you the attacker's map before the attacker uses it; not having it means accepting that some unknown fraction of your real perimeter is being defended by hope.

How Legba Recon uses it

Legba Recon is built as an EASM-first engine: it works outside-in, starting from your domains and brand and recursively expanding to enumerate subdomains, IPs, certificates, and exposed services without needing agents or credentials into your stack. Recon continuously re-runs discovery so newly stood-up assets are attributed to you the moment they appear on the internet, building a live owned-asset inventory instead of a stale quarterly snapshot. Crucially, Recon does not stop at discovery; it validates each finding to separate noise from real, reachable exposure, so an open management port, a public storage bucket, or a dangling DNS record is confirmed before it ever reaches your queue. The output is an attacker-prioritized report: not a raw asset dump, but a ranked list of the exposures most likely to be exploited, mapped to the specific asset and the fix, so your team spends its hours on the handful of things that actually move risk down.

Explore Legba Recon →

Methodology

Each finding-type guide is built from Legba Recon's real detection and validation logic, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.

FAQs.

References.

Keep exploring

Your agent needs its Legba.

Read the docs