Defender XDR Automation for SC-200: Email Notifications, Alert Tuning, Correlation, AIR and Attack Disruption

Defender XDR automation is configured in the Microsoft Defender portal, mostly under Settings > Microsoft Defender XDR, and falls into four jobs: telling people, filtering alerts, grouping alerts into incidents and responding automatically. SC-200 expects you to pick the setting that does the one job a scenario asks for, because the settings look alike but act at different points.

A common exam trap is reaching for the wrong job: an alert tuning rule never reduces the number of incident emails, a notification rule never creates an alert, and a correlation setting never closes one.

This lesson covers the Defender XDR half of SC-200 task 1.1. Defender for Endpoint settings, device group creation, and Microsoft Sentinel automation rules and playbooks belong to sibling topics and are only referenced here.

Email notification rules live under Settings > Microsoft Defender XDR > Email notifications, on three tabs: Incidents, Actions and Threat analytics. Each tab notifies about something different, so choose the tab by what the recipient needs to hear about.

Incident notification rules

An incident rule has a name and description, notification settings and a recipient list. The notification settings are:

• Alert severity, chosen per service source or detection source. One rule can, for example, ask for only High alerts from Defender for Identity and Low and above from Defender for Office 365, so sources with different thresholds don't each need their own rule.
• Device group scope: all device groups or selected ones.
• Send only one notification per incident: stops a new email each time another alert joins an incident the recipients already know about.
• Include organization name and Include tenant-specific portal link (a link with the tenant ID, useful for people who work across tenants). These change the email's content, not how many are sent.

On the Recipients page you add addresses and can select Send test email. New recipients receive notifications only for incidents after they are added.

Response-action notification rules

The Actions tab emails about response actions taken in your tenant. You choose the action source (Manual, Automated or both; automated covers automatic attack disruption and automated investigation and response), the actions to track (for example Isolate device), the device groups, and the action status (Completed, Failed or both). The filters combine: Manual + Completed, for instance, reports only analyst-run actions that succeeded. Microsoft documents one limitation: these notifications don't currently support custom detections that contain response actions.

Threat analytics notification rules

The Threat analytics tab emails when Microsoft publishes a new threat analytics report or updates an existing one. A rule tracks all reports, or only reports of a chosen type or with a chosen tag (for example Ransomware). It reports on Microsoft's research, not on incidents in your tenant.

Who can configure them

Configuring notification rules needs the Manage security settings permission; with basic permissions, that means Security Administrator or higher. Global Administrator isn't required. When the organization uses role-based access control, a user can create, edit, delete and receive notifications only for the device groups they are allowed to manage. A rule's device group scope can't reach beyond the owner's RBAC scope.

Alert tuning (previously called alert suppression) automatically hides, resolves or converts alerts that match conditions you define, for expected activity such as internal tools or security tests. Rules are created under Settings > Microsoft Defender XDR > Alert tuning, or from an alert with Tune alert. Conditions are built from evidence types (files, processes, scheduled tasks, AMSI scripts, WMI events and more), combined with AND, OR and grouping; condition values aren't case-sensitive.

Each rule takes one of three actions. They differ in whether an incident is created, where the data stays and which products they support:

Choose by what must remain afterwards: Resolve alert leaves a closed, auditable alert and incident; Hide alert leaves no incident but keeps the alert data in the Alert tables; Set as behavior turns matching signals into behaviors in the Behavior tables. For example, a sanctioned vulnerability scanner whose activity the SOC wants recorded but never triaged suits Resolve alert. Filtering the queue view is not tuning; it hides nothing from incident creation.

When creating from an alert you choose whether the rule applies only to that alert type or to any alert type matching the conditions (then you also pick service and detection sources). Within each service source you can also select specific detection sources, so a rule targets only those; a rule that isn't narrowed this way applies to all detection sources of its service sources, including custom detections.

Tuning silences alerts; it doesn't stop blocking

A tuning rule changes only alerting. If Defender Antivirus keeps quarantining a trusted tool's file, the alert disappears but the block continues. After you create a rule from an alert, the Successful rule creation page offers to add the alert's evidence (IOCs) to an allow list as indicators, with the rule's IOCs selected by default. That allow indicator, scoped to the file, is what stops the block.

Microsoft Defender ships built-in alert tuning rules that suppress alerts for common benign activity; they are active by default and can be reviewed and disabled on the Alert tuning page. Key facts:

• Built-in rules suppress alerts without affecting other features such as AIR investigations and email notifications. If an AIR investigation finds malicious or suspicious activity, the suppressed alert is reactivated.
• Built-in rules don't apply to alerts from custom detection rules or Custom TI indicators. A custom detection you wrote keeps alerting even when a built-in rule covers the same activity.
• To stop a built-in rule, select it and choose Disable. You don't edit its action.

The Microsoft Security Copilot Phishing Triage Agent doesn't classify alerts suppressed by alert tuning. If you deploy it, disable the built-in Auto-Resolve - Email reported by user as malware or phish rule (and any custom rule suppressing those alerts); otherwise the user-reported phish alerts arrive already resolved and the agent has nothing to classify. Disabling only that rule leaves the other built-in rules running.

Alert service settings

Alert service settings (Settings > Microsoft Defender XDR > Alert service settings, also reachable from the Incidents page) decide which detections from a service become alerts in the first place. For Microsoft Entra ID Protection (enhanced options, in preview) the new default is High-risk detections only; you can change it to High + Medium or All detections. Alert service settings act before an alert exists; tuning rules act only on alerts that already exist.

Correlation settings decide whether alerts from a detection rule can be grouped by Defender XDR's correlation engine with other alerts, or are grouped only by the rule's own configuration. They matter most after Microsoft Sentinel is onboarded to the Defender portal, where Sentinel analytics rule alerts can otherwise be merged into larger cross-product incidents that a Sentinel-era playbook or ticketing flow doesn't expect.

Sentinel analytics rules

• A tenant-wide Incident correlation default setting (Settings > Microsoft Defender XDR > Rules > Incident correlation) decides whether analytics rules take part in correlation by default. Learn currently describes it as off by default; check the setting in the tenant rather than assuming.
• Each rule's Incident settings tab has an Incident correlation option: Tenant default, Enabled (included) or Disabled (excluded). Disabled gives Sentinel-style incidents that follow only the rule's alert grouping. Setting Enabled or Disabled in the portal writes the matching tag into the rule's description.
• Through the API or rule description, the tags #INC_CORR# (include) and #DONT_CORR# (exclude) do the same. A tag counts only at the very start of the description, with both # characters, and is not case-sensitive.
• An alert's correlation state is fixed when the alert is created. Changing a rule affects new alerts only.
• Excluded alerts still appear in the portal; they simply bypass correlation.

Custom detection rules

Custom detections written in advanced hunting have no tenant default: existing and new custom detection rules are included in correlation by default, whatever the analytics-rule tenant setting says. Each rule can be set to Include in or Exclude from correlation on its details page (in public preview). Tags and the tenant default don't apply to them. Excluded custom detection alerts create their own incidents unless an incident alert-grouping rule applies, because alert-grouping rules remain final. Severity has no effect on correlation.

Only the primary workspace correlates

With several Sentinel workspaces onboarded, one is the primary workspace. Only its alerts can be correlated with Defender alerts. Alerts from secondary workspaces are never correlated with Defender alerts or with other workspaces, whatever the rule-level settings or tags say, and ingesting Defender data into a secondary workspace doesn't change that. To correlate another workspace's alerts, make it the primary, which moves correlation away from the old primary.

Defender keeps correlating after incidents exist and merges incidents that share entities (users, devices, mailboxes), artifacts (files, processes, senders), time frames or multistage event sequences. A merge doesn't create a new incident: the source incident's alerts, tags and entities move into the target, the source is closed with a Redirected tag, and Defender chooses the direction.

Even when correlation says two incidents belong together, Defender doesn't merge them when:

• one of them is Closed (resolved incidents aren't reopened);
• they are assigned to two different people (unassigned incidents can merge);
• they have different classifications or determinations;
• the merge would push the target over the maximum number of entities;
• they contain devices in different device groups, but only if the organization has enabled that condition (it is off by default).

Different severities or alerts from different Defender products never block a merge; merging across products is the point of XDR correlation.

To combine incidents that weren't merged, fix the blocker first, then merge manually (for example remove one assignee). Microsoft documents that up to five incidents can be merged manually at a time, and that merging is preferable to moving alerts from one incident to another because merging preserves all incident information, such as the activity log.

Automated investigation and response (AIR) investigates alerts and proposes or takes remediation actions, and the Action center is where every pending and completed action is approved, audited and undone.

The September 2026 change

As of 1 September 2026, AIR no longer runs as a separate investigation experience, and can no longer be triggered manually, for Defender for Endpoint alerts. Its detection and response capabilities run automatically in Defender for Endpoint's default antivirus protection stack; for an on-demand check Microsoft recommends a full antivirus scan. The change applies only to Defender for Endpoint: Defender for Office 365 AIR remains available. Device group automation levels still exist (they also govern attack disruption), and the Action center still lists device actions, including antivirus and attack disruption actions.

Pending and History

• Pending lists actions awaiting approval. Approve or reject one at a time, or several of the same type together. Reject applies only to actions still pending.
• History is the audit log of actions taken (automated, approved, manual, live response and antivirus actions) and is where you undo certain completed actions. Undoing a Quarantine file action can be applied to all other instances of the file at once. An allow indicator only prevents future detections; it doesn't restore copies already quarantined.

Email remediation always waits for approval

No remediation action on email and collaboration content is taken automatically. When a Defender for Office 365 Plan 2 investigation recommends soft-deleting messages, the action waits on the Pending tab until someone approves it, and an action nobody approves never runs.

Permissions for Action center tasks

The Security Administrator role group in Email & collaboration permissions doesn't include Search and Purge and doesn't grant Action center access by itself; Security Operator doesn't add Search and Purge either.

Automatic attack disruption is a built-in Defender XDR capability that, during an attack in progress such as ransomware or business email compromise, identifies the compromised assets in a high-confidence incident and contains them automatically. It differs from other automation in three ways: it evaluates the whole incident (signals correlated from endpoints, identities, email and SaaS apps) rather than one indicator; it needs no rules, playbooks or queries from the SOC; and Microsoft maintains its detectors at very high precision before they act.

Its response actions include:

• Contain device and Contain IP (Defender for Endpoint applies a policy on all onboarded devices that blocks communication from the device or from an IP of an undiscovered device), and automatic Isolate device for an onboarded device identified as an active foothold;
• Contain user (Defender for Endpoint blocks the user's communication from onboarded devices);
• Disable user (Defender for Identity: through its sensors for on-premises Active Directory accounts, and for cloud-only Microsoft Entra ID accounts through a Microsoft-managed enterprise app named Microsoft Defender for Identity, so those need no sensor deployed), Revoke user session and Suspend user in Entra;
• protective measures for a compromised OAuth app (Defender for Cloud Apps), plus preview actions in Okta and AWS through Microsoft Sentinel connectors.

Disrupted incidents carry an Attack Disruption tag and a yellow banner, the contained asset's status shows in the incident graph, and each action is added to the Action center. Every automatic action can be undone: once an investigation shows activity was legitimate, an analyst releases the asset (for example re-enables a contained user) from the action details pane in the Action center. The Action center is where a completed containment is reversed.

Attack disruption works only where each Defender product it relies on is deployed and configured: a product must be deployed to run its own response actions, and its signals must be present for the attack scenario to be detected. Beyond a qualifying licence (for example Microsoft 365 E5), the per-product requirements are:

Each requirement belongs to one product and enables only that product's part of disruption. Disabling a cloud-only Entra ID account runs through the Microsoft-managed Defender for Identity app rather than domain controller sensors. Configuring disruption needs a role such as Security Administrator or Security Operator. Also check for in-house automation that re-enables accounts, which can undo a disable while the attack is still active.

Exclusions, under Settings > Microsoft Defender XDR > Automated response, stop attack disruption from acting on chosen assets while it keeps protecting everything else. Microsoft states that excluding assets from automated responses isn't recommended, so exclude only what a business reason requires. Pick the exclusion by what must be spared:

The key near-twin: Semi automation levels do not exclude a group; Semi still lets attack disruption act without manual approval. Only No automated response excludes the group, and it also stops AIR actions for it. Exclusions affect future actions only; a containment already applied is released from the Action center. Removing an exclusion puts the asset back in scope. Managing exclusions needs Security Administrator (or Security Operator / Core security settings (manage) with Unified RBAC); Security Reader can view them only.