Device Isolation Contains a Device — Not Necessarily the Entire Identity Incident
When an endpoint is isolated, verify what stopped on the device and then look for authentication and cloud activity that may continue independently.
✓ Establish endpoint containment time
✓ Follow the user's cloud activity
✓ Verify identity containment separately
The endpoint response looked successful
The compromised laptop had generated suspicious process and network activity. Microsoft Defender for Endpoint isolation removed the device from normal network communication. That was a successful endpoint containment action — but it did not answer what had already happened to the user's identity or cloud session.
Endpoint compromisedSuspicious process and network telemetry established the device as part of the incident.
Device isolatedThe SOC used Defender for Endpoint to contain the affected machine.
Cloud activity continuedMicrosoft 365 telemetry showed that the investigation could not end with the endpoint action.
Establish the endpoint timeline first
Start with the device evidence and identify the final suspicious network activity around the isolation window. The exact isolation timestamp should come from the Defender portal or available response-action evidence; the KQL below helps establish what the endpoint was doing immediately before containment.
endpoint-before-isolation.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
let Device = "LAPTOP-042";
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where DeviceName =~ Device
| project Timestamp,
DeviceName,
InitiatingProcessAccountUpn,
InitiatingProcessFileName,
RemoteUrl,
RemoteIP,
RemotePort
| order by Timestamp asc
Did endpoint activity actually stop?
Containment should be verified rather than assumed. Compare device network telemetry before and after the isolation time. Depending on platform behaviour and the isolation mechanism, limited communications required for Defender services may still occur, so interpret post-isolation events in context.
verify-device-containment.kql
1
2
3
4
5
6
7
8
9
10
11
let Device = "LAPTOP-042";
let IsolationTime = datetime(2026-08-25 10:18:00);
DeviceNetworkEvents
| where Timestamp > IsolationTime
| where DeviceName =~ Device
| summarize Events=count(),
FirstSeen=min(Timestamp),
LastSeen=max(Timestamp)
by RemoteUrl, RemoteIP
| order by Events desc
Then move from the device to the identity
Once the endpoint is contained, pivot to the user associated with the incident. Review Microsoft Entra sign-ins around the compromise and isolation window. A cloud session may have been established before the device was isolated, or suspicious authentication may have occurred from another source entirely.
identity-around-isolation.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
AppDisplayName,
IPAddress,
ResultType,
ConditionalAccessStatus,
AuthenticationDetails,
DeviceDetail,
CorrelationId
| order by TimeGenerated asc
The cloud timeline continued after isolation
Defender XDR cloud activity showed actions associated with the same user after the endpoint containment time. This did not prove that the isolated laptop was generating those actions. In fact, the timing was the reason to separate the endpoint and cloud timelines.
cloud-after-isolation.kql
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
let User = "alex@contoso.com";
let IsolationTime = datetime(2026-08-25 10:18:00);
CloudAppEvents
| where Timestamp > IsolationTime
| where AccountId =~ User
or tostring(RawEventData) has User
| project Timestamp,
Application,
ActionType,
AccountDisplayName,
IPAddress,
RawEventData
| order by Timestamp asc
Was the cloud activity coming from the same source?
Compare the IP addresses and application context associated with cloud actions before and after device isolation. A different source can indicate that the cloud activity is independent of the isolated endpoint. A repeated source can still require careful interpretation because cloud services, proxies and session behaviour can affect what the telemetry shows.
compare-cloud-context.kql
1
2
3
4
5
6
7
8
9
10
11
let User = "alex@contoso.com";
CloudAppEvents
| where Timestamp > ago(7d)
| where AccountId =~ User
or tostring(RawEventData) has User
| summarize FirstSeen=min(Timestamp),
LastSeen=max(Timestamp),
Actions=count()
by Application, IPAddress, ActionType
| order by LastSeen desc
One containment action had solved one part of the incident
The investigation now had two distinct containment questions. Was the compromised endpoint contained? And was the compromised identity or cloud access contained? Treating those as separate questions prevented a successful device action from creating false confidence about the wider incident.
Endpoint containmentVerify that suspicious endpoint behaviour and ordinary network communication have stopped as expected.
Identity containmentReview authentication methods, credentials, sign-ins and sessions according to the organisation's incident-response process.
Cloud containmentContinue checking Microsoft 365 activity until suspicious actions stop or are otherwise explained.
Build one incident timeline across both worlds
Endpoint and cloud telemetry should be brought together chronologically. The important sequence is not simply that isolation occurred; it is what happened before it, what continued after it and which containment action finally stopped each part of the attack.
10:02 — endpoint activitySuspicious process and network behaviour established the compromised device.
10:18 — device isolatedThe endpoint containment boundary was established.
10:26 — cloud activity continuesMicrosoft 365 evidence proved that the wider incident required additional investigation.
What the evidence can and cannot prove
Cloud activity after device isolation proves that activity associated with the identity continued after the endpoint containment boundary. It does not, by itself, prove token theft or prove which physical device generated every cloud action. Attribute the mechanism only when the sign-in, session, device and cloud evidence supports it.
ProvenThe endpoint was isolated at a known time and cloud activity associated with the identity occurred afterwards.
Important inferenceThe incident had a cloud or identity dimension that endpoint isolation alone did not resolve.
Not automatically provenContinued cloud activity is not enough by itself to claim a stolen token or identify the exact session mechanism.
Agent Foskett's investigation mindset
Containment controls operate at different layers. A device action can work perfectly while an identity or cloud session remains part of the incident. Verify each layer with the telemetry that belongs to it.
Contain the endpointStop the device from continuing its role in the attack.
Follow the identityAsk what authentication and cloud access already existed before the endpoint was isolated.
Prove the outcomeKeep investigating until endpoint, identity and cloud activity all have an explained final state.
Investigation findings
Microsoft Defender for Endpoint isolation successfully contained the compromised laptop, but the incident did not end there. Sign-in and cloud telemetry showed Microsoft 365 activity associated with the affected identity after the isolation boundary. The SOC therefore expanded containment from the endpoint into the identity and cloud layers, verifying each separately instead of assuming one successful response action had closed the entire incident.
The isolation workedThe device containment action addressed the endpoint portion of the incident.
The cloud timeline kept movingPost-isolation activity demonstrated that the wider compromise still required investigation.
Containment became multi-layeredThe team treated device, identity and cloud access as separate states that each required verification.
Related Agent Foskett investigations
Continue with Defender XDR, endpoint and Microsoft 365 investigations.
Device isolation is one of the most useful endpoint containment actions available to a SOC, but it should not become the point where the analyst stops looking. Modern incidents cross endpoints, identities and cloud services. Isolate the machine, then ask what the attacker may already have carried beyond it. The device can be contained while the investigation is still moving.
Did the endpoint stop?Verify the device containment action using endpoint telemetry.
What continued in the cloud?Review sign-ins and Microsoft 365 activity after the isolation boundary.
Is every layer contained?Do not close the incident until endpoint, identity and cloud activity have been accounted for.
Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD
The Device Was Isolated — But the Cloud Session Kept Moving
This Agent Foskett investigation explores Microsoft Defender for Endpoint device isolation, Microsoft Entra sign-ins, Microsoft 365 cloud activity, DeviceNetworkEvents, CloudAppEvents and KQL.
Defender XDR Device Isolation Investigation
The investigation establishes the endpoint containment boundary and then follows the affected identity into cloud telemetry to determine whether suspicious Microsoft 365 activity continued after the device was isolated.
Endpoint, Identity And Cloud Containment
Modern incident response requires analysts to verify containment at multiple layers. A successfully isolated endpoint does not by itself establish that identity access or existing cloud activity has ended.