Microsoft Defender for Identity explained

Microsoft Defender for Identity (MDI) is the part of the Defender stack that watches for identity-based attacks — credential theft, lateral movement, golden ticket attacks, DC reconnaissance, and the like. It's purpose-built for hybrid identity, with sensors on domain controllers and (more recently) on Entra Connect servers and Entra ID itself.

What MDI detects

A non-exhaustive list of the techniques MDI watches for:

• Reconnaissance — account enumeration, SMB session enumeration, network mapping.
• Compromised credentials — brute force, password spray, suspicious sign-ins.
• Lateral movement — pass-the-hash, pass-the-ticket, overpass-the-hash, NTLM relay.
• Domain dominance — golden ticket, silver ticket, DCSync, DCShadow.
• Exfiltration — unusual SMB activity, large file copies.
• Entra ID-side attacks — risky sign-ins, anomalous OAuth grants, password spray against cloud-only accounts.

Detections fire as alerts that flow into Defender XDR alongside endpoint, email, and cloud-app signals.

How sensors work

MDI deploys sensors on:

• Domain controllers — capture network traffic, ETW events, and AD events.
• AD FS servers (if you still run federation).
• Entra Connect servers.
• Entra ID — cloud-side identity protection signals are also surfaced through MDI in the unified portal.

Sensors run as a small Windows service with minimal performance impact. Best practice is to deploy a sensor to every DC, not just a sample, so blind spots don't accumulate.

Integration with the rest of Defender

MDI's value compounds when its signals correlate with others in Defender XDR:

• A phishing click in Defender for Office 365 →
• Credential theft on an endpoint in Defender for Endpoint →
• A lateral movement attempt in MDI →
• A suspicious SaaS sign-in in Defender for Cloud Apps.

XDR groups these into a single incident with the full attack timeline, automating the manual correlation that's traditionally taken days.

Identity Threat Detection and Response (ITDR)

MDI is Microsoft's offering in the ITDR category — identity threat detection and response. As identity is increasingly the attack surface of choice (most modern breaches don't need a "real" malware payload), ITDR is one of the highest-leverage security investments a Microsoft 365 customer can make.

Licensing

MDI is included in Microsoft 365 E5, Microsoft 365 E5 Security, and Enterprise Mobility + Security E5. It's also sold standalone.

Rollout

• Inventory all DCs (including disaster-recovery sites).
• Deploy sensors broadly — coverage gaps are blind spots.
• Tune directory service account audit policies (MDI provides scripts).
• Validate detections with simulated attacks using tools like AtomicRedTeam or BloodHound.
• Onboard SOC analysts to the Defender XDR portal and advanced hunting.

For organisations with on-premises AD, MDI is the single most useful detection product they can deploy.

Decision matrix — where MDI belongs

| Situation | Verdict | |---|---| | Hybrid tenant with on-prem AD DS | Yes — sensor on every DC, plus Entra Connect. Highest-leverage security purchase on E5. | | Cloud-only tenant, no AD DS | Skip MDI; rely on Entra ID Protection and Defender for Cloud Apps for identity-side signal. | | Federated via ADFS still | Yes — MDI sensors on ADFS pick up the token-forging and password-spray patterns you cannot see cloud-side. | | Migrating off AD DS onto cloud-only | Keep MDI running through the migration; the risky window is exactly when attackers try to pivot from the on-prem side. | | DC in a segregated OT / SCADA subnet | Deploy but expect network-permission negotiations; MDI sensor needs outbound HTTPS. |

Wrong-fit warnings

• MDI is not a domain-controller EDR. It watches for identity attack patterns, not general endpoint malware. Defender for Endpoint on the DC is a separate control (and is recommended alongside).
• Sensors are not sampling — you need coverage. A missed DC is an unmonitored path; attackers will find it.
• The Directory Service Account (DSA) needs the right auditing tuned. Without the Microsoft-provided audit policy applied to AD, MDI is deaf to key events.
• Alerts without a SOC are noise. MDI's value is XDR correlation and analyst response; deploying it without anyone reading the alerts wastes the licence.
• Golden Ticket alerts sometimes fire on domain-controller promotions or backup restores. Rehearse the response so you can distinguish real from operational quickly.

Worked example — a hybrid tenant hardening against ransomware

Scenario: 3,500 employees, on-prem AD DS with eleven domain controllers across two forests, Entra Connect for hybrid identity, M365 E5 Security.

• Week 1: Deploy the DSA and apply the audit policy on all DCs. Install the sensor on the DR-site DCs first (they are the ones no one remembers to patch). Confirm health in the Defender portal.
• Week 2: Sensor on remaining DCs plus both Entra Connect servers. Enable Kerberos delegation review; catches misconfigured service accounts and old app pools with excessive rights.
• Week 3: Turn on entity tags for the ~40 sensitive accounts (domain admins, service accounts for backup, T0 assets). Alerts on these get promoted to Sev1 in XDR.
• Week 4: Rehearse a golden-ticket detection with the SOC. Confirm the XDR incident groups the endpoint, identity, and O365 sign-in signals into one thread. Time the response from alert to containment.
• Ongoing: Quarterly Atomic Red Team run of the classic AD attacks; MDI is expected to detect every one and produce the story an analyst can act on.

FAQ for MSPs

• Can MDI be deployed into a customer's on-prem environment via GDAP? Sensor install is on-box (installer + service). GDAP gets you the portal side; the customer's ops team, or an MSP field engineer, installs the sensor binary.
• Do the sensors phone home differently from Defender for Endpoint? Yes — MDI sensors use dedicated endpoints in the customer's tenant region; whitelist those specifically on egress proxies.
• Are MDI alerts visible in Lighthouse? Not directly. Ship them via the Defender XDR REST/streaming API to your SIEM or PSA for the shared view.
• Which one first — MDI, MDE, or MDO — in a limited-hours engagement? Order depends on the last breach class: identity-driven and lateral movement -> MDI. Phishing and BEC -> MDO. Endpoint payloads -> MDE. In a typical mid-market ransomware playbook, MDI is the highest-leverage first cabinet to open.