One of the most time-critical decisions in any security incident is whether to isolate a compromised device from your network. Do it too slowly and an attacker moves laterally. Do it too aggressively and you cut off access before you have collected enough evidence to understand what happened. Microsoft has now added a preview feature to Defender for Endpoint that removes that hesitation: when the platform detects suspicious activity that meets its threshold, it automatically severs the device from your corporate network — but maintains a secure cloud channel so your security team can continue investigating remotely.
Preview feature
Automatic endpoint isolation is currently in preview. It must be explicitly enabled in your Defender XDR settings. It does not activate by default, and it applies only to onboarded end-user workstations — not servers.
How Automatic Isolation Works
The feature operates as an extension of Defender XDR's existing Attack Disruption capability. Attack Disruption is designed to contain active attacks automatically — including actions like disabling compromised user accounts or blocking lateral movement. Automatic endpoint isolation adds device network isolation to that toolkit.
The sequence of events when the feature triggers:
Suspicious activity detected
Defender for Endpoint sensors on the device detect behaviour that meets the threshold for an active attack. This is correlated with signals from across Defender XDR — identity, email, cloud apps — not just endpoint telemetry in isolation.
Device is automatically isolated
Defender severs the device's connection to the corporate network. All inbound and outbound network traffic is blocked — the device cannot communicate with other internal resources, cannot be used for lateral movement, and cannot exfiltrate data to attacker-controlled infrastructure.
Secure cloud channel remains open
Despite network isolation, the device maintains a secure link to the Microsoft Defender cloud. Your security team retains the ability to run live response sessions, collect forensic data, run queries, and execute response actions on the isolated device — remotely, without needing physical access.
Security admin reconnects the device
Once the threat has been investigated and neutralised, a security administrator manually releases the isolation. The device reconnects to the corporate network. This is a deliberate manual step — isolation is never automatically lifted.
Scope and Limitations
| Property | Detail |
|---|---|
| Status | Preview — must be explicitly enabled |
| Devices in scope | Onboarded end-user workstations only |
| Servers | Not currently in scope — this capability does not apply to onboarded server devices |
| Release from isolation | Manual — security admin must explicitly reconnect the device |
| Remote investigation | Available throughout isolation via secure Defender cloud channel |
| Platform | Part of Defender XDR Attack Disruption — requires Defender for Endpoint Plan 2 or Microsoft 365 Defender |
What Attack Disruption Is and Why This Fits
Attack Disruption is Defender XDR's autonomous response layer. It is designed to act within the first minutes of an attack — before a human analyst can respond — to contain the blast radius. Existing Attack Disruption capabilities include:
- Automatically disabling compromised user accounts when account takeover patterns are detected
- Blocking lateral movement by containing suspicious processes
- Revoking active sessions for compromised identities
- Now: automatically isolating workstations from the network
The design principle across all of these is the same: act fast enough to stop the attack from progressing, while preserving the ability for the security team to investigate fully rather than just cleaning up after the fact.
What this means for your incident response runbooks
If you enable this preview, your incident response process needs to account for the fact that device isolation may happen before a human analyst opens the incident. Your runbooks should address: how security ops will be alerted when automatic isolation fires, who has permission to release isolation, and what the expected investigation workflow is for an automatically isolated device. The secure cloud channel means investigation can start immediately — make sure your analysts know how to use live response on an isolated device.
How to Enable the Preview
To enable automatic endpoint isolation in preview:
- Go to Microsoft Defender XDR portal → Settings → Microsoft Defender XDR
- Navigate to Attack disruption settings
- Enable the Automatic endpoint isolation toggle
- Review and confirm the scope — ensure you understand this applies to all onboarded end-user workstations in your tenant
- Configure who receives alerts when automatic isolation fires and who has permission to release isolation
To release an isolated device manually: in the Defender portal, go to the device page, select the device, and choose Release from isolation from the response actions menu. This is available to users with the appropriate Defender for Endpoint roles.
Admin Considerations Before Enabling
- False positive risk: Automatic isolation will occasionally fire on legitimate activity that looks suspicious. Ensure your SOC team is prepared to investigate and release quickly — a false positive means a user is cut off from the network until manually cleared.
- End-user communication: Users whose devices are automatically isolated will lose network connectivity abruptly. Have a communication plan ready — users should know who to contact and what is happening if their device is suddenly isolated.
- VIP and critical role devices: Consider whether to exclude executives, on-call staff, or roles where sudden network isolation could have operational consequences. Exclusion scoping should be available in the settings.
- Helpdesk awareness: Your service desk will likely receive calls from isolated users. Make sure they know isolation is a security response, not a technical fault, and that the security team controls release.
- Servers are excluded: This capability does not apply to servers. If you want server isolation as part of your response process, you must continue to use manual isolation or existing automated playbooks.