ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Device Compliance • Session Theft • Microsoft Entra ID • Conditional Access • Defender XDR • KQL

The Device Was Compliant — The Session Wasn't

The device was managed.

It was enrolled. It was compliant. Conditional Access allowed the sign-in.

On paper, everything looked exactly as it should.

Then the account began accessing resources from a pattern that did not match the trusted endpoint.

The device was compliant. The session still needed investigating.

Discuss identity security Back to investigations
Agent Foskett investigating a suspicious Microsoft Entra session associated with a compliant device
Session Investigation

A trusted device is evidence. It is not the end of the investigation.

Confirm what the sign-in said about the device
Compare the session with endpoint and network evidence
Investigate token replay and session protection

The compliant-device signal looked reassuring

Device compliance can be an important Conditional Access control. But an investigator still has to establish whether the resulting activity belongs to the expected user and endpoint, and whether the session itself remained trustworthy.
The device was compliantThe Entra sign-in record associated the authentication with a device that met the organisation's compliance requirements.
The later activity did not fitSubsequent access appeared from network and application patterns that did not line up cleanly with the trusted endpoint.
Trust had to be separatedThe question became whether the trusted device and the suspicious session were really the same thing.

Start with successful sign-ins from compliant devices

In Microsoft Sentinel or Log Analytics, SigninLogs can expose the device information recorded with each sign-in. Start with the successful events and extract the compliance, management and device identifiers before narrowing the hunt.
compliant-device-signins.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| where ResultType == "0"
| extend DeviceId = tostring(DeviceDetail.deviceId),
         IsCompliant = tobool(DeviceDetail.isCompliant),
         IsManaged = tobool(DeviceDetail.isManaged),
         OperatingSystem = tostring(DeviceDetail.operatingSystem),
         Browser = tostring(DeviceDetail.browser)
| where IsCompliant == true
| project TimeGenerated, UserPrincipalName, AppDisplayName,
          IPAddress, DeviceId, IsCompliant, IsManaged,
          OperatingSystem, Browser, ConditionalAccessStatus,
          AuthenticationRequirement, CorrelationId
| order by TimeGenerated asc

Compare the same account across device identities and IP addresses

A useful next step is to look for successful access associated with missing, different or changing device identifiers. This does not prove token theft, but it highlights sessions that deserve closer investigation.
compare-session-context.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| where ResultType == "0"
| extend DeviceId = tostring(DeviceDetail.deviceId),
         IsCompliant = tostring(DeviceDetail.isCompliant),
         OS = tostring(DeviceDetail.operatingSystem),
         Browser = tostring(DeviceDetail.browser)
| summarize SignIns = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by IPAddress, DeviceId, IsCompliant, OS, Browser,
       AppDisplayName, IsInteractive
| order by FirstSeen asc

Verify the trusted endpoint in Defender XDR

DeviceInfo provides Defender's view of devices in the organisation. Use the Entra device identifier from the sign-in to find the expected endpoint and confirm its current identity, operating system and logged-on-user context.
verify-defender-device.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
DeviceInfo
| where Timestamp > ago(7d)
| where AadDeviceId == "00000000-0000-0000-0000-000000000042"
| summarize arg_max(Timestamp, *) by DeviceId
| project Timestamp,
          DeviceName,
          DeviceId,
          AadDeviceId,
          OSPlatform,
          OSVersion,
          MachineGroup,
          LoggedOnUsers

Ask whether the trusted endpoint made the suspicious connection

If the suspicious cloud activity came from a particular remote address or domain, look for matching endpoint telemetry. A missing match is not proof that the session came from another device, but it can become an important discrepancy when combined with the rest of the evidence.
endpoint-network-correlation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
DeviceNetworkEvents
| where Timestamp between (datetime(2026-08-17T01:45:00Z) .. datetime(2026-08-17T03:00:00Z))
| where DeviceName =~ "LAPTOP-042"
| where RemoteIP == "203.0.113.45"
   or RemoteUrl =~ "suspicious.example"
| project Timestamp,
          DeviceName,
          InitiatingProcessAccountName,
          InitiatingProcessFileName,
          InitiatingProcessCommandLine,
          RemoteIP,
          RemotePort,
          RemoteUrl,
          Protocol
| order by Timestamp asc

Look for non-interactive token use after the trusted sign-in

A session can continue after the interactive authentication event. Review non-interactive sign-ins and token-based access around the same period, especially when the IP address, application or device context changes unexpectedly.
noninteractive-session-activity.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| where ResultType == "0"
| where IsInteractive == false
| extend DeviceId = tostring(DeviceDetail.deviceId),
         IsCompliant = tostring(DeviceDetail.isCompliant)
| project TimeGenerated,
          AppDisplayName,
          ResourceDisplayName,
          IPAddress,
          IncomingTokenType,
          DeviceId,
          IsCompliant,
          ConditionalAccessStatus,
          CorrelationId
| order by TimeGenerated asc

Build the session timeline instead of trusting a single field

A simple timeline helps expose changes in network, application and device context. The strongest finding is usually not one unusual value, but a sequence that stops matching the expected user and endpoint.
session-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| where ResultType == "0"
| extend DeviceId = tostring(DeviceDetail.deviceId),
         IsCompliant = tostring(DeviceDetail.isCompliant),
         OS = tostring(DeviceDetail.operatingSystem),
         Browser = tostring(DeviceDetail.browser)
| project TimeGenerated,
          IsInteractive,
          AppDisplayName,
          IPAddress,
          DeviceId,
          IsCompliant,
          OS,
          Browser,
          IncomingTokenType,
          ConditionalAccessStatus,
          CorrelationId
| order by TimeGenerated asc

Device compliance and token protection answer different questions

A compliant-device policy helps control which devices are allowed to access protected resources. Token Protection is a separate Conditional Access session control designed to reduce token replay by requiring supported sign-in session tokens to be device bound.
Compliance evaluates the deviceIt helps establish whether the device meets the organisation's configured compliance requirements when access is evaluated.
Token protection strengthens the sessionFor supported scenarios, device-bound session tokens make replay from another device more difficult.
Neither replaces investigationSign-in, device, token, application and network evidence still need to be correlated when behaviour is suspicious.

Agent Foskett's investigation mindset

Do not let one trusted attribute inherit trust on behalf of the entire session.
Ask what was actually trustedA device-compliance signal describes the device context recorded for the access decision. It is not a universal verdict on every later action.
Compare cloud and endpoint evidenceIf the endpoint cannot explain activity attributed to the session, preserve the discrepancy and keep investigating.
Think about tokens, not only passwordsA user can authenticate legitimately and still have a session artefact become the focus of the investigation.

Investigation findings

The compliant-device signal was valid. The mistake would have been allowing that single signal to close an investigation that the later evidence had reopened.
The trusted device existedEntra and Defender evidence supported the existence of the expected managed endpoint.
The session context changedLater sign-in and access behaviour no longer aligned cleanly with the trusted endpoint's network and device evidence.
The session became the investigationThe evidence shifted the question from “was the device compliant?” to “does this activity still belong to that device and user?”

Related Agent Foskett investigations

Continue with session hijacking, Conditional Access, MFA and identity-compromise investigations.
The Conditional Access Result Said Success — But That Wasn't the Whole StoryUnderstand why a successful policy result is only one part of the identity timeline.
MFA Session HijackingExplore how successful authentication and session theft can become separate parts of the same incident.
The Session Token Never ExpiredInvestigate persistent session access after the original authentication event.
The Login Came Through a Trusted DeviceInvestigate how trusted-device context can influence the initial interpretation of a suspicious sign-in.
The User Passed MFA — But It Wasn't Really ThemSee why MFA success does not automatically settle the question of user intent.
Agent Foskett AcademyBuild practical KQL and Microsoft security investigation skills through structured lessons.
The device was compliant. The session still had to explain itself.
Separate device trust from session trust and follow the evidence.
Visit the Agent Foskett Academy

Final thought

Zero Trust is not a collection of green labels. It is the discipline of continuously evaluating identity, device and session evidence in context.
The device signal matteredCompliance gave the investigator useful context about the endpoint associated with the sign-in.
The session told a different storyNetwork, application and token activity can force an investigation beyond the original access decision.
Trust the complete timelineA trusted device is evidence. It is not the end of the investigation.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Device Was Compliant — The Session Wasn't

This Agent Foskett investigation explores a suspicious Microsoft Entra session where the sign-in was associated with a compliant managed device, yet later access no longer aligned cleanly with the expected endpoint and network evidence.

Microsoft Entra Device Compliance, Session Tokens And Conditional Access

The investigation demonstrates how SigninLogs, DeviceDetail, ConditionalAccessStatus, DeviceInfo and DeviceNetworkEvents can be used to compare identity, device and network evidence across a suspicious session.

KQL, Token Replay And Microsoft Defender XDR Investigation

GEMXIT helps organisations investigate Microsoft Entra sign-ins, device compliance, token and session anomalies, Conditional Access outcomes and Microsoft Defender XDR telemetry using practical KQL and evidence-driven investigation workflows.