Microsoft Defender for Identity vs Defender for Endpoint: What They Actually Cover

The Alert That Needed Two Products to Understand

Three days after the initial compromise, the incident response team had two separate alert streams that no analyst had fully correlated: Microsoft Defender for Identity showed unusual Kerberos ticket requests from a service account, and Defender for Endpoint showed a lateral movement process tree on a workstation that had received a connection from that same account. The SIEM had both signals. Nobody had written the correlation rule. The SOC was working from each product's console separately.

This is not a process failure. It is an architecture failure. The two products are designed to be complementary, but the marketing framing creates a mental model where teams assume each product handles its domain completely. They do not. Defender for Identity does not see what happens on the endpoint after authentication. Defender for Endpoint does not understand the Kerberos, NTLM, and LDAP patterns that precede endpoint compromise. The overlap is narrow and specific. The gaps are where attacks live.

This guide maps exactly what each product monitors, where they share coverage, and where neither product has signal without explicit configuration.

What Microsoft Defender for Identity Actually Monitors

MDI is a sensor-based product. Sensors are deployed on domain controllers, Active Directory Federation Services (ADFS) servers, and Active Directory Certificate Services (ADCS) servers. Those sensors capture network traffic on the DC network interface and read events from the Windows Security Event Log. MDI does not require an agent on every endpoint. It captures authentication events centrally at the DC level.

What MDI sensors capture:

• Every Kerberos authentication event: AS-REQ, TGT issuance, TGS requests, and ticket validation failures
• Every NTLM authentication attempt, including Net-NTLMv1 and v2 hashes in transit
• LDAP queries: every query against the directory, including queries that enumerate users, groups, SPNs, and GPOs
• SAM-R calls (Remote SAM), used by tools like BloodHound for user and group enumeration
• ETW (Event Tracing for Windows) events from the DC for specific attack patterns
• DNS query patterns from domain controllers

Attack patterns MDI detects:

What MDI does not see:

• What happens on endpoints after successful authentication: processes spawned, files created, network connections made
• Local authentication that does not touch the DC (cached credentials, interactive logon)
• LSASS memory access at the process level
• File system activity on member servers or workstations
• Persistence mechanisms on endpoints: scheduled tasks, registry run keys, services
• Process execution trees on any host other than DCs running the sensor

MDI is a network authentication and directory monitoring product. Its entire sensor model assumes authentication flows through the DC. Anything post-authentication that happens locally on an endpoint is outside MDI's field of view.

What Microsoft Defender for Endpoint Actually Monitors

MDE is an agent-based product. A sensor deployed on every managed endpoint captures process-level telemetry, file system events, network connections, registry changes, and memory access patterns. Unlike MDI which operates centrally, MDE's telemetry is per-device. MDE sees what happens on the machine, not what happens in the directory.

If you are evaluating MDE against a third-party EDR platform rather than assuming Microsoft 365 licensing already settles the question, our [CrowdStrike vs Microsoft Defender for Endpoint comparison](/blog/crowdstrike-vs-microsoft-defender-for-endpoint-edr-comparison) covers detection depth, response tooling, and pricing differences.

What the MDE sensor captures:

• Full process tree: every process creation with parent/child relationships, command lines, and file hashes
• File write, rename, and delete events including shadow copy deletion attempts
• Network connections: outbound and inbound with PID-to-socket mappings
• Registry read and write events for security-relevant keys
• LSASS memory access at the process level (credential dumping detection)
• PowerShell and WMI event logs with decoded script content via AMSI integration
• Kernel-level behavioral signals: driver loads, token manipulation, privilege escalation
• Vulnerability inventory per device via Defender Vulnerability Management (Plan 2)

Attack patterns MDE detects:

What MDE does not see:

• Kerberos ticket characteristics: MDE sees a network connection succeeded, not the ticket's encryption type, lifetime, or PAC validity
• LDAP query patterns from the directory layer
• Golden Ticket use at the protocol level: MDE sees a successful network logon, not that the TGT had an anomalous 10-year lifetime
• Directory object changes: user account modifications, GPO changes, trust relationships
• Authentication events on DCs that do not produce endpoint-level activity
• Whether NTLM auth used a hash or a plaintext password

MDE is an endpoint behavioral monitoring product. It tells you what processes ran, what files changed, and what network connections were made. It does not understand the authentication protocol layer.

The Overlap Zone: Where Both Products Have Signal

A narrow but critical set of attack scenarios produces telemetry visible to both products. Correlation here adds the most investigative value:

Lateral movement via SMB/WinRM: MDI sees the Kerberos or NTLM authentication to the destination host. MDE sees the process spawned on the destination host (for example, cmd.exe or powershell.exe as a child of services.exe after a PsExec-style execution). Neither alert alone is conclusive. Combined: authentication from host A followed by remote process execution on host B from the same account within the same time window is high-confidence lateral movement.

Pass-the-Hash: MDI detects NTLM authentication from an unexpected source host for a given account. MDE detects LSASS credential dumping (the step that obtained the hash) on the source host. The attack chain is: LSASS access on host A (MDE) then NTLM auth from host A using the dumped account (MDI) then remote activity on host B (MDE). With only MDI: you know PTH was attempted but not which tool obtained the hash. With only MDE: you know LSASS was accessed but not whether credentials were successfully used anywhere.

Kerberoasting through to service account use: MDI detects the TGS request for the SPN (the kerberoasting step) and any subsequent authentication as the cracked service account. MDE detects what the attacker does with the service account credentials on endpoints. With pure MDI: you see the authentication abuse. With pure MDE: you see unusual service account activity on endpoints with no indication of how the credentials were obtained.

Licensing: What You Actually Need

The most common gap is assuming broader coverage than the purchased license tier provides:

The practical issue: Microsoft 365 E3 gives you MDE Plan 1, which has endpoint protection but limited EDR depth. Teams on E3 who believe they have "Defender for Endpoint" have a product that will not detect many of the attack patterns in the MDE table above. Verify your license tier:

# Check MDE license tier: Defender XDR > Settings > Endpoints > License
# Or query the MDE API using splatting to avoid line-continuation characters
$apiParams = @{
    Uri     = "https://api.securitycenter.microsoft.com/api/licenses"
    Headers = @{ Authorization = "Bearer $token" }
    Method  = "GET"
}
(Invoke-RestMethod @apiParams).value |
    Select-Object licenseType, count, expirationDate

MDI licensing also requires sensor deployment. A license without sensors is zero coverage. Verify sensor deployment coverage across all DCs:

# List all DCs and cross-reference against MDI sensor list
# Run from a management host with RSAT and MDI portal access
$AllDCs = Get-ADDomainController -Filter * |
    Select-Object Name, IPv4Address, Site

# Compare against MDI sensor status visible in MDI portal:
# portal.atp.azure.com > Configuration > Sensors
# Any DC showing "Stopped" or absent from the sensor list is a blind spot
$AllDCs | Format-Table Name, IPv4Address, Site

In the MDI portal under Configuration > Sensors, any DC showing "Stopped" or not listed at all is a monitoring blind spot. An attacker who routes authentication through an unmonitored DC bypasses all MDI detection.

Defender XDR Correlation: Getting Both Products Working Together

In Defender XDR (security.microsoft.com), MDI and MDE alerts are correlated into unified incidents automatically for patterns Microsoft has pre-mapped. For custom correlation across the two products, you need Advanced Hunting KQL. If your team is deciding how Sentinel and Defender XDR should divide responsibilities for this kind of correlation, see our [Microsoft Sentinel vs Defender XDR breakdown](/blog/microsoft-sentinel-vs-defender-xdr-2026).

For more KQL patterns built around MITRE ATT&CK techniques beyond the two queries below, see our [Microsoft Sentinel KQL threat hunting guide](/blog/threat-hunting-microsoft-sentinel-kql-guide-2026).

KQL: Cross-Product Lateral Movement Correlation

// Correlates MDI Pass-the-Hash alerts with MDE LSASS access events
// Run in Defender XDR Advanced Hunting
let PthAlerts = AlertInfo
    | where ServiceSource == "Microsoft Defender for Identity"
    | where Title has "Pass-the-Hash"
    | project AlertTime = TimeGenerated, AlertId, ComputerDns;

let LsassAccess = DeviceEvents
    | where ActionType == "OpenProcessApiCall"
    | where FileName == "lsass.exe"
    | where TimeGenerated > ago(24h)
    | project LsassTime = TimeGenerated, DeviceName,
        InitiatingProcessFileName, InitiatingProcessCommandLine,
        AccountName;

PthAlerts
| join kind=inner (LsassAccess) on $left.ComputerDns == $right.DeviceName
| where AlertTime between ((LsassTime - 1h) .. (LsassTime + 2h))
| project AlertTime, LsassTime, AccountName,
    SourceDevice = DeviceName,
    DestinationDevice = ComputerDns,
    CredentialDumpProcess = InitiatingProcessFileName,
    CredentialDumpCommand = InitiatingProcessCommandLine
| order by AlertTime desc

KQL: Kerberoasting Followed by Service Account Endpoint Activity

let KerberoastAlerts = AlertInfo
    | where ServiceSource == "Microsoft Defender for Identity"
    | where Title has "Kerberoasting"
    | extend Entities = parse_json(Entities)
    | mv-expand Entities
    | where Entities.Type == "account"
    | extend TargetAccount = tostring(Entities.Name)
    | project AlertTime = TimeGenerated, TargetAccount, ComputerDns;

let ServiceAccountLogons = DeviceLogonEvents
    | where LogonType in ("Network", "RemoteInteractive")
    | where AccountName startswith "svc"
        or AccountName startswith "service"
        or AccountName endswith "_svc"
    | project LogonTime = TimeGenerated, DeviceName,
        AccountName, LogonType, RemoteDeviceName;

KerberoastAlerts
| join kind=inner (ServiceAccountLogons)
    on $left.TargetAccount == $right.AccountName
| where LogonTime between (AlertTime .. (AlertTime + 6h))
| project AlertTime, LogonTime, TargetAccount,
    KerberoastedFrom = ComputerDns,
    SubsequentLogonDevice = DeviceName,
    LogonType
| order by AlertTime desc

Common Configuration Gaps Found in Practice

MDI: DCs without sensors. Child domain DCs, ADFS servers, and ADCS servers are the most frequently missed. Teams follow the MDI quickstart guide which covers the primary domain DCs, and ADFS/ADCS sensors never get deployed. An attacker targeting certificate-based authentication (ESC attacks on ADCS) or ADFS token theft is invisible to MDI without those sensors.

MDI: Missing Windows Event IDs. MDI requires specific audit events to be enabled on DCs. If audit policy does not capture Event ID 4662 (directory object access), 4624 (logon events), 4768 and 4769 (Kerberos ticket operations), and 4776 (NTLM validation), detection quality degrades significantly. The MDI sensor configuration page shows which event IDs are missing for each sensor.

MDE: Incomplete onboarding coverage. MDE is only as good as its device onboarding. Commonly missed: servers managed through older SCCM task sequences that were not updated to include MDE onboarding, BYOD devices that policy never reached, and legacy Windows Server 2008 R2 systems where the MDE sensor is not supported. Run a coverage gap query:

// Devices in Entra ID that have not checked in to MDE recently
let ManagedDevices = ExternalData(DeviceName: string)
    [@"https://your-cmdb-export-uri"]
    with (format="csv", ignoreFirstRecord=true);
let MdeDevices = DeviceInfo
    | where TimeGenerated > ago(7d)
    | summarize LastSeen = max(TimeGenerated) by DeviceName;
ManagedDevices
| join kind=leftanti (MdeDevices) on DeviceName
| project DeviceName

MDE: Attack Surface Reduction rules in audit mode only. ASR rules deployed in audit mode log but do not block. Many organizations leave all ASR rules in audit mode indefinitely because switching to block mode requires regression testing against business applications. Rules that should be in block mode for most enterprise environments without exceptions: Block credential stealing from the Windows local security authority subsystem (lsass.exe), Block Office applications from injecting code into other processes, and Block process creations originating from PSExec and WMI commands.

Both: No unified Defender XDR incident queue. If MDI and MDE are both licensed but analysts work from separate product consoles, automatic cross-product correlation does not surface. The unified incident queue at security.microsoft.com is required for the correlation engine to stitch MDI and MDE alerts into a single incident with a coherent attack timeline.

Decision Framework: Do You Need Both?

For any organization with Active Directory, yes. The reasoning:

You need MDI if you have Active Directory. Without it, you have no visibility into Kerberos attack patterns, directory enumeration, DCSync, or golden ticket use. MDE will not detect a golden ticket. MDE will not tell you that an attacker is mapping your AD attack paths using BloodHound. These are directory-layer attacks that require directory-layer sensors.

You need MDE Plan 2 if you have managed endpoints. Without it, you have no process-level endpoint visibility. MDI tells you an account authenticated to a host. It will not tell you what ran under that account after authentication. MDE Plan 1 (included in Microsoft 365 E3) is insufficient for SOC-grade detection: it lacks behavioral EDR depth, Defender Vulnerability Management, threat analytics, and live response.

The licensing path: Microsoft 365 E5 or E5 Security gives you both products at full capability plus Defender XDR correlation. Evaluate total per-seat cost against two separate standalone add-on subscriptions. At scale (500+ users), E5 is typically less expensive per seat when accounting for all included security components.

Hardening Checklist

• [ ] MDI sensors deployed on all domain controllers, including child domain DCs, read-only DCs, and any DC not in the primary domain
• [ ] MDI sensors deployed on ADFS servers and ADCS servers, not only DCs
• [ ] MDI sensor status verified as Running in MDI portal Configuration > Sensors for every listed DC, zero sensors in Stopped state
• [ ] Windows audit policy verified on all DCs: Event IDs 4662, 4624, 4625, 4648, 4768, 4769, 4776 audited at required granularity
• [ ] MDE onboarding coverage verified: every managed workstation and server enrolled, coverage gap KQL query run and reviewed
• [ ] MDE Plan 2 confirmed (not Plan 1): check under Defender XDR > Settings > Endpoints > License
• [ ] Attack Surface Reduction rules moved from audit to block for credential theft (LSASS), Office code injection, and PSExec/WMI process creation rules after business application testing
• [ ] Defender XDR unified portal is the primary SOC incident queue, not separate MDI and MDE consoles
• [ ] Cross-product KQL correlation rules deployed in Defender XDR Advanced Hunting for PTH, Kerberoasting, and lateral movement chaining
• [ ] MDI Lateral Movement Path analysis run quarterly to identify high-risk paths from non-privileged accounts to Domain Admin
• [ ] Service account logon baseline established in MDI: expected source hosts, logon types, and hours configured so deviations trigger automatic alerts
• [ ] ADCS templates reviewed for ESC vulnerabilities (ESC1 through ESC8) using Certify or equivalent tooling before MDI ADCS sensor deployment

Frequently Asked Questions

What does Microsoft Defender for Identity detect that Defender for Endpoint cannot?

Defender for Identity detects attacks at the directory and authentication layer, which is invisible to endpoint-level sensors. Specific detections that MDI provides and MDE cannot replicate include: golden ticket and silver ticket use in Kerberos traffic, DCSync attempts where a compromised account requests all domain credentials from a DC, Pass-the-Hash and Pass-the-Ticket lateral movement visible in authentication logs, BloodHound-style AD enumeration via LDAP queries, and Kerberoasting targeting service account SPNs. MDE does not have visibility into Kerberos ticket operations or LDAP queries because those happen between the client and the domain controller at the network authentication layer.

What does Defender for Endpoint detect that Defender for Identity cannot?

MDE operates at the endpoint and provides process-level, file-level, and network-level visibility on the device itself. MDI tells you that an account authenticated to a host; MDE tells you what happened on that host after authentication. MDE-specific detections include: credential dumping from LSASS memory, malicious process chains spawned by Office documents or script interpreters, DLL injection and process hollowing, Attack Surface Reduction rule violations, and file-level behavioral analysis for unknown malware. MDI cannot see what runs on an endpoint after a user logs in because its sensor is on the domain controller, not the workstation.

Why do both products need to feed the unified Defender XDR incident queue to be effective together?

Defender for Identity and Defender for Endpoint generate alerts in their separate product portals, but the cross-product correlation that creates a coherent attack timeline only happens in the unified Defender XDR incident queue at security.microsoft.com. When MDI detects Kerberoasting against a service account and MDE detects that account being used for lateral movement 30 minutes later, the XDR correlation engine links those events into a single incident with an attack timeline showing the full attack chain. If analysts work from separate product consoles, they see two separate alerts and must manually correlate them, which significantly increases mean time to detect and respond.

What are the most commonly missed MDI sensor deployments in enterprise environments?

The top three missed deployments are: ADFS servers, where attackers who compromise the ADFS service can issue arbitrary SAML tokens without touching a domain controller; ADCS servers, where ESC-class certificate abuse attacks happen through the certificate services API and are invisible without an MDI ADCS sensor; and child domain domain controllers, where teams follow the MDI quickstart guide that covers the primary domain but do not extend sensor deployment to child domains. An attacker operating in a child domain with no MDI sensor coverage can enumerate and move through that domain without any MDI detection.

When is Microsoft 365 E5 licensing more cost-effective than purchasing MDI and MDE as standalone add-ons?

E5 includes MDI, MDE Plan 2, and four additional Defender products (Defender for Office 365 Plan 2, Defender for Cloud Apps, Microsoft Entra ID P2, and Microsoft Purview) at a per-user price that is typically lower than the combined cost of two or three standalone add-ons. At approximately 500 seats or more, E5 is almost always more cost-effective when accounting for all included security components. Below 500 seats, the comparison depends on which specific products are needed: if you only need MDI and MDE without the other E5 components, the Microsoft 365 E5 Security add-on (which includes all six Defender products without the productivity suite) is often the most economical path.