Fix Microsoft Defender EASM: Setup, Discovery & Permission Errors
Why This Is Happening
I've worked through Microsoft Defender External Attack Surface Management issues on dozens of Azure tenants, and the frustrating part is always the same: the product does something genuinely powerful , it maps your entire internet-facing infrastructure from the outside in, but when it doesn't work the way you expect, the error messages are vague and the Azure portal gives you almost nothing to go on.
Here's the core thing to understand. Defender EASM doesn't scan your internal network. It works entirely from the outside, the same perspective an attacker would have. It starts from what Microsoft calls discovery seeds, known legitimate assets like your primary domain or IP range, and then recursively follows every observable connection outward. New domains, subdomains, hosts, IP address blocks, ASNs, email contacts, Whois organization records: all of it gets pulled into your inventory automatically over time.
That recursive, outside-in model is why most problems happen. If your seeds are wrong, incomplete, or misconfigured, the entire downstream discovery chain breaks. You end up staring at an inventory that's either empty, suspiciously thin, or full of assets that clearly don't belong to your organization. And because the discovery process runs in the background on Microsoft's schedule, you don't get an immediate error, you just wait and wait and eventually realize something went wrong during initial setup.
The second biggest category of issues is permissions. The Defender EASM role model in Azure is straightforward, Owner and Contributor can create, delete, and edit resources and inventory assets; Reader can only view data, but in enterprise environments with complex Azure RBAC configurations, teams routinely get this wrong. Someone gets assigned the Reader role thinking it's sufficient to run a discovery, then spends an hour wondering why the "Create Discovery Group" button is greyed out.
There's also a cross-tenant access limitation that trips up larger organizations hard. Defender EASM does not support cross-tenant resource access at all, and that explicitly includes Azure Lighthouse. If your security team operates out of a managed service tenant and you're expecting to view a customer's Defender EASM resource through Lighthouse, it won't work. You have to authenticate directly to the tenant where the resource lives, full stop.
Finally, I see a lot of confusion around asset states. Defender EASM categorizes discovered assets as Approved Inventory, Dependency, Monitor Only, Candidate, or Requires Investigation. When assets pile up in the Candidate state and nobody reviews them, the inventory becomes stale and the dashboards stop reflecting your real attack surface. That's not a bug, it's a workflow problem. But it looks like a bug when you're in the middle of a security audit.
I know this is frustrating, especially when leadership is asking for an external attack surface report and the tool you provisioned specifically for that purpose isn't giving you clean data. Let's fix it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your Defender EASM inventory is empty or showing far fewer assets than you expect, the most common culprit is a missing or under-specified discovery seed. This single fix resolves the majority of "my inventory is empty" cases.
In the Azure portal, navigate to your Defender EASM resource. In the left-hand menu, find Discovery > Discovery Groups. If you see no discovery groups listed at all, that's your problem, no seeds have been added, so no discovery has ever run.
Click Add Discovery Group. Give it a clear name (something like "Primary Domain Seeds" or your organization name). Now add your seeds. At minimum, add:
- Your primary domain (e.g.,
contoso.com) as a Domain seed - Any known IP address blocks your organization owns, entered in CIDR notation (e.g.,
203.0.113.0/24) - Your organization's ASN if you have one
- Any Whois organization names registered to you
The more specific and accurate your seeds, the better. Using a parent domain like contoso.com will cause Defender EASM to discover all subdomains, hosts, and associated infrastructure automatically, but it needs that starting point. If you only enter one very specific subdomain, you'll only get assets connected to that narrow slice.
After saving your discovery group, discovery runs automatically. Initial discovery on a mid-sized organization typically takes 24–72 hours before you see meaningful inventory population. Don't panic if the inventory looks thin after the first hour, the recursive discovery process takes time to follow all the connection chains outward.
If you already have a discovery group but inventory is still empty after 72+ hours, check your Azure role assignment before doing anything else (covered in Step 2 below). A misconfigured role can silently prevent discovery from completing.
Before anything else works, the Azure resource itself has to exist and be deployed to the right region. This sounds obvious, but I've seen environments where someone created the resource in the wrong region, realized data wasn't showing up correctly, deleted the resource, and hit a nasty surprise: once you delete a Defender EASM resource, it cannot be restored. Microsoft retains your customer data in their data stores for 75 days after deletion, but the actual resource is gone for good. After that 75-day window, the data is permanently deleted.
So get the region right the first time. In the Azure portal, click Create a resource, search for "Microsoft Defender External Attack Surface Management," and select it. On the creation blade:
- Subscription: Pick the correct subscription, the resource must live in the same tenant you'll authenticate from
- Resource Group: Create a dedicated resource group for EASM if you haven't already
- Region: This controls where your customer-specific data is stored. Pick a region that aligns with your data residency requirements, you cannot change this after creation
- Name: Keep it descriptive and unique within the resource group
Once deployed, the resource appears in the Azure portal under your resource group. Navigate to it and confirm the Overview blade loads without errors. If you see a "Resource not found" error or a permissions warning at this stage, stop and resolve your RBAC assignment before proceeding, you won't be able to configure anything.
If deployment itself fails, check that the Defender EASM resource provider (Microsoft.Easm) is registered in your subscription. Go to Subscriptions > [your sub] > Resource Providers, search for "Easm," and confirm it shows as Registered. If it shows Unregistered, click Register and wait about two minutes for it to complete.
Permission problems in Defender EASM are subtle because the portal doesn't always throw a clean error, sometimes it just silently hides functionality or shows blank data. Here's how to confirm your role is configured correctly and fix it if not.
In the Azure portal, navigate to your Defender EASM resource. Click Access control (IAM) in the left menu. Click View my access to see what role you're currently assigned.
The role breakdown works like this:
- Owner: Full control, create, edit, delete resources and inventory assets, manage role assignments
- Contributor: Create, edit, and delete resources and inventory assets, but cannot manage role assignments
- Reader: View Defender EASM data only, cannot create, delete, or edit anything
If you need to run discoveries, manage inventory assets, or configure data connections, you need at minimum the Contributor role. Reader is genuinely read-only, no exceptions.
To assign the correct role, click Add > Add role assignment on the IAM blade. Select the appropriate role, click Next, then search for and select the user, group, or service principal that needs access. Confirm and save.
One thing that catches enterprise teams off guard: Defender EASM does not support cross-tenant resource access, and this explicitly includes Azure Lighthouse. If your managed security provider is trying to access your EASM resource from their own tenant through Lighthouse, it won't work, period. The user must authenticate directly to the tenant where the Defender EASM resource is located. There's no workaround for this in the current product. Your MSSP needs either a guest account in your tenant or a dedicated user in your tenant with appropriate role assignment.
Once the correct role is assigned, sign out of the portal completely and sign back in to refresh your Azure RBAC token. Some portal sessions cache permissions and won't reflect new role assignments until you re-authenticate.
Discovery in Defender EASM isn't a one-time scan, it's a continuous, recursive process. Microsoft's proprietary discovery technology starts from your seeds and follows every observed infrastructure connection outward: it finds a domain, looks at that domain's hosts, checks what IP blocks those hosts live in, examines the ASNs those blocks belong to, reads the Whois registrations, and keeps going. The depth of what it finds is directly proportional to the quality of your seeds.
To manage your discovery groups, go to your Defender EASM resource and click Discovery > Discovery Groups in the left navigation. Each discovery group is a named collection of seeds that gets processed as a unit.
Best practice is to organize seeds by logical grouping: one group for your primary corporate domains, another for acquired subsidiary domains, another for your IP address blocks. This keeps things manageable and makes it easier to audit what's being discovered from which seed set.
The asset types you can add as seeds are:
- Domains, e.g.,
contoso.com - IP Address Blocks, in CIDR notation, e.g.,
198.51.100.0/22 - Hosts, specific hostnames
- Email contacts, organizational email addresses
- ASNs, autonomous system numbers
- Whois organizations, exact organization name strings from Whois records
After adding or editing seeds, Defender EASM queues a new discovery run. You can monitor discovery status within the Discovery Groups blade. If a discovery group shows an error state, check whether the seed values are valid and correctly formatted, an invalid CIDR notation entry or a typo in a domain name can cause the entire group's discovery to fail silently.
You'll know discovery is working correctly when you start seeing new assets appearing in the Inventory section, typically within a few hours for well-seeded organizations, and within 48–72 hours for a full initial discovery pass.
This is the step most people skip, and it's why their Defender EASM dashboards never look quite right. Asset states in Defender EASM aren't automatic labels that the system gets right on its own, they require human review, especially for the Candidate state.
Here's how the states work and what you need to do with each one:
Approved Inventory, Assets you've confirmed are directly owned and operated by your organization. These are the ones you're fully responsible for. If an asset is in this state, it will show up in all your risk and vulnerability dashboards.
Dependency, Infrastructure owned by a third party that directly supports your assets. A classic example: your web application runs on a hosting provider's IP range. That IP address would be a Dependency. You don't own it, but if it goes down or gets compromised, you're affected.
Monitor Only, Assets related to your organization but not directly controlled or technically dependent. Franchisee websites, sister companies, or assets from an acquired company you haven't fully integrated yet often land here.
Candidate, This is where problems hide. Candidate assets have some observed connection to your known seeds, but not a strong enough one for Defender EASM to automatically classify them as Approved Inventory. You have to manually review these and either approve them or dismiss them.
To review Candidate assets: navigate to Inventory and use the filter panel to filter by State = Candidate. Work through the list. For each one, decide: is this actually your asset? If yes, change the state to Approved Inventory. If no, dismiss it or set it to Monitor Only. This isn't a one-time task, new Candidates appear regularly as discovery finds new connections.
If your Candidate queue is overwhelming, filter further by asset type (Domains first, then Hosts, then IPs) and work through the highest-confidence ones. The inventory filters in Defender EASM are powerful, use them.
If your Defender EASM dashboards are showing blank panels, zeroed-out metrics, or stale data that hasn't updated in days, there are three things to check in order.
First, confirm you have Approved Inventory assets. The vulnerability, compliance, and security hygiene dashboards only show insights based on assets classified as Approved Inventory. If everything is sitting in Candidate state, the dashboards will look empty even though discovery worked fine. Go back to Step 4 and classify your assets first.
Second, check your data connections. Defender EASM can push data to other Microsoft security products, Microsoft Sentinel, Microsoft Defender for Cloud, and others. If you've configured a data connection and the destination isn't receiving data, navigate to Data Connections in your EASM resource and check the connection status. A failed or disconnected data connection doesn't break EASM itself but does break any downstream reporting you're relying on.
To set up or repair a data connection, click Add Data Connection, select your target workspace (Log Analytics workspace for Sentinel integration, for example), authenticate with an account that has Contributor access to both the EASM resource and the target workspace, and save. Test the connection immediately after creating it.
Third, check for Azure region outages. Defender EASM is region-specific. If the Azure region where your resource is deployed experiences an outage, only your EASM resource is affected, services in other regions continue running. To check: visit the Azure Service Health blade in the portal (Monitor > Service Health) and filter by your resource's region. If there's an active incident, wait for Microsoft to resolve it. There's nothing to fix on your end.
Once all three checks pass and your Approved Inventory is populated, the dashboards should display insights across vulnerabilities, compliance posture, and security hygiene within a few hours of the next discovery cycle completing.
Advanced Troubleshooting for Defender EASM
If the steps above didn't resolve your issue, here's where things get more technical. These scenarios come up most often in enterprise environments with complex Azure configurations.
Service Principal and Automation Access
If you're accessing Defender EASM programmatically, through the REST API or automated scripts, your service principal needs an Owner or Contributor role assignment on the EASM resource, exactly the same as a human user. Reader-assigned service principals can only pull read-only data. Make sure your automation account's client ID is assigned the right role in the resource's IAM blade.
Use the following Azure CLI command to verify what role a specific service principal has on your EASM resource:
az role assignment list \
--assignee <service-principal-object-id> \
--scope /subscriptions/<sub-id>/resourceGroups/<rg-name>/providers/Microsoft.Easm/workspaces/<easm-resource-name> \
--output tableIf the output is empty, the service principal has no direct role assignment on the resource and is likely inheriting nothing useful. Assign the role explicitly at the resource scope, not just at the subscription or resource group level, to keep permissions tight.
Investigating Missing Asset Types
If discovery is running but specific asset types (say, IP address blocks or ASNs) aren't appearing in your inventory, check whether your seeds actually have observable connections to those asset types. Defender EASM discovers IP blocks and ASNs by inference, it finds hosts in your domain's DNS records, resolves those to IPs, then looks up the CIDR blocks and ASNs those IPs belong to. If your domain's DNS isn't publicly resolving (internal-only DNS, for example), those downstream discoveries won't happen.
Remember: Defender EASM only discovers externally facing assets exposed to the open internet. It's specifically designed for assets outside traditional firewall protection. Internal infrastructure that isn't externally routable simply won't appear, and that's by design, not a bug.
Verifying Data Residency Configuration
Your customer-specific data, the labels you apply to assets, your inventory classifications, your custom data, is stored in the Azure region you selected at resource creation. The underlying internet data that Defender EASM uses for discovery is global data originating with Microsoft and doesn't change based on your region selection. If you have data residency requirements and you're unsure which region your resource is deployed in, check the resource's Overview blade, the region is listed there. You cannot migrate a Defender EASM resource between regions.
Handling the 180-Day Data Deletion Policy
If your organization has recently offboarded from Microsoft or is in the process of restructuring Azure subscriptions, be aware: Microsoft's compliance framework requires all customer data to be deleted within 180 days of your organization no longer being a customer. This includes data in offline locations like database backups. After you delete a Defender EASM resource, your data is retained in Microsoft's data stores for 75 days, but the resource itself cannot be restored at all during that window. After 75 days, permanent deletion occurs.
This matters for incident response planning. If you delete the resource accidentally during a cleanup script or a subscription reorganization, you cannot get it back. Export any inventory data you need to retain before deleting the resource.
Escalate to Microsoft Support if: discovery has been running for more than 7 days with zero assets in inventory despite valid seeds; your resource shows provisioning errors in the Azure portal that don't resolve after 24 hours; you're seeing unexpected data from another organization appearing in your inventory (a data isolation issue that Microsoft needs to investigate immediately); or your data connection to Sentinel or Defender for Cloud is failing despite correct permissions and workspace configuration. For billing or licensing questions about Defender EASM, open a billing support ticket rather than a technical one, they route differently and resolve faster.
Prevention & Best Practices for Microsoft Defender EASM
Getting Defender EASM working correctly is one thing. Keeping it accurate and useful over time as your infrastructure evolves is a different challenge entirely. Here's what separates organizations that get ongoing value from the product versus those that set it up, ignore it for six months, and suddenly realize their attack surface inventory is completely out of date.
Maintain a living seed inventory. Every time your organization acquires a company, registers a new domain, gets assigned a new IP block, or spins up infrastructure under a different legal entity, those new assets need to be added as seeds. Defender EASM's recursive discovery is powerful but it can only discover assets connected to what it already knows. New, unconnected acquisitions are invisible until you add a seed.
Review the Candidate queue on a regular schedule. Set a recurring calendar item, monthly at minimum, weekly if your infrastructure changes frequently, to review assets in the Candidate state. Assets sitting unreviewed in Candidate don't appear in your vulnerability dashboards, which means you could have externally exposed infrastructure with serious security issues that your EASM dashboards aren't flagging because nobody classified the asset.
Audit your role assignments quarterly. People change roles, leave organizations, and join managed service providers. A quarterly IAM audit on your Defender EASM resource costs 15 minutes and prevents the scenario where a departed employee still has Contributor access or where your current security team is unknowingly working with Reader-level permissions and wondering why they can't edit anything.
Don't rely on Defender EASM as your only external visibility tool. It's excellent at discovering infrastructure you didn't know you had. But cross-reference its findings with your CMDB, DNS records, and certificate transparency logs periodically. Discrepancies are worth investigating, they often reveal shadow IT or misconfigured infrastructure that poses real risk.
- Add Whois organization names as seeds, not just domains, legacy acquisitions often have separate Whois registrations that won't be discovered from domain seeds alone
- Assign roles at the resource scope, not subscription scope, to keep your RBAC blast radius small
- Export your approved inventory to CSV monthly and store it in version control, gives you a historical record of attack surface changes over time
- Enable data connections to Microsoft Sentinel immediately after setup so attack surface changes flow into your SIEM automatically without manual exports
Frequently Asked Questions
What is Microsoft Defender External Attack Surface Management and what does it actually do?
Defender EASM is an Azure security product that continuously discovers and maps your organization's internet-facing infrastructure, domains, IP blocks, hosts, email contacts, ASNs, and Whois organizations, by crawling from known starting points called discovery seeds. Think of it as an attacker's-eye view of your organization: it finds assets you might not even know you own. The inventory it builds feeds into dashboards that highlight vulnerabilities, compliance gaps, and security hygiene issues across your external attack surface, giving your security team something to actually act on rather than just a list of IPs.
How do I deploy the Defender EASM Azure resource and get started?
In the Azure portal, search for "Microsoft Defender External Attack Surface Management" in the Marketplace and create a new resource. You'll need to select your subscription, resource group, region (which determines where your customer data is stored), and give the resource a name. Once deployed, navigate to the resource, go to Discovery > Discovery Groups, and add your organization's primary domains, IP address blocks, and ASNs as seeds. Discovery runs automatically after that, expect 24–72 hours before your inventory starts populating meaningfully. The official quickstart in Microsoft's documentation walks through the creation steps in detail if you need a visual reference.
Why is my Defender EASM inventory empty after setting it up?
The two most common reasons are: no discovery seeds have been added (check Discovery > Discovery Groups in the portal and confirm at least one group exists with valid seeds), or discovery simply hasn't finished yet, initial discovery on a reasonably sized organization takes 24–72 hours. If it's been over 72 hours with seeds correctly configured and your role assignment is Owner or Contributor, check the Azure Service Health blade for any active incidents in your resource's region. A regional outage will pause discovery until Microsoft resolves it.
What's the difference between Approved Inventory, Candidate, and Dependency in the asset states?
Approved Inventory is for assets your organization directly owns and is responsible for, these drive your dashboards and vulnerability reports. Candidate assets are ones Defender EASM discovered that have some relationship to your seeds but aren't strong enough to auto-classify; you need to manually review and either approve or dismiss them. Dependency is for infrastructure owned by a third party (like a hosting provider or CDN) that your assets rely on, you don't own it, but disruption or compromise there affects you. Keeping up with your Candidate queue is the single most important operational habit for getting accurate results from EASM over time.
Can I access Defender EASM through Azure Lighthouse or across tenants?
No, and this is a hard limitation, not a configuration issue. Defender EASM does not support cross-tenant resource access of any kind, including via Azure Lighthouse. Every user who needs to access a Defender EASM resource must authenticate directly to the tenant where that resource is located. For managed security providers, this means your team needs guest accounts or dedicated user accounts in the customer's tenant with appropriate Owner or Contributor role assignments on the specific EASM resource.
What happens to my data if I delete my Defender EASM resource or stop being a Microsoft customer?
Deleting a Defender EASM resource is permanent, it cannot be restored by Microsoft's teams after deletion. Your customer data remains in Microsoft's data stores for 75 days post-deletion, after which it's permanently deleted. If your organization stops being a Microsoft customer entirely, the compliance framework requires all customer data to be deleted within 180 days, including offline locations like database backups. The practical takeaway: export any inventory data you need before deleting the resource, because there's no recovery path once it's gone.