EDR isolates the device on its own; the rule that brings it back is written beforehand

On 3 September at 20:19 UTC, somebody at Microsoft added a sentence to the Defender for Endpoint documentation. By 4 September at 19:06 UTC it was gone. It lived for less than a day and it read: "This issue can also occur when device isolation is triggered as full isolation by automatic attack disruption. To have automatic attack disruption use selective isolation, define an isolation exclusion rule."

The public repository where Microsoft writes that documentation tells the story: one commit puts it in on the 3rd, and the next commit that touches the file — titled "Resolve syncing conflicts from repo_sync_working_branch to public" — leaves it out. We do not know whether it was pulled on purpose or lost in a sync, and we are not going to pretend we do. What we can check is that the two facts that sentence joined are both still published, each in a different place, and that joining them is now your job.

A note on vocabulary before we go on, because the product is called one thing and everyone calls it another. The feature is called attack disruption, and it does several different things. The two that concern us here are contain and isolate, which are not synonyms and on whose difference the rest of this article depends.

Where the wall lives when you "contain" a device

Isolating acts on the device: it cuts its network from the inside, while keeping connectivity to required security services. Containing does the opposite of what its name suggests. The documentation describes the action for an unmanaged device that is or might be compromised, and says: "When you contain a device, all Defender for Endpoint onboarded devices block incoming and outgoing communication with that device." The policy is applied on the other machines.

Three practical things follow, two written down and one ours. The written ones: it can take up to five minutes for the details of a newly contained device to reach the rest of the onboarded estate, and Microsoft recommends staying under one hundred contained devices at a time because of possible performance issues on the devices doing the blocking. Ours, flagged as an inference: if the wall lives on the other machines, anything not onboarded — the hypervisor, the storage array, the NAS, the switch, the printer, the Linux box nobody remembers — keeps talking to the contained device exactly as it did yesterday.

That inference is what turns a security decision into an inventory job, and inventory has a trap that has already bitten us: an agent can show green in the console having sent no telemetry for weeks. A device listed as onboarded but not actually onboarded blocks nothing, and still counts towards your coverage figure.

What gets isolated on its own is end-user workstations

The objection we usually get in meetings is "I do not want an AI disconnecting my file server." That specific thing does not happen. Two separate pages say it in the same words: "Automatic device isolation works only on end-user workstations that are onboarded and managed by Microsoft Defender for Endpoint." End-user workstations, onboarded and managed. Both pages also mark automatic isolation as preview, which matters for planning: we pilot a preview feature on a small group and document it as reversible.

Critical servers get the other thing. The section on containing critical assets says that "Device containment supports critical asset types like domain controllers, DNS servers, and DHCP servers" and that there containment "blocks only specific ports and communication directions", with the stated goal of keeping the asset running. The domain controller does not lose the network: it loses a very specific slice of it.

The two facts the deleted sentence joined

The first has been published for a while and is still there today, in the list of points to keep in mind about isolation. We quote it in full, because the second half qualifies the first and leaving it out would be cheating: "In environments that use web proxies (including Proxy Auto Configuration (PAC), WPAD, or static/direct proxy configurations), devices might not be able to recover from network isolation. Use selective isolation in such cases. When using selective isolation, exclusion settings aren't required to avoid this scenario."

Read that way, for manual isolation the problem is solved: you pick the mode, you pick selective, and you do not even need exclusion rules. The second fact sits in another section, the one about automatic isolation, and it is a note: "When an isolation exclusion rule is defined, automatic attack disruption uses selective isolation by default and isolates the device according to the configured isolation exclusion rules."

Two more things about those rules are worth knowing before you flip the switch. One, isolation exclusion rules are defined under Settings > Endpoints > Advanced features > Isolation Exclusion Rules, and enabling the feature means the embedded exclusions for Microsoft Teams, Outlook and Skype no longer apply, and the list starts empty on every platform (Skype, the documentation notes, is deprecated and no longer included in any default exclusions). If you want Teams and Outlook to keep working during an isolation, you write them in.

And two, the limitation that decides when this work is worth anything: "Changes to exclusion rules only impact new isolation requests. Devices that were already isolated remain with the exclusions that were defined when they were applied." With the device already isolated, applying a new rule means releasing it and isolating it again. With the incident under way, the lever does not move.

An honest limit to all of the above: the documentation says that "Exclusions, such as e-mail, messaging application, and other applications for both macOS and Linux isolation aren't supported", and selective isolation is available on Windows, Azure Stack HCI and macOS. So "write the rule beforehand" covers the Windows part of the estate and leaves Linux out. If you have onboarded Linux endpoints, that piece of the plan has to be solved another way.

The way back, point by point

The outbound action fires on its own, in seconds. Coming back is scattered across several sections of the documentation and, lined up, it reads differently:

• Releasing the device is manual, from the portal, with Release from isolation. To use the isolation feature the documentation asks for at least the Active remediation actions role and access to the device according to device group settings.
• If nobody releases it there is a clock, but not the same one in both cases. Manual isolation is lifted after seven days. For isolation triggered by attack disruption the documentation only says "after a defined time window", without giving the figure. For a user contained by attack disruption it does give one: five days.
• If the device stops responding while isolated, there is a force-release script with three conditions: you download it from that device's page, it expires in three days, and it only works on Windows with specific versions and KBs. It is run by admins or by whoever holds the manage-security-settings permission, which is not exactly the same permission as releasing from the portal.
• On Linux the risk runs the other way: an isolated device comes out of isolation as soon as an administrator modifies or adds an iptables rule. The command a colleague runs to help takes the containment down without anyone deciding to.
• An isolated device behind a full VPN tunnel cannot reach the Defender cloud service. The written recommendation is split tunnelling for Defender for Endpoint and antivirus cloud-protection traffic.

Two side effects that do not show up in the demo

The first is for anyone virtualising on Windows: "Isolating a server running on Microsoft Hyper-V blocks network traffic to all child virtual machines of the server." Isolating a Hyper-V host takes the network away from all of its virtual machines. This is manual isolation, and even so it describes precisely the mistake made at three in the morning: a name on a list does not tell you what is inside. It belongs to the same family as redundancy that does not survive the procedure.

The second is for whoever watches the directory. Containing a user is enforced at the endpoint and does not disable the account in the identity provider: it blocks incoming traffic on attack-related protocols — network logons, RPC, SMB, RDP — ends ongoing remote sessions and logs off existing RDP connections. The note flagged as important comes next: "Once a Contain user action is enforced on a domain controller, it starts a GPO update on the Default Domain Controller policy", and that change starts a sync across the domain controllers. Undoing the action reverts the GPO and starts another. Anyone monitoring GPO changes will get alerts about the automated response in the very system they planned to investigate it with.

Three levers for excluding, and the one almost nobody touches

This is where most people reach for the wrong tool, us included the first time. The exclusions page offers exclusions for user accounts, IP ranges and device groups, and opens with a CAUTION notice: "Excluding assets from automated responses isn't recommended." But the device group selector does not have two positions, it has five: Full, three Semi variants that still investigate automatically and only require approval to remediate, and No automated response. The warning that excluding a group "also impacts automated investigation and response actions" really bites at that last step.

And there is a third lever, in preview, that almost nobody touches because it lives on another tab of the portal: policy applications and exclusions. You create a device tag — with dynamic rules based on device type, operating system or other properties — create a rule for that tag, and disable only the controls you want. The documentation has a section dedicated to excluding just the Isolate device action for a tag: the rest of attack disruption keeps working, and when the system identifies an excluded device as compromised, the action shows with a Skipped status in the Action center. The stated goal is "Keep most disruption controls active while selectively disabling specific protections."

Our recommendation, offered as opinion and with the source in plain view arguing the other way: Microsoft suggests "using automatic attack disruption exclusions to reduce the likelihood of isolating devices that can't tolerate interruption", while also advising against excluding in general. Both sentences coexist because they are about different granularities. We prefer the tag and the per-action exclusion over turning down the automation level of a whole group: the first is paid once, when you configure it, and the second is paid in visibility every day of the year. And switching it all off is a support request: you open a case in the Defender portal with the subject Attack disruption opt-out and explain why.

Seven questions before you switch it on

This is what we go through. It orders what Microsoft's documentation has scattered, so you can answer it in a half-hour meeting:

1. What automation level does each device group have, today, looking at it? Under Settings > Microsoft Defender XDR > Automated responses > Devices, groups tab. Nobody remembers from memory what they set two years ago.
2. Does the estate use PAC, WPAD or a static proxy? If so, the isolation exclusion rule stops being optional for Windows endpoints.
3. How many Linux endpoints are onboarded? For those, isolation exclusions are not supported and the plan has to be different.
4. Is the VPN full tunnel? Then the decision comes earlier: split tunnelling for Defender traffic, or accept that an isolated device does not talk to the cloud.
5. If we enable isolation exclusions, who rewrites the Teams and Outlook rules, and when? The list starts empty.
6. What share of the estate is genuinely onboarded, and what is on the list of what is not? That is where containment has holes, and that list is almost never written down.
7. Who can release a device out of hours, and does the monitoring team know that containing a user on a domain controller generates a GPO change and its sync?

All seven are operational questions, which is why they fall between chairs: whoever buys the licence does not know them, and whoever answers at dawn was not in the purchase meeting. It is the same crack we described writing about the continuity plan nobody has rehearsed: the document exists, the chain of decisions does not.

What the 99% actually says

Microsoft publishes a figure about attack disruption, and publishes it plainly: "For containment actions, Defender maintains a confidence level of 99% or higher based on real production data." That is detector precision, measured as signal-to-noise ratio, and it comes with the detail that detectors are validated in audit mode first and rolled out gradually. We think it is an honest number and we have no reason to argue with it.

What that 99% does not say is how often it will fire on your estate in a year. Nobody publishes that rate, and it cannot be derived from detector precision either: the two are measured differently. So the argument about whether you trust the model, whatever the answer, leaves untouched the question that actually costs money on the day: how the machine comes back, who brings it back, and under which written rule.

We like attack disruption and we are not going to pretend otherwise for a spicier article. In a ransomware case, the minutes a person takes to notice, understand and act are the same minutes between a compromised device and an encrypted folder. The feature does its job well. The field for who holds the role at three on a Saturday is one you fill in.

If you would rather start with the basics, the door is the usual one: knowing what is on your network and what is genuinely protected. That is what our cybersecurity practice is about, and no automated response makes up for not having it.

Note on sources

Two groups of citations need to be kept apart. First, the headline sentence, which is NOT published today: the text "This issue can also occur when device isolation is triggered as full isolation by automatic attack disruption. To have automatic attack disruption use selective isolation, define an isolation exclusion rule" was added to defender-endpoint/respond-machine-alerts.md in the public repository MicrosoftDocs/defender-docs in commit f2685dde ("Update respond-machine-alerts.md", 3 September 2026, 20:19 UTC) and does not appear in the next commit touching that file, 2f51dff1 ("Resolve syncing conflicts from repo_sync_working_branch to public", 4 September 2026, 19:06 UTC); nor is it in the version published today, which we downloaded and checked. Whether the reason was a sync slip or a decision, we do not know, and we say so. Second, everything else, which is published today and which we read on 15 September 2026 in that same repository: the 99% and audit mode, the CAUTION notice about excluding assets, the five automation levels, the warning about automated investigation, the preview policy applications and exclusions, and the opt-out procedure with the subject Attack disruption opt-out are in Automatic attack disruption in Microsoft Defender and Exclude assets from automated response in attack disruption; the end-user workstation note, containment of critical assets, the behaviour of Contain device, the five minutes, the hundred devices, the seven days of manual isolation, the five days of user containment, the three-day script, the iptables behaviour on Linux, the full-tunnel VPN, the effect on a Hyper-V host's virtual machines, the GPO note, the unsupported exclusions on macOS and Linux, the note about selective isolation by default and the per-tag exclusion of the Isolate device action are in Take response actions on a device in Microsoft Defender for Endpoint; the two isolation modes, the path to the rules, the emptying of the Teams, Outlook and Skype exclusions and the limitation that changes only affect new requests are in Network isolation exclusions in Microsoft Defender for Endpoint; and the preview marking of automatic isolation appears both in Take response actions on a device in Microsoft Defender for Endpoint and in Configure automatic attack disruption in Microsoft Defender XDR. What is our own inference in this article is marked as such: that anything not onboarded keeps talking to a contained device, and our preference for per-tag exclusion over turning down a whole group. We found no published figure for how often attack disruption fires across an estate, which is why we give none.