8.1 Defender XDR Suite and Microsoft Defender Portal

What Microsoft Defender XDR Is

Microsoft Defender XDR is Microsoft's extended detection and response (XDR) suite. It was renamed from Microsoft 365 Defender (which was itself previously Microsoft Threat Protection), and the rename is heavily tested on SC-900 — use Defender XDR as the current umbrella name. XDR means the platform detects and responds to threats across multiple domains rather than one. Defender XDR coordinates four pre-breach and post-breach protection services into a single experience:

The core idea Defender XDR adds on top of the individual products is correlation. Each service generates its own alerts, but Defender XDR automatically connects related alerts across services into a single incident so an analyst sees one attack story instead of dozens of disconnected signals.

The Unified Microsoft Defender Portal

All of this is operated from the Microsoft Defender portal at security.microsoft.com. The portal is the single pane of glass for the Defender family: incident and alert queues, advanced hunting (Kusto Query Language), the action center for remediation, threat analytics, secure score, and per-product settings. SC-900 expects you to know the portal is where you investigate Defender incidents — you do not bounce between separate consoles per product.

Key portal concepts:

• Alert — a single detection of suspicious activity from one Defender service.
• Incident — a collection of correlated alerts, plus the entities (users, devices, mailboxes, files, IPs) and evidence involved, representing one end-to-end attack. Correlation maps to the MITRE ATT&CK framework so the incident reads as a kill-chain story.
• Advanced hunting — proactively query raw signal data across all Defender services with KQL.
• Automatic attack disruption — using high-confidence correlated signals, Defender XDR can automatically contain an in-progress attack (for example, disable a compromised account or isolate a device) before an analyst manually intervenes.

Defender XDR vs. Microsoft Sentinel (the key trap)

The most-tested distinction in this domain is Defender XDR vs. Microsoft Sentinel:

• Defender XDR is an XDR suite — it protects and correlates across the four Microsoft Defender workloads and is largely turnkey for Microsoft 365/Azure data.
• Microsoft Sentinel is a cloud-native SIEM and SOAR — it ingests logs from any source (Microsoft and non-Microsoft, on-prem, multicloud, firewalls, third-party apps), scales for long-term analytics, and automates response with playbooks.

The two integrate: Sentinel can pull Defender XDR incidents in, and Microsoft now offers a unified security operations experience in the Defender portal. But for product-matching: broad SIEM/SOAR, tenant-wide log ingestion, hunting across non-Microsoft data, playbooks = Sentinel; Defender portal incidents correlated across Microsoft 365 workloads = Defender XDR.

A helpful framing: Defender XDR is the native protection and detection layer that already understands Microsoft 365 and Azure deeply and ships ready to use, while Sentinel is the aggregation and orchestration layer that brings everything — including signals far outside Microsoft's own products — into one analytics workspace for long-term retention, custom analytics rules, and automated response.

How a Cross-Domain Incident Forms

Understanding why XDR exists makes the product choice obvious on exam day. Consider a realistic intrusion. An attacker sends a phishing email; Defender for Office 365 detects the malicious link and raises an alert. A user clicks before the block fully propagates and runs a malicious payload; Defender for Endpoint raises a device alert about suspicious process behavior. The attacker harvests credentials and attempts lateral movement against a domain controller; Defender for Identity raises an identity alert. Finally the attacker abuses a sanctioned SaaS app to exfiltrate data; Defender for Cloud Apps raises an anomaly alert.

Without XDR, those are four disconnected alerts in four queues, and a tired analyst might never connect them. With Microsoft Defender XDR, the correlation engine recognizes the shared entities (the same user, the same device, related timestamps and IPs) and stitches the four alerts into one incident that tells the whole story end to end. The analyst opens a single item, sees the full attack chain mapped to MITRE ATT&CK tactics, and can take coordinated action. This is the essence of extended detection and response: detection that spans domains and a response that is coordinated rather than siloed.

Choosing the Right Level

The exam often gives you a broad scenario and asks for the suite, or a narrow scenario and asks for the specific service. Decide by the surface named:

• Broad wording — "a single portal to investigate incidents that span email, devices, and identities" — points to Microsoft Defender XDR.
• A specific protected workload points to the specific Defender service (Office 365, Endpoint, Identity, or Cloud Apps).
• SIEM, SOAR, ingest any log source, hunt across all data, playbooks points to Microsoft Sentinel.
• Compliance, labels, DLP, retention, eDiscovery points to Microsoft Purview.
• Conditional Access, MFA, roles, PIM, Identity Protection points to Microsoft Entra.

Quick decision path

• Defender portal or cross-service incident wording → Defender XDR.
• Named workload (email, device, AD, SaaS app) → the matching Defender service.
• SIEM/SOAR/any-source logs → Microsoft Sentinel.

By auto-correlating alerts, Defender XDR shrinks the analyst's queue from many noisy alerts to fewer high-fidelity incidents, and automatic attack disruption can contain the attack while it is still unfolding. That cross-domain stitching is the value proposition SC-900 wants you to associate with Microsoft Defender XDR.