This chapter provides a comprehensive overview of Microsoft Defender XDR (Extended Detection and Response), a unified security operations platform that correlates signals across endpoints, email, identities, and cloud applications. For the MS-102 exam, this topic is critical as it appears in approximately 15-20% of questions within Domain 3.2 (Security Threats). Understanding how Defender XDR integrates with Microsoft 365 Defender, how it automates incident response, and how to configure its core components is essential for the exam and for real-world administration.
Jump to a section
Imagine a large hospital emergency room (ER) that handles all incoming patients. The ER has a triage nurse (Microsoft Defender XDR) who quickly assesses each patient's symptoms (alerts from endpoints, email, identities, cloud apps). The nurse categorizes patients by severity: critical (red) cases go immediately to the trauma team, moderate (yellow) cases are monitored, and minor (green) cases wait. The ER has specialist doctors (Microsoft Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps) who each focus on a specific body system. The triage nurse doesn't just pass patients; she correlates symptoms across specialists. For example, a patient with a fever (phishing email) and a rash (malicious file on endpoint) might indicate a systemic infection (advanced attack). The nurse uses a central dashboard (unified incidents and alerts) to see all patient data. She also has access to a knowledge base (Microsoft Threat Intelligence) that lists known disease patterns. When a new disease appears, the nurse updates the triage protocol (automatic attack disruption). The ER also has a security guard (Microsoft Sentinel) who monitors the entire hospital for unusual behavior, like someone trying to access the pharmacy without a badge. The guard can lock down the pharmacy (automated response) if needed. The triage nurse and guard work together: the nurse alerts the guard about a suspicious patient, and the guard investigates further. This coordinated approach ensures that no single symptom is missed and that the right response happens quickly.
What is Microsoft Defender XDR and Why It Exists
Microsoft Defender XDR (formerly Microsoft 365 Defender) is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and cloud applications. It was designed to address the challenge of siloed security tools: traditionally, security teams used separate solutions for endpoint detection and response (EDR), email security, identity protection, and cloud app security. Attackers often move laterally across these domains, and without a unified view, defenders miss critical correlations. Defender XDR solves this by ingesting signals from:
Microsoft Defender for Endpoint (MDE)
Microsoft Defender for Office 365 (MDO)
Microsoft Defender for Identity (MDI)
Microsoft Defender for Cloud Apps (MDA)
Microsoft Entra ID (for identity signals)
The platform uses artificial intelligence and machine learning to automatically correlate alerts into incidents, prioritize them by severity, and suggest or execute automated responses. It also provides a single portal (https://security.microsoft.com) for investigation, hunting, and reporting.
How It Works Internally – The Mechanism
Defender XDR operates on a data fusion and correlation engine that runs in Microsoft's cloud. The process can be broken down into several layers:
Data Ingestion: Each Defender component sends telemetry to a common data store. For example:
MDE sends endpoint process events, network connections, file creations, registry changes.
MDO sends email messages, URLs clicked, attachment detonation results, phishing reports.
MDI sends Active Directory authentication events, Kerberos ticket requests, group membership changes.
MDA sends cloud app usage logs, OAuth permissions, file sharing events.
Entra ID sends sign-in logs, risky user detections, conditional access failures.
This data is streamed in near real-time (typically < 2 minutes for most signals) to the unified backend.
Alert Generation: Each component independently generates alerts based on its own detection logic. For instance, MDE might generate an alert for "Suspicious process injection" while MDO generates an alert for "Phishing email delivered to inbox." These alerts are initially standalone.
Incident Correlation: The correlation engine uses a graph-based model to link related alerts. It looks for common entities such as:
- User account (UPN, SID) - Device (device ID, hostname) - IP address - File hash - Email message ID - Attack campaign ID (from Microsoft Threat Intelligence)
When multiple alerts share one or more entities within a time window (default 48 hours, adjustable), they are merged into a single incident. The engine also applies ML models to predict whether alerts are part of the same attack chain.
Incident Prioritization: Each incident is assigned a severity (Informational, Low, Medium, High, Critical) and a classification (True Positive, False Positive, Benign Positive). The classification is based on the confidence of the correlation and the presence of known indicators of compromise (IOCs). The platform also uses a "threat score" that combines the severity of individual alerts, the number of affected entities, and the attack stage (e.g., initial access, lateral movement).
Automated Investigation and Response (AIR): For incidents meeting certain criteria (e.g., high severity, known attack pattern), Defender XDR can automatically launch playbooks. These playbooks run on virtual machines in Microsoft's cloud and perform actions such as:
- Collecting additional evidence from endpoints (e.g., memory dump, network capture) - Isolating a device from the network - Deleting a malicious email from all mailboxes - Disabling a compromised user account - Revoking suspicious OAuth grants
The results are presented in a unified timeline within the incident.
Threat Intelligence Integration: Defender XDR ingests threat intelligence from Microsoft's global network (over 8 trillion signals daily) and from third-party feeds via Microsoft Defender Threat Intelligence (MDTI). This intelligence is used to enrich alerts with context (e.g., known attacker group, attack tool) and to drive detection rules.
Key Components, Values, Defaults, and Timers
Incident correlation window: Default 48 hours. This means alerts on the same entity within 48 hours are candidates for merging. This can be changed in the Microsoft 365 Defender settings under "Incident settings."
Alert severity levels: Informational, Low, Medium, High, Critical. The severity is determined by the individual component's logic, but the incident's overall severity is the highest among its alerts.
Automated investigation and response (AIR): Enabled by default for all Defender components. The level of automation can be set to:
- Full (automatically remediate) - Semi (require approval for destructive actions) - Off (only investigate) - Time to live for quarantined items: 30 days for email messages, adjustable per policy. - Data retention: Most telemetry is retained for 30 days (for hunting) and 180 days for incidents. Advanced hunting data (Kusto queries) can be retained up to 30 days by default, extendable to 2 years with additional licensing. - Signal latency: Most signals arrive within 2 minutes, but some (e.g., cloud app events) may take up to 10 minutes.
Configuration and Verification Commands
While most configuration is done via the Microsoft 365 Defender portal, some settings can be managed via PowerShell or APIs. For example:
To get incident details via Microsoft Graph API:
GET https://api.security.microsoft.com/api/incidents/{incidentId}To enable or disable automatic investigation for a device group via Microsoft Defender for Endpoint API:
PATCH https://api.security.microsoft.com/api/machines/{machineId}/automation
{
"automationLevel": "full"
}To check the health of data connectors (e.g., for MDE, MDO) via the Microsoft 365 Defender portal, navigate to Settings > Endpoints > Advanced features or Settings > Email & collaboration > Threat investigation and response.
To run a hunting query in Advanced Hunting:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName == "powershell.exe"
| project Timestamp, DeviceName, AccountName, ProcessCommandLineHow It Interacts with Related Technologies
Microsoft Sentinel: Defender XDR incidents can be streamed to Microsoft Sentinel via a connector. Sentinel provides SIEM capabilities, while Defender XDR provides XDR. They complement each other: Sentinel correlates across multiple data sources including non-Microsoft systems, while Defender XDR focuses on Microsoft security products.
Microsoft Purview Compliance Portal: Defender XDR alerts may contain sensitive data; Purview can enforce data loss prevention (DLP) policies on investigation data.
Microsoft Intune: Device compliance policies from Intune can feed into Defender XDR for conditional access decisions.
Microsoft Entra ID Protection: Risky sign-in events from Entra ID Protection are ingested by Defender XDR as identity alerts.
Microsoft 365 Lighthouse: For managed service providers, Defender XDR incidents from multiple tenants can be viewed in a single dashboard.
Exam Focus: What MS-102 Tests
The MS-102 exam specifically tests your ability to:
Describe the components of Microsoft Defender XDR.
Explain how incidents are created from alerts.
Configure automated investigation and response.
Understand the integration points with other Microsoft security services.
Interpret the incident dashboard and response actions.
Common wrong answers include:
Confusing Defender XDR with Microsoft Sentinel (SIEM vs XDR).
Thinking that Defender XDR replaces all individual Defender components (it doesn't; they still run independently).
Assuming that all alerts automatically become incidents (they don't; correlation is needed).
Forgetting that automated response requires specific licensing (E5 or add-on).
Trap numbers: The 48-hour correlation window is a frequent exam question. Also, know that Defender XDR is included with Microsoft 365 E5, but individual components (like MDE) require separate licensing for non-E5 tenants.
Ingest Signals from All Components
Each Defender component (MDE, MDO, MDI, MDA, Entra ID) sends telemetry to the unified backend. For example, MDE sends endpoint process trees and network connections via the cloud connector. MDO sends email metadata and detonation results. MDI sends Active Directory authentication logs and Kerberos ticket requests. This data is normalized into a common schema and stored in a high-speed data lake. The ingestion latency is typically under 2 minutes for most signals, but can be up to 10 minutes for cloud app events. Administrators can verify data flow by checking the service health dashboard in the Microsoft 365 Defender portal.
Generate Individual Alerts
Each component independently analyzes its telemetry using built-in detection logic. For instance, MDE detects suspicious process injection based on behavioral signatures. MDO detects a phishing email based on URL reputation and machine learning models. MDI detects a Kerberos golden ticket attack based on anomalous TGT requests. Each alert includes metadata such as severity, affected entities (user, device, IP), and a description. Alerts are initially stored as separate items in the data lake. The exam may test that alerts are generated by the individual components, not by Defender XDR itself.
Correlate Alerts into Incidents
The correlation engine runs continuously and links alerts that share common entities (user, device, IP, file hash, email message ID) within a 48-hour sliding window. For example, if MDE detects malware on a device and MDO detects a phishing email sent to the same user, the engine merges them into one incident. The correlation uses a graph database and machine learning to identify attack chains. The incident is assigned a severity equal to the highest severity among its alerts. The exam frequently tests the 48-hour default window and the entity-based correlation logic.
Prioritize and Classify Incidents
Each incident is classified as True Positive, False Positive, or Benign Positive. The classification is based on confidence scores from detection engines and threat intelligence. The incident also receives a severity level (Informational, Low, Medium, High, Critical). The overall severity is the maximum of its alerts. Additionally, the incident is assigned a threat score that factors in the attack stage (e.g., initial access, lateral movement) and the number of affected entities. This helps security teams focus on the most critical incidents first.
Execute Automated Investigation and Response
For incidents that meet criteria (e.g., high severity, known attack pattern), Defender XDR can automatically launch playbooks. These playbooks run in an isolated environment and perform actions such as collecting additional evidence, isolating a device, deleting malicious emails, or disabling accounts. The automation level can be configured per device group or component. The results are displayed in the incident timeline. Administrators can approve or reject pending actions. The exam may ask about the default automation level and how to change it.
Enterprise Deployment Scenarios
Scenario 1: Large Financial Institution with 50,000 Endpoints
A bank deploys Microsoft Defender XDR to protect against advanced persistent threats (APTs). They have Microsoft 365 E5 licenses, which include all Defender components. The security team configures automated investigation to run in full mode for critical servers and semi mode for workstations. They use the unified incident dashboard to triage over 200 alerts per day. One common issue is false positives from legitimate software installations. To reduce noise, they create custom detection rules and exclusion lists. They also integrate Defender XDR with Microsoft Sentinel for long-term log retention and compliance reporting. The correlation engine successfully identified a ransomware attack that started with a phishing email (MDO alert), then executed on a workstation (MDE alert), and attempted lateral movement via RDP (MDI alert). The incident was automatically escalated and the device isolated within 2 minutes.
Scenario 2: Mid-Size Healthcare Provider with 5,000 Users
A hospital uses Defender XDR to protect patient data. They have Microsoft 365 Business Premium licenses, which include limited Defender capabilities. They enable automated response for email phishing (MDO) but not for endpoint isolation due to concerns about disrupting critical medical devices. They configure custom threat alerts for suspicious access to electronic health records (EHR) systems. A misconfiguration occurred when they excluded a medical device from MDE scanning, which later turned out to be compromised. The attack went undetected for 48 hours. After remediation, they implemented device groups with different automation levels. The exam tip: understand that Business Premium includes Defender for Office 365 Plan 1 and Defender for Business (basic EDR) but not full XDR.
Scenario 3: MSP Managing 100 Tenants
A managed service provider uses Microsoft 365 Lighthouse to view Defender XDR incidents across all client tenants. They configure automated response to run in semi mode for all tenants to avoid accidental disruptions. They use advanced hunting queries to detect patterns across tenants, such as a phishing campaign targeting multiple clients. A common challenge is tenant-specific exclusions and policies. They use Azure Lighthouse to manage security policies centrally. The MSP also integrates Defender XDR with their own SIEM for cross-tenant correlation.
MS-102 Exam Focus: Microsoft Defender XDR
Objective Codes: The exam domain "Security Threats" includes objective 3.2: "Describe the capabilities of Microsoft Defender XDR." This covers:
Understanding the components (MDE, MDO, MDI, MDA, Entra ID)
How incidents are created from alerts
Automated investigation and response
Integration with Microsoft Sentinel and other services
Licensing requirements (E5 vs. E3 with add-ons)
Common Wrong Answers: 1. Confusing XDR with SIEM: Many candidates think Defender XDR is a SIEM. It is not; it is an XDR solution. Microsoft Sentinel is the SIEM. The exam may ask: "Which Microsoft security solution provides SIEM capabilities?" Answer: Microsoft Sentinel, not Defender XDR. 2. Assuming all alerts become incidents: The correlation engine only merges related alerts. Standalone alerts remain as alerts, not incidents. The exam might present a scenario where a single alert exists and ask if it becomes an incident. The correct answer is no, unless it is correlated with another alert. 3. Forgetting the 48-hour correlation window: This is a frequent trap. The exam may say "24 hours" or "72 hours" as distractors. Always remember the default is 48 hours. 4. Thinking Defender XDR replaces individual components: It does not. Each component still runs independently and generates its own alerts. Defender XDR just correlates and orchestrates.
Specific Numbers and Values:
Default incident correlation window: 48 hours
Data retention for advanced hunting: 30 days (default), extendable to 2 years
Automated investigation levels: Full, Semi, Off
Licensing: Microsoft 365 E5, E5 Security, or standalone add-ons
Edge Cases:
If a user has multiple alerts across components but the entities do not match (e.g., different IPs, different devices), they will not be correlated. The exam might test that correlation is entity-based.
Automated investigation can be paused if the incident is manually classified as a false positive.
Incident severity is the maximum of its alerts, not an average.
How to Eliminate Wrong Answers:
If the question mentions "SIEM" or "log aggregation from third-party sources," the answer is likely Microsoft Sentinel, not Defender XDR.
If the question asks about "correlation of alerts from multiple domains," it is Defender XDR.
If the question mentions "automated response playbooks," consider both Defender XDR (AIR) and Microsoft Sentinel (SOAR). The key difference: Defender XDR's playbooks are pre-built and focused on Microsoft products; Sentinel's are customizable and can integrate with third-party systems.
Microsoft Defender XDR correlates alerts from MDE, MDO, MDI, MDA, and Entra ID into unified incidents.
The default correlation window is 48 hours; alerts on the same entity within this window are merged.
Incident severity is the maximum severity of its constituent alerts.
Automated investigation and response (AIR) can be set to Full, Semi, or Off per device group.
Defender XDR is not a SIEM; it is an XDR solution. Microsoft Sentinel is the SIEM.
Licensing: Microsoft 365 E5 or E5 Security provides full Defender XDR capabilities.
Advanced hunting data is retained for 30 days by default, extendable to 2 years with additional licensing.
The Microsoft 365 Defender portal (security.microsoft.com) is the single pane of glass for incident management.
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Defender XDR
XDR solution that correlates alerts from Microsoft security products only
Incidents are created automatically from correlated alerts
Pre-built automated response playbooks focused on Microsoft products
Included with Microsoft 365 E5 or E5 Security
Data retention up to 30 days for hunting (extendable to 2 years with extra cost)
Microsoft Sentinel
SIEM solution that ingests logs from any source (Microsoft and third-party)
Incidents are created based on analytics rules you define
Customizable automation using Logic Apps and playbooks
Licensed separately (per GB ingested or per node)
Data retention configurable up to 2 years or more based on workspace tier
Mistake
Microsoft Defender XDR replaces Microsoft Defender for Endpoint.
Correct
No, Defender XDR is an overlay that correlates alerts from multiple Defender components, including Defender for Endpoint. Each component still functions independently and generates its own alerts.
Mistake
All alerts in Defender XDR automatically become incidents.
Correct
Only alerts that are correlated with other alerts based on shared entities within a 48-hour window become part of an incident. Standalone alerts remain as alerts.
Mistake
Defender XDR is a SIEM solution.
Correct
Defender XDR is an XDR (extended detection and response) solution. Microsoft Sentinel is the SIEM. Defender XDR focuses on Microsoft security signals, while Sentinel ingests data from any source.
Mistake
Automated investigation and response requires manual approval for all actions.
Correct
The automation level can be set to Full, Semi (requires approval for destructive actions), or Off. Full automation allows automatic remediation without human intervention.
Mistake
Defender XDR is available with Microsoft 365 Business Basic licenses.
Correct
Defender XDR requires Microsoft 365 E5, E5 Security, or standalone licenses for each component. Business Basic includes only basic security features like Exchange Online Protection, not full XDR.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Microsoft Defender XDR is the new name for Microsoft 365 Defender. The rebranding occurred in late 2023 to align with the Defender product family. The functionality remains the same. For the MS-102 exam, both names may appear, but the official name is now Microsoft Defender XDR.
Automated investigation and response is enabled by default for all components. You can configure the automation level per device group in the Microsoft 365 Defender portal under Settings > Endpoints > Device groups. Options are Full (automatically remediate), Semi (require approval for destructive actions), or Off. For email, configure in Threat policies > Anti-phishing > Automated investigation and response.
Yes, but you need licenses for each component. For example, you can buy standalone Defender for Endpoint Plan 2, Defender for Office 365 Plan 2, etc. However, the full XDR capabilities (incident correlation across all domains) require that you have all components licensed. Microsoft 365 E5 includes all components.
In the Microsoft Sentinel portal, add a data connector for Microsoft Defender XDR. This connector ingests incidents and alerts from Defender XDR into Sentinel. You can then use Sentinel's analytics rules and playbooks for further correlation and response. The integration allows bi-directional linking: from Sentinel you can view Defender XDR incidents.
Incidents are retained for 180 days in the Microsoft 365 Defender portal. After that, they are deleted. You can export incidents via API or stream them to Microsoft Sentinel for long-term retention. Advanced hunting data (raw telemetry) is retained for 30 days by default, but you can extend to 2 years with additional licensing (add-on for Defender for Endpoint).
You can manually classify an incident as a false positive, which will suppress future similar alerts. You can also create custom detection rules with exclusions. Automated investigation may also classify alerts as benign based on analysis. For persistent false positives, create suppression rules in the relevant component (e.g., MDE exclusion for a specific file).
Microsoft Threat Intelligence (MDTI) provides context for alerts by identifying known attacker groups, tools, and campaigns. This enrichment helps analysts understand the severity and scope of an incident. Defender XDR uses MDTI to assign a threat score and to drive automated response decisions. For example, if an alert matches a known APT pattern, automation may be triggered more aggressively.
You've just covered Microsoft Defender XDR Overview for Admins — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?