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. 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.

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