Security Azure

Defender EASM: Discovering and Reducing Your Internet-Facing Attack Surface

Jun 8, 2026 16 min read Advanced Vinod

Every estate has assets nobody on the security team knows about. A marketing agency stood up a campaign microsite on a domain you’ve never logged into. An acquisition came with three forgotten subdomains still pointing at an EOL load balancer. A developer pushed a “temporary” demo to a public IP that’s been live for fourteen months. Your CMDB doesn’t have any of these, your vulnerability scanner only scans what you point it at, and attackers find them with the same passive recon you could be running yourself.

Microsoft Defender External Attack Surface Management (Defender EASM) runs that recon for you. It starts from a small set of things you know you own - a domain, an IP block, an ASN - and recursively pivots through DNS, WHOIS, certificate transparency logs, and infrastructure relationships to surface everything connected to them on the open internet. This guide takes you from an empty workspace to an operationalized, recurring discovery pipeline whose findings land in Defender XDR exposure management and Sentinel.

1. The unknown-unknowns problem

Traditional asset management is an inside-out exercise: you enumerate what your tooling already knows about. EASM is outside-in. It models what an attacker sees when they have nothing but your company name, and it answers the question your CMDB structurally cannot: what’s out there that we never registered?

The three recurring sources of unknown internet-facing assets:

EASM is a passive, agentless reconnaissance system. It never touches your network and requires nothing deployed on your assets - it works entirely from internet-observable data, the same way an adversary’s recon does.

2. Deploy the resource and understand the licensing model

Defender EASM is an Azure resource (Microsoft.Easm/workspaces), billed per asset per day, with a 30-day free trial on each new resource. Pick the region deliberately - it determines where metadata about your inventory is stored, which matters for compliance.

Register the provider and create the workspace:

# Register the resource provider (one-time, per subscription)
az provider register --namespace Microsoft.Easm

az group create \
  --name rg-easm-prod \
  --location eastus

# Supported regions include: eastus, westus3, centralus, canadacentral,
# northeurope, westeurope, swedencentral, switzerlandnorth, norwayeast,
# francecentral, australiaeast, eastasia, japaneast, southcentralus
az resource create \
  --resource-group rg-easm-prod \
  --name easm-corp-prod \
  --resource-type Microsoft.Easm/workspaces \
  --location eastus \
  --properties '{}'

Creating the resource in the correct tenant matters more than it looks. The act of provisioning auto-creates the EASM API service principal in that tenant - the identity you’ll later grant access to Log Analytics and Azure Data Explorer for data export. Get the tenant wrong and the connectors won’t authenticate.

You administer the workspace from the Defender EASM blade in the Azure portal. Creating the resource needs Contributor on the resource group.

3. Seed discovery with what you know you own

EASM discovery is recursive. You provide seeds - assets you’re confident you own - and the engine pivots outward from each one. Seeds accept these types:

Seed type Example What it pivots through
Domain contoso.com Subdomains, MX, certs, registrant
Host www.contoso.com Resolved IPs, certs, hosted pages
IP block (CIDR) 203.0.113.0/24 Reverse DNS, hosted services, certs
ASN AS64500 Announced IP ranges
Email contact hostmaster@contoso.com WHOIS registrant linkage
WHOIS organization Contoso Ltd Domains registered to the org

You have two starting paths:

Pre-built footprint (fastest). Use the Get Started flow to search for your organization name. Microsoft maintains pre-built footprints for thousands of organizations - it bootstraps a reasonable inventory in minutes, useful for a first look or a quick assessment of a vendor or acquisition target.

Custom discovery group (what you’ll run in production). Group your seeds into a named discovery group, which is the unit you schedule and re-run. Start narrow and high-confidence - a host, your apex domain, and your known external IP ranges - then expand. The control-plane REST API drives this for automation; capture a bearer token and POST the group:

TOKEN=$(az account get-access-token --resource https://management.azure.com \
  --query accessToken -o tsv)

BASE="https://management.azure.com/subscriptions/$SUB/resourceGroups/rg-easm-prod"
BASE="$BASE/providers/Microsoft.Easm/workspaces/easm-corp-prod"
API="api-version=2023-04-01-preview"

curl -s -X PUT "$BASE/discoGroups/corp-core-seeds?$API" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "description": "Apex domains, owned ASNs, and known prod IP ranges",
      "frequencyMilliseconds": 604800000,
      "seeds": [
        { "kind": "domain", "name": "contoso.com" },
        { "kind": "host",   "name": "www.contoso.com" },
        { "kind": "ipBlock","name": "203.0.113.0/24" },
        { "kind": "as",     "name": "64500" }
      ]
    }
  }'

frequencyMilliseconds: 604800000 is a 7-day cadence. Keep seed groups small and trustworthy - a bad seed (a shared-hosting IP, a CDN range you don’t own) pollutes the recursion and floods your inventory with false positives you’ll spend weeks weeding out.

4. Run discovery, then claim and de-duplicate the inventory

When a discovery run completes, every discovered asset lands in one of five states. This state machine is the heart of EASM and you must understand it before you trust a single dashboard number:

State Meaning Scan cadence
Approved Inventory You own it and are responsible for it. The connection from seed to asset was strong enough to auto-approve, or you promoted it manually. Daily
Candidate Related to your seeds but the connection isn’t strong enough to auto-approve. Needs manual review. Discovery runs only
Requires Investigation Like Candidate, but flagged by a lower internal confidence score; needs a human to determine the relationship. Discovery runs only
Dependency Third-party infrastructure that supports your assets (e.g., a hosting provider’s IP running your site). Per config
Monitor Only Relevant to your surface but not owned or a technical dependency - franchisees, sibling companies. Per config

The critical operational fact: only Approved Inventory assets are scanned daily and appear in dashboards by default. Candidate and Requires-Investigation assets are scanned only during discovery runs. If you leave owned assets sitting in Candidate, they’re invisible to your daily posture view and to every downstream integration. Triage is not optional housekeeping - it’s what makes the data real.

Your claiming workflow after each run:

  1. Filter inventory to Requires Investigation and Candidate.
  2. For each asset, confirm ownership (registrant, cert subject, hosting). If yours, promote to Approved Inventory.
  3. Tag third-party-but-load-bearing infra as Dependency; sibling/franchise assets as Monitor Only.
  4. De-duplicate: the same host can surface via multiple seeds. EASM de-dupes automatically, but verify hosts and IP blocks aren’t double-counted across overlapping CIDR seeds before you report numbers.

Apply labels to slice inventory by business unit, environment, or owning team - this is what makes prioritization and reporting tractable at scale. Labels are first-class and queryable:

curl -s -X PUT "$BASE/labels/acquired-northwind?$API" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "properties": { "displayName": "Northwind acquisition", "color": "purple" } }'

5. Triage exposures: certs, vulnerable services, and risky config

Once assets are Approved and scanned daily, EASM surfaces exposures through its dashboards. The high-value categories, in roughly the order they bite:

Work the Attack Surface Summary and Security Posture dashboards. Pivot on any insight to get the affected asset list, then drill into an individual asset’s detail page for the observed evidence - the cert chain, the banner, the DNS record - that justified the finding. That evidence is what you hand to the owning team; “EASM says so” is not a remediation ticket, but “here’s the expired cert chain on this specific host” is.

6. Prioritize by exploitability and business criticality

A flat list of 4,000 findings is noise. Prioritize on two axes:

Exploitability - is it actually reachable and weaponizable? A high-CVSS CVE on an internet-facing service with a known public exploit outranks a medium-severity header issue on a static brochure page. Externally reachable management interfaces and databases are near-automatic top priority regardless of CVSS - they shouldn’t be exposed at all.

Business criticality - this is where your labels pay off. A cert expiry on the payments domain is a Sev1; the same finding on a defunct campaign microsite is a backlog item. Encode criticality in labels (tier-0, pci-scope, decommission-candidate) so it travels with the asset into every report and integration.

A practical first-pass triage order:

  1. Internet-exposed databases, RDP/SSH, and admin/management panels - close or firewall today.
  2. CVEs with public exploits on tier-0 / revenue assets.
  3. Certs expiring within 30 days on production domains.
  4. Dangling DNS and domains expiring within 60 days (takeover/hijack risk).
  5. Everything else, ranked by exploitability x criticality.

Treat low-value assets as a reduction opportunity, not just a remediation queue. The cheapest way to shrink your attack surface is to decommission what shouldn’t exist - tag decommission-candidate aggressively and let surface-area shrink be a tracked metric, not an afterthought.

7. Integrate with Defender XDR exposure management and Sentinel

EASM is most powerful when its findings stop living in a standalone portal and flow into the tools your SOC already works in. There are two integrations, and you want both.

7a. Defender XDR exposure management (the attack-path play)

Microsoft Security Exposure Management exposes an External Attack Surface Protection initiative. Connecting it pulls EASM data into the exposure graph so that external, internet-facing assets become starting nodes in attack-path analysis - modeling realistic chains that begin outside your perimeter and pivot inward. No agents, scripts, or connectors are required.

To wire it up (needs Global Administrator or Core security settings (manage)):

  1. In the Defender portal, go to Exposure management -> Initiatives, select External Attack Surface Protection, choose Open initiative page, then Connect data source.
  2. Choose Connect your MDEASM workspace and enter the values from your resource’s Essentials pane in Azure:
    • Resource Name
    • Subscription ID
    • Resource Group Name
    • Region
  3. Select Connect. After validation, data flows into the graph and metrics calculate within 32 hours.

There’s also a pre-built footprint option on the same initiative that needs no MDEASM subscription and populates high-level metrics in about an hour - good for a quick read on a vendor or acquisition target, but it gives no asset-level detail. For your own estate, use the full integration. Note: external attack surface assets do not support scoping, so everyone with access sees all collected data - plan RBAC accordingly.

7b. Sentinel and Azure Data Explorer (the hunting/SOAR play)

For automation, incident enrichment, and custom hunting, push EASM data out via a data connection to one of two destinations:

Content options are asset data (granular per-asset metadata), attack surface insights (the dashboard-level findings), or both; frequency is daily, weekly, or monthly. Crucially, only Approved-state assets are exported - which is exactly why Step 4’s triage discipline determines the quality of everything downstream.

Two hard dates and a constraint to design around. New Log Analytics connectors now use the Logs Ingestion API, not the legacy HTTP Data Collector API, which is deprecated September 14, 2026. The Defender EASM resource and the target Log Analytics workspace must be in the same tenant, and data connections do not support private links or networks.

Grant the EASM API service principal access on the Log Analytics side before creating the connection. On the workspace’s resource group, assign Reader, Monitoring Contributor, Log Analytics Contributor, and Monitoring Metrics Publisher to the EASM API app, and register microsoft.insights on the subscription:

RG_LAW="rg-sentinel-prod"
EASM_SP_ID=$(az ad sp list --display-name "EASM API" --query "[0].id" -o tsv)

for ROLE in "Reader" "Monitoring Contributor" "Log Analytics Contributor" \
            "Monitoring Metrics Publisher"; do
  az role assignment create \
    --assignee-object-id "$EASM_SP_ID" \
    --assignee-principal-type ServicePrincipal \
    --role "$ROLE" \
    --resource-group "$RG_LAW"
done

az provider register --namespace microsoft.insights

Then add the connection from Data Connections in the EASM blade. Once data lands, hunt it in Sentinel - here, surfacing externally reachable services that should never face the internet:

EasmAsset_CL
| where AssetType_s == "host"
| where State_s == "Approved Inventory"
| mv-expand Port = parse_json(Ports_s)
| extend PortNumber = toint(Port.port)
| where PortNumber in (3389, 5432, 3306, 1433, 27017, 6379, 9200)
| project TimeGenerated, AssetName_s, PortNumber,
          Labels = Labels_s, FirstSeen_t
| sort by TimeGenerated desc

Column names in the _CL table depend on the schema EASM emits and your ingestion mapping - confirm the actual field names in your workspace after the first ingestion before hardening any detection rule on them.

8. Operationalize recurring discovery and track drift

A one-time scan is a snapshot; an attack surface is a moving target. Operationalize it:

Enterprise scenario

A retail platform team finished acquiring a regional competitor and inherited the security posture sight-unseen: the target’s registrar logins were still in transition, their cloud accounts hadn’t been federated, and the only documentation was a year-old architecture deck. Two weeks post-close, the platform team’s CISO asked the only question that mattered: what does the internet see that we now own and can’t account for?

Their constraint was sharp. They had the acquired company’s primary domain and a partial list of IP ranges, but no access to the registrar, no CMDB, and no agents they could deploy - they didn’t control the assets yet. Any active scanning was off the table both legally (the deal’s reps-and-warranties period hadn’t closed) and practically (they had no credentials). They needed a passive, outside-in view fast, and they needed it to feed the same exposure dashboards the parent company already ran.

They spun up a dedicated EASM discovery group seeded only with the high-confidence assets they had, and labeled everything it found so the acquisition stayed visually and operationally separate from the parent estate:

curl -s -X PUT "$BASE/discoGroups/northwind-acquisition?$API" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "properties": {
      "description": "Northwind M&A - passive recon, pre-close",
      "frequencyMilliseconds": 604800000,
      "seeds": [
        { "kind": "domain",  "name": "northwind-retail.com" },
        { "kind": "ipBlock", "name": "198.51.100.0/24" },
        { "kind": "contact", "name": "admin@northwind-retail.com" }
      ]
    }
  }'

The first run returned 60-odd assets the deck never mentioned: a staging environment exposing a Postgres instance straight to the internet, two domains expiring inside 45 days (a hijack risk during a high-profile acquisition), a wildcard cert covering subdomains nobody could enumerate, and a dangling CNAME pointing at a deprovisioned storage account - a live subdomain-takeover opportunity. The email-contact seed was what cracked it open: WHOIS registrant linkage surfaced three additional domains registered to the same administrator that weren’t in any handover list.

They promoted the confirmed-owned assets to Approved Inventory, tagged the dangling CNAME and the exposed Postgres tier-0, and connected the EASM workspace to their existing Security Exposure Management External Attack Surface Protection initiative. Within 32 hours the acquired surface appeared as starting nodes in the parent company’s attack-path analysis - the exposed database now modeled as a realistic external entry point. The takeover-able subdomain and the internet-facing database were remediated before the reps-and-warranties window closed, which materially changed the integration team’s risk write-up. Total elapsed time from resource creation to first actionable findings: under a day, with zero packets sent at the target’s network.

Verify

Confirm the pipeline end-to-end before you trust it:

# 1. Resource exists and is provisioned
az resource show \
  --resource-group rg-easm-prod \
  --name easm-corp-prod \
  --resource-type Microsoft.Easm/workspaces \
  --query "properties.provisioningState" -o tsv   # expect: Succeeded

# 2. Discovery group is registered with the expected cadence
curl -s "$BASE/discoGroups/corp-core-seeds?$API" \
  -H "Authorization: Bearer $TOKEN" \
  | python3 -c "import sys,json; d=json.load(sys.stdin)['properties']; \
print('seeds:', len(d['seeds']), 'freq(ms):', d.get('frequencyMilliseconds'))"

# 3. EASM API principal exists in the tenant (required for connectors)
az ad sp list --display-name "EASM API" --query "[0].appDisplayName" -o tsv

In the portal, also confirm:

Checklist

Defender-EASMattack-surfaceasset-discoveryshadow-ITexposure-managementexternal-recon
VH

Written by Vinod

Senior Cloud Architect with 22+ years of experience. Sharing practical knowledge from production environments.

Comments

// more articles

Keep Reading

Security Jun 8, 2026

Stopping Token Theft: Conditional Access Token Protection and Authentication Context

Defeat pass-the-cookie and token-replay attacks on Microsoft Entra with device-bound token protection, authentication context tags, and protected actions that gate your highest-value operations.

16 min read Read
Security Jun 8, 2026

Defender for Cloud Attack Path Analysis: Custom Recommendations and Governance Rules

Operationalize the Defender for Cloud security graph to prioritize attack paths, author custom KQL recommendations, and drive remediation with governance rules, owners, and SLAs across Azure, AWS, and GCP.

15 min read Read
Security Jun 8, 2026

Defender XDR Advanced Hunting: Custom Detection Rules and Automatic Attack Disruption

A practitioner guide to writing cross-domain KQL hunts in Defender XDR, promoting them to scheduled custom detections with response actions, and operationalizing automatic attack disruption for ransomware and BEC.

16 min read Read