Microsoft continues to evolve Automatic Attack Disruption in Microsoft Defender XDR, moving security operations beyond detection toward automatically interrupting attacks while they are still in progress.

Until now, Attack Disruption could contain suspicious or compromised devices discovered in the network. This containment action instructs Microsoft Defender for Endpoint (MDE)-onboarded devices to block communication with the contained device, helping prevent an attacker from using it to move laterally toward protected endpoints.

However, this is different from device isolation. With containment, the suspicious device itself is not necessarily isolated from the network; instead, MDE-onboarded devices enforce the communication restrictions around it.

What Attack Disruption did not previously do was automatically isolate an MDE-onboarded endpoint identified as an active foothold in an attack. Isolating such a device required a separate response action.

Until now, Microsoft has introduced Automatic Device Isolation in Attack Disruption. When Defender XDR identifies an eligible MDE-onboarded and managed endpoint in the compromised foothold, it can automatically isolate the device, without any manual initiation of the isolation.

NOTE: The feature is currently in preview (09-09-2026)

From detection to disruption

A “traditional” SOC response often looks something like this:

Detect → Alert → Investigate → Respond

The biggest issue with this approach is that attackers don’t wait for the SOC. Attacks can happen 24/7, and even a 15-minute response window can give an attacker enough time to cause significant damage.

Once an endpoint has been compromised, an attacker can begin credential discovery, lateral movement, command-and-control activity, data collection, exfiltration, or ransomware deployment while the investigation is still taking place.

What happens during Device Isolation?

When Automatic Attack Disruption determines that an eligible endpoint should be isolated, Microsoft Defender for Endpoint disconnects the compromised device from the network. This doesn’t mean Defender simply disables the network adapter and loses visibility into the machine.

The isolated device retains connectivity to the Microsoft Defender for Endpoint service, allowing Defender to continue monitoring the endpoint. This can help prevent the compromised endpoint from being used for:

  • Lateral movement
  • Communication with attacker-controlled infrastructure
  • Data exfiltration
  • Ransomware propagation
  • Further attack activity against other systems

Containment vs. Isolation

One of the most important concepts to understand is that device containment and device isolation aren’t the same thing. They sound similar, but technically they solve different problems.

Contain Device

Containment is particularly useful when Defender discovers a suspicious or compromised unmanaged device in the network. The device itself isn’t onboarded to Defender for Endpoint, but it can still be discovered through signals and device discovery capabilities available within the Defender ecosystem.

For example, this device is: TESTDEVICE1

The device isn’t onboarded into MDE, so Defender can’t necessarily execute an endpoint response directly on it; there is no control or installed sensor. What Microsoft does is the following.

It tells all the onboarded MDE devices that device TESTDEVICE1 is potentially malicious, and the onboarded devices need to stop communicating with this device.

More information (blog): Automatic attack disruption in Microsoft Defender XDR and containing users during Human-operated Attacks

All Defender for Endpoint-onboarded devices block incoming and outgoing communication with the contained device, since the contained device is part of the local policy set of the machines. The important difference with an isolated action is where the enforcement occurs. The MDE-onboarded endpoints enforce the containment.

Containment protects your managed endpoints FROM a suspicious device.

Isolate device

Device isolation approaches the problem from a different direction. With this approach, the device is onboarded to Defender for Endpoint. Instead of telling other endpoints not to communicate with it, Defender applies isolation directly to the compromised endpoint via the SENSE and the automation IR service.

Isolation restricts the compromised managed endpoint ITSELF.

Why Automatic Isolation changes Attack Disruption

Manual device isolation isn’t new. SOC analysts/ Security admins have been able to isolate devices from the Microsoft Defender portal for years via the isolate device action feature.

The important change is who initiates the action and when.

Previously: (example flow)

  1. Attack detected
  2. Incident generated
  3. Analyst investigates
  4. Analyst determines device is compromised
  5. Analyst selects “Isolate device”

With Automatic Device Isolation: (example flow)

  1. Attack detected
  2. Incident generated
  3. Defender correlates attack signals
  4. Compromised endpoint identified
  5. Attack disruption automatically isolates devices
  6. Analyst investigates

That removes potentially critical minutes between identifying an active attack and restricting the compromised endpoint. This is exactly where automated response can provide value. The goal isn’t to replace the SOC analyst.

The goal is to limit what the attacker can do while the SOC analyst investigates further.

Safeguards and business impact

Automatically disconnecting an endpoint from the network is a powerful response action, but it can also have significant business impact. For that reason, Microsoft has implemented several safeguards around Automatic Device Isolation

Scoped

Microsoft has therefore implemented several safeguards around Automatic Device Isolation. Isolation targets specific devices involved in the incident rather than broadly isolating devices across the environment.

Time-limited

Device isolation isn’t intended to remain indefinitely. Microsoft documents isolation as a time-limited action and allows security operations to release a device earlier after investigation and remediation. The analyst can review what happened, validate the disruption, and release from isolation.

What happens after Attack Disruption?

Automatic isolation doesn’t mean the incident is resolved. To be clear, isolation is not a full remediation.

The attacker’s network access may have been interrupted, but the endpoint could still contain:

  • Malware
  • Persistence mechanisms
  • Malicious scheduled tasks
  • Stolen credentials
  • Web shells or backdoors
  • Malicious tools
  • Modified configuration
  • Other attacker artifacts

Before releasing the endpoint, the SOC should determine what happened and whether the threat has actually been remediated.

Questions should include:

  • How did the attacker compromise the endpoint?
  • What was executed?
  • Were credentials accessed or dumped?
  • Was persistence established?
  • Did lateral movement occur before isolation?
  • Were other identities or endpoints compromised?
  • Was data accessed or exfiltrated?
  • And many more items

Once the threat has been investigated and remediated, the analyst can use Release from isolation to restore network connectivity.

What about business-critical devices and exclusions?

Microsoft supports Automatic Attack Disruption exclusions, which can prevent specific devices or entities from being subjected to automatic disruption actions. Be careful when specifying exclusions, since any exclusions are a cap. And the most critical devices are the most likely to be targeted.

When configuring automatic device isolation, there are two important types of exclusions to consider:

Selective isolation exclusions determine what remains accessible after a device has been isolated. They allow specific processes and network destinations to continue communicating, helping maintain access to critical services such as management tools and essential business applications.

Automatic attack disruption exclusions, on the other hand, prevent selected devices or entities from being targeted by automatic disruption actions altogether. These exclusions are useful for business-critical systems where automatic isolation could have an unacceptable operational impact.

Via Device automated and response Policy application it is possible to define specific exclusions without the need to completely exclude a device group. Another method is to exclude the IP or Device group.

Specification for each disruption action:

The key distinction is simple: selective isolation exclusions control what an isolated device can still access, while automatic attack disruption exclusions can prevent the device from being automatically isolated in the first place.

More information: Exclude assets from automated response in attack disruption – Microsoft Defender XDR | Microsoft Learn

Simulation and alerts

Now it is time to put Automatic Device Isolation to the test and see how it behaves during an actual attack simulation.

To trigger Attack Disruption, we first need to generate enough malicious activity on the endpoint for Defender XDR to correlate the individual signals, recognize the broader attack, and identify the device as a compromised foothold.

For this simulation, I generated a mix of malicious and suspicious activity, including ClickFix activity, AMSI tampering, PowerNet malware, living-off-the-land binary (LOLBin) abuse, masqueraded scheduled tasks and services, and several other techniques like human-operated activity.

The goal here is not simply to generate a single Defender for Endpoint alert. We want to create an attack chain with enough high-confidence signals for Defender XDR Attack Disruption to kick in and, ultimately, automatically isolate the compromised device.

After generating the malicious activity, Defender started correlating the individual signals into the broader incident. Some of the resulting alerts included:

  • “Compromised account conducting hands-on-keyboard attack
  • “Lateral movement using RDP blocked”
  • Compromised device (attack disruption)

After some time Microsoft detected and performed the automated Attack Disruption response action. This is visible via the portal in the header and the Disruption action taken summary:

When opening the Activities tab, you can view all items related to the incident, from the first alerts to the increase and enforcement of Attack Disruption:

It all started with alerts and the first “Contain User” activity:

More alerts, and Microsoft isolated the device via Attack Disruption:

VM-win11-pc2 isolated:

Microsoft created an alert: Compromised device (attack disruption)

And there it is: automated response took place.

Defender XDR correlated the malicious activity and automatically initiated Attack Disruption. The incident summary shows the impact:

  • 1 compromised account contained
  • 2 sign-ins blocked
  • 1 device automatically isolated
  • 1 device saved from the intended impact

The most interesting result for this test is Devices: Isolated 1. Defender identified the compromised endpoint as part of the active attack and automatically isolated it, without requiring an analyst to manually initiate the action.

At the same time, Attack Disruption contained the compromised identity and blocked sign-ins.

This is Attack Disruption doing exactly what we wanted to test: not just detecting the attack, but actively disrupting it across identity and endpoint signals.

Another method is to view the Attack Disruption tenant-wide is via Actions & submissions -> History or via the direct link: https://security.microsoft.com/action-center/history

Final thoughts

Automatic Device Isolation is a logical and powerful addition to Attack Disruption. Device isolation itself isn’t new, but automatically initiating the action when Defender XDR identifies a compromised endpoint as part of an active attack changes the response flow significantly.

The lab simulation showed exactly that. Defender didn’t just generate alerts. Attack Disruption correlated the activity, contained the compromised identity, blocked sign-ins, and automatically isolated the compromised endpoint without requiring manual intervention

And that is the value of Attack Disruption: reducing the time an attacker has to operate while giving the SOC time to investigate and remediate the incident. Detection tells you something happened. Disruption tries to stop what happens next.

Sources

Microsoft: Take response actions on a device in Microsoft Defender for Endpoint – Microsoft Defender for Endpoint | Microsoft Learn

Jeffreyappel.nl: Configure automatic Attack Disruption in Microsoft Defender XDR

Jeffreyappel.nl: Automatic attack disruption in Microsoft Defender XDR and containing users during Human-operated Attacks