There are two automation systems running in your tenant right now and they are governed on opposite principles. One of them will not act until a human approves it. The other will disable an account or cut a machine off the network without asking anyone, and offers you an undo button instead of an approval queue. Most teams I meet know they have the first one, because it has settings. Very few have decided anything about the second, and the second is the one that will act during your incident.
The object everything else acts on
Before either of those systems can act, something has to decide what they are acting on, and that is the incident. The correlation engine aggregates related alerts from every product feeding it into one object, and the incident rather than the alert is the unit of work. Three properties of that object break operational assumptions, and they break them quietly enough that most teams meet them during an incident rather than before one.
Incidents are living. The engine keeps adding evidence to one that is already open, so a case an analyst is halfway through can grow underneath them, and a triage decision made an hour ago was made against a smaller object. That is a feature, and it means any process that snapshots an incident at assignment time is working from a photograph of something that moved.
Incidents merge, on shared entities and artefacts and timeframes, and a merge creates no new object. The contents of the source migrate into the target, the source closes, and it is tagged as redirected. The part worth writing down is that Microsoft decides the direction, including when an analyst merges two incidents by hand. You choose that two cases are one; you do not choose which identifier survives. Anything you have built that keys on an incident identifier, which in most estates means the ticketing integration, will eventually hold a reference to a closed tombstone while the live case carries a different number. There is no product-side remedy for that and Microsoft offers none. The mitigation is to key your integration on something else, or to accept the reconciliation work and staff it.
And a resolved incident does not reopen. New alerts that would have correlated into it instead form a new incident. Closing is therefore not the administrative act at the end of the work, it is a decision that partitions future correlation, and premature closure quietly costs you the link between the thing you resolved on Tuesday and the thing that turns up next week wearing a different name. I have watched a team close aggressively to keep a queue metric respectable and lose exactly that link, twice, before anybody connected the two facts.
You choose that two incidents are one. You do not choose which identifier survives, and your ticketing integration is holding the other one.
Permission and forgiveness
Automated investigation and response is the older design and it is built entirely around consent. A device group carries an automation level, remediation either happens or waits, pending actions queue up for a human, and the whole thing is configurable down to which folders you are willing to let it clean. It is a workflow engine with a gate in the middle, and the gate is the product. Attack disruption is the newer design and it has no gate. It evaluates a whole incident rather than a single indicator, decides that an attack is in progress, and takes containment action across whatever products you have deployed. There is no approval step and there is no way to add one. What Microsoft offers in exchange is that every action it takes is reversible.
Those are two genuinely different theories of how a security platform should behave, shipped in the same console, both switched on. They coexist, and Microsoft has already decided which one wins. The half that asks permission is being dissolved into the antivirus stack on a published date, and the half that asks forgiveness is the half that keeps gaining actions. If you want to know where this platform is going, that is the whole answer in one sentence.
What it can actually do, and what that depends on
The action surface is best read as a grid of action against product rather than as a feature list, because that is the shape that tells you what you will actually get. Defender for Endpoint contributes device containment, containment of an IP address for assets that were never onboarded, and automatic device isolation, which is still in preview and works only on onboarded end-user workstations. Defender for Identity contributes the account disable. Entra ID contributes two distinct actions, revoking a user’s sessions and suspending the account outright. Defender for Cloud Apps contributes the response to a compromised application registration, which is the governance surface argued in the software as a service pillar. Contain user sits on the endpoint side despite sounding like an identity action, for reasons I will come back to. Two further actions, suspending a user in Okta and attaching a deny policy to an AWS principal, arrive through Microsoft Sentinel connectors and are in preview.
Read that grid twice and the licensing argument from the anchor turns into an operational one. Any single qualifying licence entitles the tenant to the whole engine. Microsoft used to publish a table of per-scenario minimum requirements and no longer does; what replaced it is a prose principle, that the wider the deployment the greater the coverage and that each product must be deployed to execute its own response actions. So the grid above is not a licensing table. It is an inventory of your rollout, and every row you cannot execute is a place where the correlation engine will recognise an attack and have nothing to do about it.
Containment is the action worth understanding properly because it inverts the usual model. Isolating a device acts on the compromised machine: it drops the network while keeping the Defender channel open so you can still work on it. Containing a device does the opposite. The compromised asset is not touched, because it may not be onboarded and may not be manageable at all. Instead every onboarded device in the estate starts refusing to talk to it. Your endpoint fleet becomes the enforcement fabric, which means the number of machines you onboarded two years ago is what determines how effective containment is today. It also means the recommended ceiling of around a hundred contained devices at once is a real design constraint rather than a footnote, and that a contained device changing its address is handled for you, with the new address blocked and the old one released within about five minutes.
Containment does not act on the compromised machine. It turns every device you onboarded into the thing that refuses to talk to it.
The same inversion explains contain user, which is not a directory operation and does not disable anything. It blocks the compromised identity at the endpoints: network logons, remote procedure calls, file sharing and remote desktop, with existing remote sessions terminated rather than left running. It releases itself after five days, it cannot be triggered by hand, and applying it causes a Group Policy update on the domain controllers and a domain-wide synchronisation, which happens again when you undo it. That last detail is the sort of thing nobody mentions until an infrastructure team asks why the domain controllers replicated policy at three in the morning.
Containment has also stopped being a single blunt instrument. There is now a critical asset behaviour in which the platform identifies a device’s role and applies a matching policy, blocking specific ports and specific directions rather than everything, with domain controllers, DNS servers and DHCP servers named as examples of the supported asset types. That is the right direction of travel, and it quietly answers the most common objection I hear to letting disruption run, which is that nobody wants an automated system severing a domain controller at full strength.
The account disable is where deployment reality bites hardest, and it belongs to the sensor architecture argued in the identity pillar. An on-premises account is disabled on a domain controller by the sensor running there, which means the sensor has to be on the controller that will perform the disable. A cloud-only account is disabled through a Microsoft-managed enterprise application, and that path does not depend on having deployed the identity product at all. Sensors on federation, certificate and directory synchronisation servers contribute signal and take no remediation action. And current sensors always act as the domain controller’s own system account and ignore any group managed service account you configured for the previous generation, which is the kind of change that silently invalidates a permissions design somebody documented carefully in 2024.
The ninety nine percent, read carefully
The confidence figure gets quoted constantly and almost always wrongly. Microsoft’s statement is that confidence refers to detector precision measured as a signal to noise ratio, that for containment actions it maintains a level of ninety nine percent or higher, and that this is based on real production data. Three qualifications are doing work in that sentence. It describes detector precision rather than the correctness of a decision to act. It is scoped to containment actions rather than to disruption generally. And it is an observation of what the system has been doing, not a service level you can hold anyone to.
I do not raise that to undermine the number, which is a good number and is backed by an ensemble of models and a practice of running new detectors in audit mode before release. I raise it because the number is what people put in the risk paper when they are asking a change board to accept ungated automation, and a risk paper that overstates what the vendor said is a risk paper that will not survive the first false positive. State it as precisely as Microsoft states it and the argument gets stronger, not weaker.
The half that asks permission is being switched off
From 1 September 2026, automated investigation and response stops running as a separate investigation experience in Defender for Endpoint and stops being available for manual triggering. Microsoft’s position is that the detection and response capability is already in the default antivirus protection stack and runs automatically, and that a full antivirus scan is the substitute for an on-demand investigation. Defender for Office 365 is explicitly unaffected and keeps its own investigation engine. The configuration toggle for automated investigation has already gone from the endpoint advanced features page, with the capability described as enabled by default.
What makes this worth an article rather than a diary entry is the paper trail, or rather the absence of one. Five weeks before the date, this change exists in the documentation as two banner notices sitting on nine article pages. There is no entry in the what’s new feed, no line in a deprecation index, no release note. The two banners do not even say quite the same thing: the endpoint one scopes the change to Microsoft Defender broadly, the platform one scopes it to Defender for Endpoint alerts and remediations, which is materially narrower. Several of the pages a reader would most expect to be marked carry no banner at all, including the platform overview that still describes this capability as your own virtual analyst, and the device response page, updated at the end of June, which still walks you through triggering an investigation by hand.
A capability that many teams describe as their automation strategy is being withdrawn in five weeks, and the entire published record of it is two notices pasted onto nine pages.
Microsoft has not addressed what follows, and I am going to name the gaps as unanswered rather than guess, because guessing is what produces the confident wrong answer somebody later plans against. Custom detection rules can attach an initiate investigation action to a device, and that option is still documented without any deprecation marker on pages updated in June and July of this year. Nobody has said whether those rules keep running with the action dropped, fail validation on edit, or are migrated. The device group automation level is simultaneously the setting that governs investigation behaviour and the documented way to exclude a group from attack disruption, and no page explains what it still controls once investigations no longer run. And the built-in alert tuning rules that went generally available in April carry an explicit guarantee that suppression does not affect investigations and that an investigation finding something malicious reactivates the suppressed alert. That is a live functional dependency of a shipped feature on a mechanism that stops running for endpoint in five weeks, restated on a page updated in the middle of June.
That is overdue work rather than an emergency. Write down now which of your operational processes assume an investigation runs, and stop treating the device group automation level as a control you understand. The specific artefacts to go and read are the runbook steps that say to trigger an investigation and any integration calling the interface that does it, because neither will fail loudly on 1 September. They will do nothing.
What survives, and it is the part worth keeping
The Action center is the durable operator surface and it is not going anywhere. It holds pending and completed remediation across devices, mail and identities in one place, it exports, and it carries an undo catalogue that is the practical expression of the reversibility that ungated automation is trading on: isolation, device containment, user containment, code execution restriction, file quarantine, registry keys, services, drivers and scheduled tasks, undoable in bulk and, for a quarantined file, restorable across every device it reached. If you are going to let something act without asking, the interface where you review and reverse what it did is the control that matters, and it is the one to build your operating procedure around rather than the investigation graph.
Two permission traps live there and both catch people. Access to the Action center comes from the Security Administrator role in the directory, and Microsoft is explicit that membership of the similarly named mail and collaboration role group does not grant it. And in the unified model the endpoint approval permission and the mail remediation permission are two separate grants inside the same permission category, so a role built for one silently will not cover the other. That is the authority argument arriving at the point where somebody has to approve a remediation and finds they cannot.
Your exclusion list is your risk posture
Because there is no approval gate, everything you get to say about disruption you say in advance. The tenant side surface is four controls: excluded user accounts, excluded addresses and ranges, the device group automation level, and a newer preview that lets you keep disruption enabled while switching off individual controls for a set of devices selected by dynamic tag. That fourth one is the important arrival, because until it existed the only way to protect a fragile system was to remove it from automated response entirely. The direction is finer-grained rather than more permissive, and I would rather have it than the blunt lever.
There is now a second brake in a different place, generally available since June, which restricts high-impact response actions on assets designated as high value, live response included. So an estate can express do not touch this in two unrelated surfaces with different vocabularies, and an engineer who knows only the exclusions page will meet the other one during an incident and not know what they are looking at. Pick one as the record of intent, document the other as an exception, and do not let both drift.
Everything about how Microsoft has built this says the exclusion list is meant to be short. Exclusions are documented as not recommended. There is no export, no programmatic surface, and no way to review the list other than opening the page and reading it, which means your only durable record of why a break-glass account is excluded is the free text note somebody typed when they added it. Full opt-out is a support case, and opting out leaves the alerts and removes the actions. All of which is to say that in an estate running this platform, the honest description of your automated response policy is the contents of that page, and I have yet to review one that was written down anywhere else.
One asymmetry is worth knowing before you need it. Undoing a contained user requires Global Administrator, which Microsoft states and then immediately qualifies in the same block with its own advice that the role should be limited to emergencies. Reversing the device-side actions sits at the ordinary operator tier, on Security Administrator or the response permission in the unified model. So the single most privileged role in the tenant is the ticket for reversing the one action most likely to need reversing under time pressure, at the exact moment your privileged access process is least convenient.
Capabilities can also leave without telling you
Two years ago this feature was presented through named scenarios: business email compromise, human-operated ransomware, adversary in the middle. Those scenarios have gone from the documentation and the surface is now described generically, which is a reasonable editorial decision. Two capabilities have gone rather further. Disruption of financial process manipulation in SAP, which was a genuine and much-discussed capability, now exists only as a redirect to the generic overview, and the redirect is configured in a way that means the content was dropped rather than merged. The deception capability went the same way, two pages redirected to the same destination. In neither case is there a deprecation notice, a retirement date, or any statement at all.
I am not going to write that Microsoft deprecated either one, because Microsoft has not said that and the honest description is that the documentation stopped describing them. What follows for design is narrow and worth stating exactly: a control objective whose evidence is one named capability of this fabric has a dependency the vendor can retire editorially, with no date and no notice. The preview markers scattered across the rest of this surface are the same exposure in a more honest form, covering automatic isolation, the per-control exclusions and predictive shielding as a whole. I would deploy behind them. I would not cite one in a control document.
Predictive shielding is where this is heading, and it is worth a sentence for direction rather than for planning. It overlays live attack activity onto the exposure graph built in the exposure pillar and pre-emptively restricts assets that have not been compromised yet, on the basis that the attacker is predicted to reach them. The feature is in preview, its proactive user containment action is already generally available, and the aggregated exposure data that the previous block spent six articles building now has a consumer that acts rather than merely reports. That is the strongest argument I know for taking exposure aggregation seriously.
What cannot be decided
The thing that cannot be decided is whether this runs. It is running, it acts without asking, and the only tenant-side answer to it is the one you configured in advance. Proving that you actually configured it, across five products with no single readiness view and no interface that will tell you the answer, is a job of work rather than a checklist, and it is the readiness build sheet. After that, the platform’s other durable asset, which is the schema every one of these detections is written against and the detection engineering plane your own team owns, in the schema article.
Defender XDR
‹ Previous: [D 7.1.1] Build Sheet: Activating Unified RBAC and Wiring the Fabric Settings
Next: [D 7.2.1] Build Sheet: Attack Disruption Readiness ›
