Defender’s Auto-Isolate Preview: What Changes When ‘Contain’ Becomes ‘Isolate’

By AutoCypher · 1 day ago 26 May 2026

BleepingComputer ran a piece on May 26 titled “Microsoft Defender can now automatically isolate hacked endpoints,” which is accurate but elides the distinction defenders need to make before turning this on. Automatic isolation in Defender already existed — it just used a different mechanism (Device contain) and operated through Defender-onboarded peer devices rather than enforcing at the compromised host itself. What’s new in the May 2026 Preview is Isolate device as an automatic-attack-disruption action, which enforces full network isolation at the device, not at the neighbors.

The two controls do different things, run on different mechanisms, and break different attack stages. The headline blurs them. The Microsoft Learn docs (updated May 17 and May 20, 2026) do not, and the deployment decision needs the docs’ framing, not the headline’s.

This post walks the actual distinction, the confidence threshold Microsoft is claiming for the automation, the scoping rules, and what defenders should wire up before enabling the Preview in their tenants. Standard scope caveat: this is defender-side analysis of a published Microsoft Preview feature against your own infrastructure, not an evasion or operator post.

Device contain vs Isolate device — the distinction the BleepingComputer piece glosses

Microsoft’s automatic attack disruption stack has had a containment action firing automatically since the original October 2023 launch. That action is Device contain: when Defender for Endpoint identifies a device with high confidence as actively used by an attacker, every other Defender-onboarded device in the tenant starts blocking incoming and outgoing communication with the suspect host. The block is enforced peer-to-peer through the broader fleet. The suspect device itself isn’t doing the blocking — its neighbors are. This is also why Device contain works against unmanaged or undiscovered devices: it doesn’t need an agent on the suspect host.

The new Preview action is Isolate device – automatic attack disruption, which works the opposite way. The agent on the compromised device itself drops the host into network isolation, blocking essentially all traffic except the EDR control plane back to Microsoft Defender for Endpoint. The Microsoft Learn page for respond-machine-alerts (the same page that’s documented manual isolation since 2017) added a new section for the automatic variant, currently flagged Preview, that explicitly only works on end-user workstations onboarded and managed by Defender for Endpoint.

Three operational consequences of that difference matter for the deployment decision:

First, Isolate device requires an agent on the suspect host. Device contain doesn’t. If your IOT and OT segments are full of unmanaged hosts (and they are), the Preview’s Isolate action does nothing there — Device contain still does. Both controls coexist in the disruption stack; flipping on the new one doesn’t replace the old one.

Second, Isolate device enforces at the kernel/networking layer of the host. Device contain enforces at the peer Defender agents’ firewalls. The Isolate posture is materially stronger for east-west blast radius because it doesn’t depend on which other tenant devices have been onboarded — a compromised laptop on a coffee-shop network with no Defender peers nearby still gets isolated. Device contain on that same laptop does nothing useful until it returns to a network with onboarded peers.

Third, Isolate device’s failure modes are different. Per the Microsoft Learn respond-machine-alerts page, if the suspect device is offline or inactive when the isolation action submits, Defender retries enforcement for up to three days. After three days with no reconnect, the retry stops and an administrator must reissue the action manually. Device contain doesn’t have this problem — the peer-side block is unaffected by the suspect device’s state. For shops with a meaningful fraction of laptops that are offline at any given moment, the three-day retry window is the load-bearing operational detail.

The 99%+ confidence claim

The headline number from the primary docs is Microsoft’s stated confidence threshold. From the automatic-attack-disruption Learn page, updated May 17, 2026: “For containment actions, Defender maintains a confidence level of 99% or higher based on real production data.” That figure is signal-to-noise ratio, evaluated against a broad set of indicators across cross-workload correlation, machine learning outputs, and “expert-led incident classification.” Microsoft’s framing is that the high SNR target is what makes the automation tolerable as a deployable control — most enterprises have been historically unwilling to let an EDR autonomously sever a production endpoint without human review, and the 99%+ bar is positioned as the answer to that hesitation.

A few notes on reading that number honestly.

It’s a confidence threshold on detector output, not an end-to-end false-positive rate at scale. The Learn page is clear about this: detectors get validated in audit mode before broad release, deploy gradually as they meet quality requirements, and remain under continuous review with 24×7 operational anomaly coverage. The 99% figure is the design target for production detectors as released. Real-world false positives are a function of that threshold and the distribution of activity in your specific tenant, which Microsoft can’t bound for you.

The model stack Microsoft names is worth pinning. From the same Learn page: “graph models, boosted decision trees, neural networks, and dedicated small language models (SLMs).” That’s a different stack from what most “AI-driven EDR” marketing implies. SLMs in this position — purpose-built, narrow, tuned to disruption-decision tasks — are a real architectural choice, not a model-of-the-month story. The graph models are the part most defenders should care about because cross-asset correlation (endpoint + identity + email + SaaS) is what lets the system distinguish “compromised user laterally moving” from “developer with three jump-box sessions open.” Single-signal EDR can’t make that call at 99% confidence. The XDR-wide correlation is what makes the disruption confidence bar reachable.

The automation is reversible. Every action goes to Action Center and can be undone by a security operator with the right role. That matters because the actual operational risk of an automatic isolation isn’t “it fired wrong on a critical asset and we never noticed” — it’s “it fired wrong on a critical asset and the user couldn’t reach anyone for 90 minutes.” Reversibility is a control, not a feature. Plan the runbook for the false-positive case before flipping the feature on.

What gets isolated and what doesn’t

The Preview is workstation-only. The Learn respond-machine-alerts page is explicit: “Automatic device isolation works only on end-user workstations that are onboarded and managed by Microsoft Defender for Endpoint.” Servers, domain controllers, and critical assets are not in scope for the Preview’s full isolation action. They are still in scope for Device contain and for the granular critical-asset containment that ships separately.

The critical-asset path is its own mechanism worth understanding because it’s the answer to the question “what happens when the compromised host is a DC.” The automatic-attack-disruption doc notes that critical asset containment uses device role-based granular policy — blocking specific ports and communication directions while leaving “essential functions running.” Domain controllers, DNS servers, and DHCP servers are explicitly named as supported critical-asset roles. The architectural posture is: severing a critical asset’s network connectivity is worse than the attack continuing for the disruption-response window, so the system blocks the attack-related traffic rather than all traffic. This is a deliberate departure from the workstation isolation model. The granular containment has been GA; the new Preview is specifically about adding full isolation to the workstation tier.

The exclusion model has two layers. Defenders need both before the Preview is safe to enable broadly.

Selective isolation exclusions define which processes and network destinations remain reachable from an isolated device. Use these to keep management tooling, backup agents, or specific business applications working while the device is otherwise cut off. Per the Learn isolation-exclusions page (the same exclusion model the manual Isolate device action has used since at least 2018), this is Windows 10 1703+, Windows 11, Windows Server 2012 R2+, and macOS. Not Linux.

Automatic attack disruption exclusions define which devices or entities are excluded from automatic disruption actions entirely. Use these for business-critical hosts that cannot tolerate being isolated even briefly, regardless of confidence level. This is the runbook for the executive laptop, the trading floor workstation, the surgical-suite tablet — anywhere where the cost of a 99% confidence isolation is unacceptable in the 1% case.

The Learn doc’s guidance on the interaction is the important part: “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.” Read that twice. If you’ve configured selective isolation exclusions for a device, the automatic action will respect those exclusions rather than falling back to full isolation. Which means the exclusion configuration you set up for the manual action also governs the automatic action’s behavior. That’s helpful (one exclusion model, two callers) and also a sharp edge (broad selective-isolation exclusions defang the automatic action’s blast-radius reduction). Audit your selective-isolation exclusion list before turning on the automatic feature.

Defender-side mitigations to wire up before enabling

This is the section that’s load-bearing. The Preview is on by default for tenants that meet the prerequisites and have automatic attack disruption configured, per Microsoft’s rollout pattern. Defenders who don’t want to find out their highest-paid executive’s laptop got isolated at 3 AM during an actual incident should do the following first.

One — inventory the critical-asset tag application. The granular critical-asset containment relies on Microsoft Defender Vulnerability Management’s critical asset identification. If your tenant hasn’t applied the critical asset tag thoughtfully, the automation either does the wrong thing on a critical host (treats it as a workstation candidate for full isolation) or does nothing where it should fire. Pull the device inventory, sort by critical asset designation, and validate. Domain controllers should be tagged. DNS servers should be tagged. Anything where full network isolation would create a downstream outage should be tagged or explicitly excluded.

Two — define the automatic attack disruption exclusion list with the business, not the SOC. This is a list of who cannot be auto-isolated under any circumstances. The SOC can’t make that call alone; it’s a business decision about which roles or hosts cannot tolerate a 1%-case false positive. Get the list signed. Apply it to the disruption exclusions. Document the runbook for what happens when an excluded host shows attack-disruption-triggering signals (manual triage queue, on-call escalation, whatever fits the shop). The hardest part of this work is political, not technical; do it before the first incident, not during.

Three — audit your selective isolation exclusions against the new caller. The selective isolation exclusion list that’s been governing manual isolations now governs automatic ones too. Walk the list. Anything that was “let this through for the operator who manually isolated” probably still makes sense for the automatic case, but the implicit blast-radius calculation has changed — automation will fire more often than manual operators do. Tighten where appropriate.

Four — test the release-from-isolation path before you need it. The Learn docs reference a downloadable script for forcibly releasing devices that have become unresponsive while isolated (this is the case where the user truly cannot do anything, can’t reach IT, and the device’s local agent has wedged). The script requires Windows 10 21H2 / 22H2 with KB5023773, Windows 11 21H2 with KB5023774, or Windows 11 22H2 with KB5023778. If your Windows patch posture is older than those minima, the force-release path doesn’t work and you’ll be stuck with manual reimaging on a wedged isolated device. Patch first.

Five — verify the EDR control plane network path works under isolation. The Microsoft Learn isolation doc warns that “devices that are behind a full VPN tunnel won’t be able to reach the Microsoft Defender for Endpoint cloud service after the device is isolated.” If your remote-worker fleet routes all traffic through a full-tunnel VPN, isolation kills the EDR connectivity that’s supposed to be preserved. The recommended posture is split-tunneling for Defender cloud-protection traffic specifically. If you can’t or won’t do split-tunneling for compliance reasons, you need a different mitigation strategy — possibly excluding the full-tunnel population from the automatic action entirely until the connectivity gap is resolved.

Six — make sure the user notification UX exists where you need it. The Learn doc notes that the device-side isolation notification (“a no network connection message”) is only available on Windows. macOS and Linux give the user no UI signal that the device has been isolated. The user just sees “the network is broken.” If your help desk takes that ticket without a way to correlate it back to an automatic disruption action, the support cost spikes. Make sure the help desk runbook covers the case.

What the Microsoft case data actually says about timing

Microsoft’s October 2023 launch post for automatic attack disruption included two case examples worth referencing because they’re the only public numbers Microsoft has shared on disruption timing in real incidents. From the primary Microsoft Security Blog, the Akira ransomware case described attackers being “blocked approximately 30 minutes into the attack,” and a medical research lab case had the disruption fire at 4 AM “before lateral movement completed.” Both are anecdotes, not statistics — Microsoft has not published aggregate dwell-time-reduction numbers or false-positive rates for the broader deployment.

The honest read: the Microsoft case data confirms the feature can fire fast under the right conditions. It does not confirm what the per-tenant false-positive rate will be in your specific environment. The 99%+ confidence figure is a design target; the case studies are anecdotal evidence the design is meeting that target in some real incidents. Both are real, neither is a guarantee.

The shape of the change

Automatic attack disruption launched in October 2023 with Device contain and user disable. The May 2026 Preview adds Isolate device to the workstation tier. The structural direction is clear: Microsoft is closing the gap between “an attack is detected” and “the attack is contained” by removing the human in the loop for the highest-confidence detection band, and they’re betting that the 99%+ confidence design target is high enough to make that tradeoff acceptable.

For defenders, the Preview is not a feature decision — it’s an opportunity to do the exclusion-list, critical-asset-tagging, runbook, and patching work that should have been done before the existing Device contain action was firing. The work matters either way. The Preview is what makes the work urgent rather than recommended.

The next quarter’s question is what server-tier automation looks like, because the workstation-only scope leaves the highest-impact attack stage (DC compromise, hypervisor compromise, critical SaaS pivot) outside the new control. The granular critical-asset containment is the current answer; whether it’s enough is a different post.