In almost every tenant I support, the first serious security incident turns into the real test for Defender live response. An alert shows up in Microsoft Defender for Endpoint Plan 2, the SOC is on edge, and a device has to be isolated right now. Knowing the theory is one thing. Responding well under pressure is something else. Whether an investigation stays controlled or turns chaotic usually comes down to the details of device isolation, how you actually use live response and how carefully you handle evidence. Below is how I structure my response in practice, along with the tips that save me time and the pitfalls I keep running into.

Full and selective isolation both keep the device reachable for live response

When a device is compromised, you want it as isolated as possible, but not so isolated that Defender loses contact with it. On the device page in the Defender portal, under “Actions,” select “Isolate device.” You then pick full or selective isolation. Full isolation cuts off all network access except what Defender services strictly need. Selective isolation also allows traffic to specific management systems defined in policy. In both modes, the device stays available for Defender live response as long as the connection to the Defender service holds. In most crises I go straight to full isolation, unless that would break something critical. If you're interested in automated responses, I've written about automatic attack disruption in Defender XDR here.

Before going further, this diagram shows the flow I usually follow when responding to a device incident:

flowchart TD
    Start["Alert on device"] --> Isolation["Isolate device (full/selective)"]
    Isolation --> RestrictApps["Restrict app execution"]
    RestrictApps --> Investigation["Collect investigation package"]
    Investigation --> LiveResponse["Start live response session"]
    LiveResponse --> Doku["Document actions taken"]

Figure: My usual workflow for a live response session during a device incident.

Restricting app execution is the safeguard most teams forget

If you're concerned that malware could still drop more payloads, the “Restrict app execution” action in Defender for Endpoint helps a lot, and people often forget it exists. It blocks new applications from launching on the device. Processes that are already running keep going, though, and that detail is easy to miss. So it's not a full freeze, but it does stop attackers from starting additional tools. The option sits on the device page under “Actions” → “Restrict app execution.” You need a Defender for Endpoint Plan 2 licence, and Advanced features must be enabled for the tenant.

The investigation package gives you forensics with one click

Once the device is isolated, I almost always request an investigation package next. It collects memory dumps, logs and forensic artifacts that you'll need for later analysis. You trigger the collection from the same device page. Preparation usually takes a few minutes, and the device has to stay connected to Defender during that time. If you like to automate, the Defender for Endpoint APIs are worth a look, but the portal is fine for most teams. One thing to watch out for is that the investigation package is encrypted, and the password appears together with the download link. Make sure you write it down!

Practical tip: Let the investigation package finish downloading before you remove the device from inventory or start destructive forensics. Otherwise you risk losing your chain of custody.

Live response sessions depend on settings, RBAC and a few key commands

After isolating the device, open the device page → "Live Response" to start a session. Check the prerequisites first. In the Defender portal, go to Settings → Endpoints → Advanced features and confirm that "Live Response" is enabled. If you want to run your own (possibly unsigned) scripts, you have to explicitly turn on "Allow unsigned scripts". That setting carries real risk, so reserve it for experienced analysts. Permissions are managed through unified Defender RBAC (Microsoft Defender portal → Settings → Permissions). You need at least a role with "Live Response" or "Custom Investigation" permissions.

The live response commands I find most useful:

  • processes – shows all running processes,
  • getfile – pulls specific files from the device (useful for suspicious DLLs or scripts),
  • run – runs library scripts, if permitted.

The official docs always have the current full command list. In most incidents, a quick look at the running processes plus collecting suspicious files is enough to check your first hypotheses.

This is how you fetch a suspicious file, for example:

getfile C:\Users\Public\Downloads\suspect.exe

Run it directly in the live response console (Defender portal → Devices → select device → Start live response).

Every response step belongs in the incident timeline

When things get hectic, documentation is usually the first thing to slip. I've made it a habit to record my actions in the incident timeline in the Defender portal, including device isolation, app restrictions, requested packages, downloaded files and executed scripts. That effort pays off at team handovers, in the post-incident review and for compliance. If you work with custom detection rules, Custom detection rules from hunting queries in Defender XDR covers good documentation and continuous improvement.

Practice beats panic when the real incident hits

Defender live response is a powerful tool, but only when prerequisites, permissions and processes are sorted out before a crisis. Far too often I watch teams enabling features, fixing RBAC or pulling an investigation package for the very first time in the middle of a real emergency. Regular practice, playbooks you've actually rehearsed and a working knowledge of the essential commands make incident response faster and safer, and the documentation ends up better too. A few dry runs are worth much more than improvising when it matters.