Ransomware operators and business email compromise crews move fast, often when nobody is watching. Automatic attack disruption is Microsoft Defender XDR's answer: when it is highly confident an attack is in progress, it contains the devices, accounts and IP addresses the attacker is using without waiting for an analyst. In this post I'll explain how it decides, what each action does, what you must configure so it can act, and how your team reviews and reverses its work.
Status (October 2026): Microsoft Learn lists the Microsoft Entra ID and Active Directory actions as generally available, while automatic device isolation and the Okta and AWS IAM actions are in preview. The action list keeps growing, so re-check the Learn pages before you plan.
How it works#
Attack disruption works at incident level rather than on a single indicator, in three stages:
- Correlate: signals from endpoints, identities, email, collaboration tools and SaaS apps are combined into one high-confidence incident.
- Identify: Defender works out which assets the attacker controls and is using to spread.
- Contain: it takes response actions in the relevant Defender product, in real time.
The classic targets are human-operated ransomware, business email compromise (BEC) and adversary-in-the-middle (AiTM) phishing, and the action list now covers compromised OAuth apps too. Microsoft states that it maintains 99% or higher confidence for containment actions, based on production data, that new detectors run in audit mode before release, and that every automatic action can be undone.
The actions it can take#
| Action | Delivered by | Effect |
|---|---|---|
| Contain device | Defender for Endpoint | All onboarded devices block communication from the compromised device |
| Contain IP | Defender for Endpoint | The same for an IP address used by an undiscovered or non-onboarded device |
| Isolate device (preview) | Defender for Endpoint | Takes an onboarded workstation used as a foothold off the network, keeping its link to Defender services; undone automatically after a set period |
| Contain user | Defender for Endpoint | Onboarded devices block the account's authentication, file access and network paths, limiting lateral movement and remote encryption |
| Disable user | Defender for Identity | Disables the account so it can't sign in |
| Revoke user session, Suspend user in Entra | Microsoft Entra ID | Ends active sessions and blocks further access |
| OAuth app compromise | Defender for Cloud Apps | Protective measures against a compromised OAuth app |
| Suspend Okta user, deny policy on AWS IAM user or role (preview) | Microsoft Sentinel connectors | Contains identities outside Microsoft's cloud |
Disable user depends on where the account lives. Active Directory accounts are disabled through domain controllers running the Defender for Identity sensor, and for synced accounts the Microsoft Entra ID object is disabled as well. Cloud-only accounts are disabled through a Microsoft-managed enterprise application named Microsoft Defender for Identity (application ID 60ca1954-583c-4d1f-86de-39d835f3e452, shown as Radius Aad Syncer in some older tenants), so leave it alone during app clean-ups.
Learn also lists predictive shielding actions that act before an incident escalates: Safe Mode and Group Policy hardening on devices, and proactive containment of high-risk users, which blocks new sessions rather than ending existing ones.
Preparing your tenant#
Licensing#
You need Microsoft 365 E5 or A5, or Microsoft 365 E3 with the Microsoft Defender Suite or Enterprise Mobility + Security E5 add-on; the configure page lists every qualifying combination. Each action also needs its workload deployed and healthy: without Defender for Identity sensors, AD-only accounts can't be disabled automatically.
Defender for Endpoint#
- Sensor version: Contain user needs Sense client 10.8470 or later.
- Device group automation: in Settings › Endpoints › Device groups, Microsoft recommends Full - remediate threats automatically. Groups set to No automated response are excluded from automatic containment.
- Device discovery: use at least Standard discovery so unmanaged devices can be found and contained.
Defender for Identity#
Run sensors on every domain controller with the auditing Defender for Identity requires. Remediation runs as the domain controller's LocalSystem account by default; if you configured a gMSA action account instead, make sure it may disable users.
Defender for Office 365 and Defender for Cloud Apps#
Keep mailboxes in Exchange Online with mailbox auditing on, and Safe Links enabled, for example through the Standard or Strict preset policies. In Defender for Cloud Apps, connect the Microsoft 365 app connector and turn on app governance for OAuth app scenarios.
Exclusions: use them sparingly#
- Users: Settings › Microsoft Defender XDR › Automated response › Identities › Add user exclusion, select the accounts, then Exclude users.
- Devices: set the device group's automation level to No automated response. That also stops automated investigation remediating those devices, so keep such groups small; see my post on AIR automation levels and device groups.
- IP addresses: single IPs and ranges, for example critical infrastructure, can be excluded from containment.
Microsoft advises against exclusions. Emergency access and critical service accounts are reasonable candidates, but an excluded account is attractive to attackers, so alert on its sign-ins.
When it fires: review and undo#
A disrupted incident carries the Attack Disruption tag in the queue and a yellow banner on the incident page, and the incident graph shows each asset's state, such as account disabled or device contained. The Policy status column (preview) on the Activities tab, filtered to provider Attack disruption, shows whether each policy is still active. Through the API, the incident title ends with (attack disruption).
- Investigate first. Disruption buys time; it doesn't replace incident response, remove persistence or reset credentials.
- Find the actions under Actions & submissions › Action center › History.
- When the asset is clean, select the action and choose Undo. A contained device can also be released from its device page.
- Re-enable synced accounts in Active Directory (or with Undo), not only in Entra ID; the next sync overwrites a cloud-only change.
Set up email notifications for response actions, and brief the service desk not to re-enable disabled accounts on request.
Verify you're ready#
Find Windows devices whose sensor is too old for Contain user:
DeviceInfo
| where Timestamp > ago(1d) and OSPlatform startswith "Windows"
| summarize arg_max(Timestamp, ClientVersion) by DeviceId, DeviceName
| where toint(tostring(split(ClientVersion, ".")[1])) < 8470
| project DeviceName, ClientVersionConfirm mailbox auditing isn't switched off for the organisation; False is what you want:
Connect-ExchangeOnline
Get-OrganizationConfig | Format-List AuditDisabledThen check the portal: no unexpected device groups on No automated response, device discovery on Standard, Defender for Identity sensors healthy and the Microsoft 365 connector connected.
Tips & gotchas#
- It acts only on high-confidence incidents, so most incidents never show the tag. Silence doesn't mean it's broken.
- Write a short runbook for "yellow banner" incidents: who investigates, who approves an undo and who tells the user.

