Defender External Attack Surface Management

Microsoft Defender External Attack Surface Management (Defender EASM) discovers everything your organisation has exposed to the public internet — domains, subdomains, IP addresses, web apps, certificates, cloud resources, third-party assets — and surfaces vulnerabilities and misconfigurations across that surface. It's the modern answer to "do we even know what we have on the internet?"

The discovery model

Defender EASM works without an agent. Starting from a few seed inputs — primary domains, known IP ranges, organisation names — it discovers the connected ecosystem by:

• DNS enumeration — sub-domains, hosting providers, MX records, DNS configuration.
• WHOIS — registered domains owned by the organisation, with confidence scoring.
• Certificate transparency — TLS certificates issued for your domains by any CA.
• Web crawling — what's hosted on each discovered host.
• Cloud asset discovery — Azure / AWS / GCP resources tied to the organisation.
• Third-party assets — SaaS subdomains (e.g., acme.zendesk.com) and partner-controlled infrastructure.

The result is an inventory of your external attack surface, often surfacing assets the organisation has lost track of — old marketing sites, abandoned subdomains, forgotten test environments.

Why this matters

Most organisations have significantly more exposed than they realise:

• Marketing campaigns spin up vanity domains and forget them.
• Acquired companies have legacy infrastructure that wasn't fully migrated.
• Developers spin up cloud resources for tests that outlive the test.
• SaaS apps subdomain-attach to your brand.

Each forgotten asset is a vector. EASM surfaces them.

What EASM evaluates

For each discovered asset:

• Open ports and services.
• Software versions and CVEs.
• TLS / SSL configuration weaknesses — weak ciphers, expired certs, mismatched names.
• Web application security — missing security headers, exposed admin interfaces, debug mode left on.
• Misconfigurations — public cloud storage buckets, exposed databases, unauthenticated APIs.
• Reputation signals — assets on malware blocklists, mentioned in threat-intel feeds.

Findings are prioritised by severity and exploit availability, similar to vulnerability management.

Discovery groups and the confirmed inventory

Discovery doesn't run once — it runs as an ongoing discovery group, a saved set of seeds (domains, IP blocks, organisation names) that EASM re-crawls on a schedule. Every asset it finds lands in one of three states:

• Approved inventory — confirmed as belonging to the organisation; this is what shows up in dashboards, reports, and risk scoring.
• Candidate inventory — discovered with reasonable confidence but not yet reviewed; nothing here counts toward your attack-surface score until triaged.
• Requires investigation / Dependency — assets connected to yours (a CDN, a shared SaaS tenant) that aren't yours to remediate but matter for context.

Triaging candidates into approved or "not applicable" is the recurring operational task — new candidates appear as the organisation acquires domains, spins up test environments, or contracts with new SaaS vendors.

Integration with the rest of Defender

EASM signals feed Defender XDR so external attack surface findings correlate with internal incidents — e.g., "the breach in incident 12345 came in through that abandoned subdomain EASM flagged a month ago." EASM data can also be exported to a Log Analytics workspace for organisations already centralising security telemetry in Microsoft Sentinel, so attack-surface changes trigger the same alerting pipeline as everything else.

Who should own it

EASM sits awkwardly between security and IT asset management, and that ambiguity is the most common reason a deployment stalls after the initial discovery run. In practice it works best when:

• Security owns triage and prioritisation — deciding what's critical, what's acceptable risk, what needs immediate takedown.
• IT or the asset owner owns remediation — patching, decommissioning, or reconfiguring the actual asset, which security rarely has direct access to.
• A recurring cadence exists — weekly candidate-inventory triage is enough for most organisations; monthly lets too much drift accumulate, especially in organisations that do frequent marketing campaigns or M&A.

How to use it

A typical EASM workflow:

1. Configure inventory — confirm Microsoft's discovered assets match what's actually yours.
2. Triage findings — start with critical and high-severity exposures.
3. Remediate — patch, take down, configure correctly, or accept (with documentation).
4. Monitor over time — EASM rediscovers continuously; new assets appear as they're created.

For larger organisations, EASM often pays back its licence cost in the first month by surfacing forgotten infrastructure that was a real risk.

Licensing

Defender EASM is licensed by billable asset count (the assets in your confirmed inventory). Pricing tiers depend on organisational size.

For Microsoft 365 customers with public-facing infrastructure, EASM is increasingly part of the security baseline. It's the only Microsoft product that looks at security from outside the network.