Microsoft Defender XDR Security Guide

Microsoft Defender XDR only works as well as the permissions, automation settings and data connections behind it, and many tenants switch it on without deciding who can isolate a device, disable a user or delete email at scale. Defender XDR is the suite layer in the Microsoft Defender portal that correlates signals from the individual Defender products into one incident queue, adds cross-product advanced hunting and custom detections, and can contain an attack automatically. This guide covers how access works through unified role-based access control, the privileged roles and service identities to control, logging and detection with advanced hunting, automatic attack disruption and the Action center, a hardening baseline and the misconfigurations that weaken it. It is written for SOC leads, security engineers and Microsoft 365 administrators. Endpoint-only configuration is in the Microsoft Defender for Endpoint Guide; the vendor-neutral concepts are in the XDR Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

Correlation depends on what you license and connect. Defender XDR stitches signals only from products that are licensed and provisioned, so gaps in onboarding become gaps in every incident.
Unified RBAC is the access model to aim for. Once a workload is activated, its roles are controlled from the Defender portal, but Entra global roles such as Security Administrator keep working alongside it.
Attack disruption acts on identities as well as devices. It can contain devices and users, disable accounts and revoke sessions, so exclusions and conflicting automations need deliberate decisions.
Native hunting data covers 30 days. Anything you need for longer investigations must be streamed or held in a Sentinel workspace with suitable retention.
Service principals are part of the attack surface. Graph security API apps with hunting and incident permissions read your most sensitive telemetry and need owner, scope and credential controls.

What Defender XDR covers

Microsoft's overview lists the products Defender XDR coordinates: Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps, Defender Vulnerability Management, Defender for Cloud, Entra ID Protection, Microsoft Data Loss Prevention, App Governance, Purview Insider Risk Management and Security Exposure Management. It is reached at the Microsoft Defender portal, security.microsoft.com, and licensing requirements must be met before the service can be enabled.

Capability	What it does	Where it lives
Incidents queue	Joins related alerts, events and impacted assets into one incident with the attack story	Investigation and response, Incidents and alerts
Advanced hunting	KQL queries over up to 30 days of raw data across endpoint, email, identity and cloud apps	Investigation and response, Hunting
Custom detections	Scheduled or continuous hunting queries that raise alerts and take response actions	Hunting, Custom detection rules
Automatic attack disruption	High-confidence, incident-level containment of in-progress attacks	Settings, plus tags on incidents
Action center	Pending and completed remediation actions, with approval and undo	Actions and submissions
Streaming API	Sends advanced hunting events to Azure Event Hubs or a storage account	Settings, Microsoft Defender XDR

How identity and access work in Microsoft Defender XDR

Users sign in to the Defender portal with Microsoft Entra ID, so Conditional Access, phishing-resistant authentication and session controls applied to the portal protect every Defender workload behind it. See the Conditional Access Guide.

Authorisation has three layers, and knowing which one applies avoids most access surprises:

Unified RBAC: one permissions model across Defender solutions, consolidating the per-product models with backward-compatible permissions. It applies to a workload only after that workload is activated; until then the existing product RBAC stays in force. Microsoft states unified RBAC is the default for new Defender for Endpoint and Defender for Identity tenants from 2025, and for new Defender for Office 365 Plan 2 organisations from July 2026; tenants that configured roles earlier keep their old configuration until they activate.
Entra global roles: Defender continues to respect them after activation. Security Administrator is needed for initial access to Permissions and roles. Global Administrators do not automatically get workspace permissions but can assign them, including to themselves.
Purview and Exchange models: Data Loss Prevention and Insider Risk Management are governed by Purview RBAC even when opened from the Defender portal, and Exchange Online and Security & Compliance PowerShell keep their own role groups.

Scope is how you limit blast radius. Defender for Endpoint roles honour device group scope, Defender for Identity roles honour its scoped access, and Sentinel data can be restricted with scope tags. A regional SOC analyst should see and act only on their region's devices.

Admin roles and privileged access

The permissions that matter most are the ones that change state across many users or devices at once.

Permission or role	What it allows	Control
Entra Security Administrator	Manage Defender settings and roles; approve device remediation; create custom detections	Eligible only through privileged identity management, with approval and short activation
Unified RBAC custom role with the Authorization permission	Manage Defender roles without an Entra global role	Treat as Tier 0; assign to a small group
Security operations, Security data, Response (manage)	Approve and take device remediation in the Action center	Analyst roles, scoped by device group
Email & collaboration advanced actions (manage), with Search and Purge	Remediate email at scale, including deletion	Small senior group; review history weekly
Security settings (manage)	Create and edit custom detection rules, which can disable users or isolate devices	Change control for rules with response actions
Roles that can configure attack disruption (for example Security Operator, Helpdesk Administrator, User Administrator)	Change disruption configuration and exclusions	Review who holds these; several are not security roles

Microsoft's configuration page lists a broad set of Entra roles that can configure attack disruption, including User Administrator, Authentication Administrator and Helpdesk Administrator. Exclusions are a quiet way to switch protection off for a target, so log and review changes to them. The Privileged Access Management Guide covers just-in-time patterns.

Integrations, API tokens and service accounts

Defender XDR exposes incidents, alerts and hunting through the Microsoft Graph security API, which means app registrations and managed identities with access to your full security telemetry.

Graph security API: incidents are listed at /security/incidents, alerts at /security/alerts_v2, and hunting runs through POST /security/runHuntingQuery, which needs ThreatHunting.Read.All as a delegated or application permission. By default a Graph hunting query looks back 30 days unless a longer timespan is set in the request.
Legacy APIs: Microsoft is retiring the older Defender for Endpoint and Defender XDR advanced hunting APIs (for example api.security.microsoft.com/api/advancedhunting/run); Message Center notice MC1220762 gives full retirement on 1 February 2027, after which they no longer function. Microsoft also lists the legacy Graph alert resource as deprecated, with retirement scheduled for 15 October 2026, in favour of alerts_v2. Inventory SOAR and SIEM integrations still using them, and remove their old AdvancedHunting.Read.All permissions after migration.
Defender for Identity action accounts: by default the sensor uses the domain controller's LocalSystem account to disable accounts during disruption; for cloud-only users Microsoft uses a managed enterprise application named Microsoft Defender for Identity. Do not delete or restrict that application without understanding the effect.
Unified RBAC and service principals: Microsoft's guidance is to keep using Azure RBAC, not unified RBAC, for service principals that need Sentinel permissions.
Credentials: prefer managed identities or certificate credentials over client secrets for integration apps, give each integration its own app, and record an owner. See the Azure Entra Client Secrets Security Guide and the Entra ID Applications and Consent Guide.

Logging and detection

Advanced hunting

Advanced hunting runs KQL in guided or advanced mode over Defender for Endpoint, Office 365, Cloud Apps and Identity data, plus Sentinel tables when a workspace is onboarded to the Defender portal. Native data is kept for up to 30 days; Sentinel tables follow the workspace's analytics-tier retention, and data held only in the Sentinel data lake is not queryable from advanced hunting. Queries run in UTC, return up to 100,000 rows or 64 MB, and time out after ten minutes. Entity data such as devices and users refreshes hourly.

Custom detections

Frequency	Lookback on Defender data	Typical use
Continuous (NRT)	Near real time	High-signal single events, such as a known malicious hash
Every hour	4 hours	Fast-moving identity or email patterns
Every 3 hours	12 hours	Aggregations such as many failed actions per account
Every 12 hours	48 hours	Slower behavioural patterns
Every 24 hours	30 days	Rare events and long-window correlation

Rules must return Timestamp (or TimeGenerated) and ReportId, plus DeviceId for endpoint tables, and asset columns such as AccountObjectId or RecipientEmailAddress so alerts map to the right entity. Each rule raises at most 150 alerts per run. Response actions include isolate device, collect investigation package, restrict app execution, quarantine file, mark user as compromised (sets Entra risk to high), disable user, reset user authentication and soft or hard delete of email. A rule with a disable or delete action is an automated change to production: review it like code.

Retention and the SIEM

For investigations that reach back further than 30 days, onboard a Sentinel workspace with appropriate retention or stream advanced hunting events through the streaming API to Event Hubs or a storage account. Streaming retention starts from the day you enable it, so enable it before you need it. The Microsoft Sentinel Move to the Defender Portal guide covers the unified portal transition.

Automatic attack disruption and the Action center

Attack disruption evaluates the whole incident rather than a single indicator and, according to Microsoft, keeps a confidence level of 99% or higher for containment actions, validating new detectors in audit mode first. Actions include contain device, contain IP, isolate device, contain user, disable user (through Defender for Identity), revoke user session and suspend user in Entra ID, with OAuth app actions through Defender for Cloud Apps and preview actions for other identity providers through Sentinel. Affected incidents carry an Attack Disruption tag and "(attack disruption)" in the title, every action is added to the Action center, and Microsoft states all automatic actions can be undone by the security team.

Prerequisites shape coverage: Standard device discovery for contain device, a minimum sensor version for contain user, device group remediation levels of Full or Semi (No automated response excludes the group), audit events on domain controllers for Defender for Identity, the Office 365 connector with all options in Defender for Cloud Apps, and mailbox audit events including MailItemsAccessed, UpdateInboxRules, MoveToDeletedItems, SoftDelete and HardDelete in Exchange Online.

Metrics

Onboarding coverage: share of devices, domain controllers and mailboxes reporting to their Defender workload.
Disruption readiness: share of device groups at Full or Semi remediation and number of active exclusions.
Time to approve: median age of pending Action center items.
Standing privilege: count of permanent (non-eligible) Security Administrator and Authorization holders.
Detection health: custom rules with errors, zero results for 90 days, or hitting the 150-alert cap.

Hardening baseline

Onboard fully first. Every endpoint, every domain controller sensor, the Office 365 connector with all options, and Exchange mailbox auditing. Disruption and correlation depend on it.
Activate unified RBAC per workload, import existing roles, then build custom roles by job (tier 1 triage, tier 2 response, hunting, administration) scoped by device group.
Move Security Administrator and the Authorization permission to eligible assignments with approval and phishing-resistant authentication for activation.
Set device group remediation to Full for most groups; use No automated response only for a small, documented set.
Decide exclusions deliberately. Exclude only critical assets where automated containment would cause more harm than the attack, record the reason and an owner, and review quarterly.
Remove conflicting automation. Microsoft warns that automations which re-enable accounts can undo disruption during an attack; pause or adjust them.
Extend retention through Sentinel or streaming before an incident needs it.
Migrate integrations off the retired advanced hunting endpoints and legacy alerts to the Graph security API with least-privilege permissions.
Put custom detections with response actions under change control, preferably as code with peer review.

Common misconfigurations

Partial onboarding: domain controllers without the Defender for Identity sensor, or the Cloud Apps connector without all checkboxes, which Microsoft says can cause failed disruption flows.
Too many standing administrators: permanent Security Administrator and Global Administrator assignments used for day-to-day triage.
Unreviewed exclusions: executives or servers excluded from containment once and never revisited, leaving the most valuable targets unprotected.
No automated response on large device groups, set during a pilot and left in place, which silently removes those devices from disruption.
Retention assumed, not configured: teams discover the 30-day hunting window during an incident that started earlier.
Over-permissioned integration apps: SOAR or reporting apps with write permissions and long-lived client secrets, no owner, and legacy API permissions left after migration.
Email purge rights spread widely: Search and Purge granted broadly, so one compromised analyst account can delete mail across the tenant.

Framework mapping

Defender XDR control	NIST CSF 2.0	NIST SP 800-53 r5
Unified RBAC, scoped custom roles	PR.AA-05	AC-6 Least Privilege, AC-6(5) Privileged Accounts
Onboarding and audit events	DE.CM-01	AU-12 Audit Record Generation, SI-4 System Monitoring
Incident correlation and hunting	DE.AE-02, RS.AN-03	AU-6, IR-5 Incident Monitoring
Attack disruption and Action center	RS.MI-01	IR-4 Incident Handling
Streaming and retention	DE.CM-01	AU-11 Audit Record Retention

Practitioner checklist

Confirm every licensed workload is onboarded and reporting, including domain controller sensors and mailbox auditing.
Activate unified RBAC per workload and replace broad Entra roles with scoped custom roles.
Make Security Administrator and the Authorization permission eligible-only with approval.
Set device group remediation levels to Full or Semi and document every exclusion with an owner.
Pause automations that re-enable disabled accounts.
Extend telemetry retention beyond 30 days through Sentinel or the streaming API.
Inventory Graph security API apps, migrate off retired endpoints and remove unused permissions.
Review custom detections with response actions through change control and check rule health monthly.

Microsoft Defender XDR: Run Incidents Across Endpoint, Identity, Email and Cloud Apps