Whenever automatic attack disruption comes up in Microsoft Defender XDR projects, I still notice a fair amount of uncertainty. Most admin teams have heard of "contain device" or "disable user" automations, yet few have actually rolled them out. That's a pity, because human-operated ransomware, business email compromise (BEC) and phishing techniques such as AiTM are on the rise, and these built-in countermeasures can decide whether an incident stays contained or turns into a widespread breach. Even experienced security teams are often surprised how well the XDR components now work together to stop an attack mid-flight, provided everything is configured correctly.

Defender XDR stops high-confidence attacks while they are still running

The idea behind automatic attack disruption is to stop high-confidence attacks while they are still in progress rather than cleaning up afterwards. Defender XDR correlates signals from endpoints, the identity infrastructure and email. Once it recognizes the typical patterns of spreading human-operated ransomware, business email compromise, AiTM phishing or large-scale password spray, it acts right away. It isolates compromised endpoints, disables user accounts in Entra ID or Active Directory and revokes live sessions. The official documentation covers these scenarios in detail. Still, you only get a feel for what it can do (and for its operational quirks) when you watch it fire in a real tenant.

I've seen Defender XDR quarantine devices, disable on-prem or cloud accounts and terminate sessions within a few minutes. One thing you need to understand, though. These actions are triggered only by "high-confidence" detections, usually after several signals have been correlated, and not by every suspicious alert.

Four Defender workloads have to be in place first

Automatic attack disruption only behaves as intended if several Defender workloads are licensed, deployed and properly integrated in the tenant. You need:

  • Microsoft Defender for Endpoint on all endpoints, with block mode enabled and automated investigation turned on
  • Defender for Identity (sensors on all domain controllers, action account set up with correct permissions)
  • Defender for Office 365 (Plan 2, for email and BEC detection)
  • Defender for Cloud Apps (connectors for Entra ID and Exchange Online configured)

If part of this stack is missing, some actions, such as disabling users or isolating devices, will simply fail. Read the setup guide carefully, especially the section on the Defender for Identity action account, because that's where first deployments tend to stumble. I've come across environments where one misconfigured sensor or an expired password on the action account meant not a single user could be disabled during an attack.

Tip from practice: Check regularly that Defender for Identity monitors every domain controller, and make sure your action account is excluded from password expiry and lockout policies. One missing sensor can be enough for nobody to get blocked at exactly the moment it counts.

In hybrid or legacy environments I test the integration step by step. For example, I simulate a compromised test user and watch whether the right automated actions kick in.

Every automated action follows detection and correlation

The following diagram shows in simple terms how Defender XDR gets from detection to containment:

flowchart TD
    Attack["Attack detected"] --> Correlate["Signals correlate"]
    Correlate --> HighConf["High-confidence detection"]
    HighConf --> Action["Automated response"]
    Action --> ContainDevice["Contain device"]
    Action --> DisableUser["Disable user"]
    Action --> RevokeSession["Revoke sessions"]
    Action --> NotifyAdmin["Notify admin"]

Figure: The usual sequence of automatic attack disruption in Defender XDR.

Once an action has run, it shows up in the Action Center (Microsoft Defender portal → Actions) along with what was done, which user or device was affected and what the result was. The same actions appear on the related incident page. From there you can also roll them back, for instance unlocking a user or releasing a contained endpoint, if the response turned out to be unnecessary or hit a critical account. In my experience, this fast containment gives the security team the few extra minutes it needs to investigate and respond.

Break-glass and critical accounts can be excluded

A concern I hear often is that automatic containment might disable an emergency admin account, or the CFO's account at a sensitive moment. Defender XDR lets you exclude specific users from these automated actions under Settings → Microsoft Defender XDR → "Identity automated response". That's where genuine break-glass accounts or high-value service accounts belong, the ones that must never be blocked automatically. Don't get carried away, though. Many tenants I look at have far too many exclusions, which defeats much of the purpose. Keep the list as short as possible (ideally two break-glass accounts) and revisit it whenever your admin team changes.

If you want to see which accounts are currently excluded from automatic disablement, you'll find that list in the same XDR settings. Review it periodically so nothing ends up exposed by accident.

The automation is only as strong as its setup

Automatic attack disruption brings Defender XDR a lot closer to genuine autonomous defense, but only if you've set up all the moving parts and keep them maintained. It's most useful in combination with Defender XDR's unified incidents. The system can isolate a compromised device, disable the identity the attacker is using and revoke all active sessions before lateral movement gets going. Based on my projects, my main advice is to spend time verifying the sensors, testing the action account and keeping the exclusion list short. If you'd like the bigger picture of how incidents, automation and hunting fit together, have a look at my earlier post on getting started with Microsoft Defender XDR.

Automation like this won't replace security awareness or a proper IR process. It may, however, give you the few minutes that decide whether you contain an attack or not.