Microsoft Defender XDR (extended detection and response) is the suite that joins Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps and more into one portal, the Microsoft Defender portal. Before a security operations center (SOC) can use it well, someone has to configure a few tenant-wide settings: who gets told about incidents, which known-benign alerts are quieted, who can see and do what, and how devices are grouped. None of these settings detect anything by themselves, but together they decide whether the right analyst sees the right incident quickly and without drowning in noise. The exam treats them as the foundation of a working SOC.
Email notifications live under Settings, Microsoft Defender XDR, Email notifications. There are separate rule types for incidents, for response actions and for threat analytics. An incident notification rule has a name, a list of recipients and filters, such as minimum severity, the source product (for example only Defender for Identity) or device group. You can also choose whether one email is sent per incident or per new alert added to it, and whether the email includes organization details. A common design is to email the on-call lead for every high-severity incident and nobody for low ones. Email is a supplement, not the queue: analysts still work incidents in the portal, and a notification rule never changes an incident's status.
Alert tuning, previously called suppression rules, handles alerts you have already investigated and judged benign, such as a legitimate admin tool that always triggers the same detection. You find it under Settings, Microsoft Defender XDR, Alert tuning, or create a rule directly from an alert's page. You build a rule from conditions on the alert and its evidence (file name or hash, process command line, IP address, user, device) and choose a scope: every device or only selected ones. The action is either to hide the alert or to resolve it automatically. Tuning changes only alerting. Protection and data collection keep running, which is why tuning is safer than an allow indicator or an antivirus exclusion, both of which change what the product blocks or scans.
Access in the portal is controlled in two ways. Microsoft Entra ID roles such as Global Administrator, Security Administrator, Security Operator and Security Reader apply across the whole tenant and every workload. Microsoft Defender XDR Unified role-based access control (RBAC) lets you build custom roles from permission groups (security operations, security posture, and authorization and settings) and assign them to users or groups for chosen data sources, such as endpoints only or email only. You activate unified RBAC per workload under Settings, Microsoft Defender XDR, Permissions. Least privilege means Tier-1 analysts get read and triage rights, while only a small group can change settings or run live response.
Device groups are defined under Settings, Endpoints, Device groups. Each group has a rank, matching rules (device name, domain, tag or operating system), an automation level (from no automated response to full remediation) and a list of Microsoft Entra user groups that may access it. A device joins only the highest-ranked group whose rules it matches, and anything that matches nothing lands in the default ungrouped devices group. Device groups do three jobs: they scope who can see and act on devices, they set how much automated investigation and remediation (AIR) happens, and they can scope notifications, indicators and tuning rules. Tags, set manually or through a registry value or Intune, are the usual way to steer a device into a group.
Consider a worked example. A hospital's backup software triggers a credential-access alert every night on two backup servers. The SOC lead confirms the behavior is expected by checking the process path and signer, then chooses Tune alert from the alert page. She sets conditions on the process file path and command line, scopes the rule to a device group containing only those two servers, and sets the action to resolve the alert. She also creates an EU-Servers device group, ranked above the general servers group, with semi-automated remediation and access for the EU analysts' Entra group only. Finally, an incident notification rule emails the on-call lead for high-severity incidents from any source.
Common mistakes: using a tenant-wide allow indicator or exclusion to silence one noisy alert, which weakens protection everywhere; scoping a tuning rule to all devices when only two need it; assuming a lower-ranked device group wins because its rule is more specific (rank decides, not specificity); giving analysts Security Administrator when a custom unified RBAC role would do; and forgetting that devices in no group still need an owner and an automation level. Another trap is expecting an email rule to page someone reliably at night; integrate the incident queue with your on-call tooling if that matters.
Exam questions are usually short scenarios. 'Stop a known-benign alert without reducing protection' points to alert tuning with a narrow scope. 'Analysts in one region must only see their region's devices' points to device groups with Entra user group access. 'Grant a custom set of permissions only for email data' points to Defender XDR unified RBAC. 'Notify a manager only for high-severity incidents' points to an incident email notification rule with a severity filter. 'A device matches two groups' is answered by rank.
Key terms
- Alert tuning rule
- A rule, formerly called a suppression rule, that hides or auto-resolves alerts matching chosen conditions without changing protection.
- Unified RBAC
- Defender XDR's role-based access control model, where custom roles combine permission groups and are assigned per data source.
- Device group
- A ranked set of devices, defined by matching rules, that controls access, automation level and scope for other settings.
- Device group rank
- The order that decides which group a device joins when it matches several; the highest-ranked match wins.
- Incident notification rule
- A setting that emails chosen recipients when incidents matching filters such as severity or source are created or updated.
- Automation level
- The per-device-group setting that decides whether automated investigation remediates on its own or waits for approval.
A hospital's backup software triggers a suspicious credential access alert every night on two backup servers. After confirming the behavior is expected, the SOC lead creates an alert tuning rule for that process path, scoped to those two servers, set to resolve the alert. The same detection still fires on any other device, and a new incident notification rule emails her only for high-severity incidents.
Check yourself
Why is an alert tuning rule usually safer than a tenant-wide allow indicator for a noisy admin tool?
Tuning only hides or resolves the alert; the tool is still monitored and protection is unchanged. An allow indicator changes prevention for every device in the tenant.
A device matches the rules of two device groups. Which one does it join?
The one with the higher rank. Devices join only the highest-ranked group whose matching rules they meet.
What filters can an incident email notification rule use?
Filters such as minimum severity, the source product and device groups, along with the list of recipients.
You need a role that lets a team triage only email alerts. Which feature do you use?
A custom Defender XDR unified RBAC role with security operations permissions, assigned for the email and collaboration data source only.