Agent Foskett Case File • Microsoft Intune • Entra ID • Conditional Access • KQL
The Device Was Compliant Yesterday — Today It Wasn't Even Managed
Yesterday, the laptop was enrolled, compliant and permitted to access Microsoft 365.
Today, the help desk could not find it in Intune — but sign-in activity still appeared under the user's account.
“Was the laptop compliant?”
“Yesterday, yes.”
“And today?”
“Today, we're not entirely sure which laptop we're talking about.”
Agent Foskett stared at the device list. “Excellent. We've lost the device, but at least the confusion is fully managed.”
Case file: The missing managed device
A fictional, evidence-led investigation into Intune enrollment, Entra device identity, Conditional Access decisions and suspicious sign-in context.
✓ Separate compliance state from enrollment and device registration
✓ Correlate device identifiers across systems
✓ Test what Conditional Access actually enforced
The alert that made no sense
At 08:12 UTC, a user reported that their company laptop had stopped receiving configuration updates. The Intune admin centre no longer showed the expected managed device record. Yet Microsoft Entra sign-in logs contained recent activity for the same user.
Was the laptop retired? Had someone removed the management profile? Was the user signing in from a replacement device? Or was the device identifier in the sign-in record stale or misleading?
This is a fictional case study. All identities, times and events are illustrative. The purpose is to demonstrate an evidence-based investigation, not to imply that every missing Intune record indicates compromise.
Was the laptop retired? Had someone removed the management profile? Was the user signing in from a replacement device? Or was the device identifier in the sign-in record stale or misleading?
This is a fictional case study. All identities, times and events are illustrative. The purpose is to demonstrate an evidence-based investigation, not to imply that every missing Intune record indicates compromise.
YesterdayA corporate Windows laptop was listed as enrolled and compliant in Microsoft Intune.
TodayThe expected Intune managed-device record could not be found by its previous identifier.
Unproven concernMicrosoft 365 sign-ins continued; analysts needed to determine which device and which access controls were involved.
Three states that must not be confused
Registered or joined describes a device relationship with Microsoft Entra ID. Enrolled or managed describes management by Microsoft Intune or another MDM. Compliant describes an evaluation against configured compliance policies. These are related, but they are not interchangeable.
A device can have an Entra record without a corresponding active Intune enrollment. Compliance can become stale or change as policies and check-ins evolve. And a sign-in record may include device information without proving that a currently managed, healthy endpoint generated the event.
A device can have an Entra record without a corresponding active Intune enrollment. Compliance can become stale or change as policies and check-ins evolve. And a sign-in record may include device information without proving that a currently managed, healthy endpoint generated the event.
Start with the identifiers, not the display name
Record the Intune managed device ID, Microsoft Entra device ID, device name, serial number, primary user, enrollment type and last check-in time from any available records or exports. Do not join events solely on a friendly device name: devices can be renamed, reimaged, replaced or duplicated.
In the fictional case, investigators found an old Intune record identifier in a help-desk ticket, but a different device identifier in recent sign-ins. That mismatch became the central question, not proof of malicious activity.
In the fictional case, investigators found an old Intune record identifier in a help-desk ticket, but a different device identifier in recent sign-ins. That mismatch became the central question, not proof of malicious activity.
KQL: Review sign-ins and Conditional Access outcomes
In a Microsoft Sentinel workspace ingesting Microsoft Entra
SigninLogs, inspect device details, authentication status and Conditional Access outcomes together. The DeviceDetail column is dynamic; fields can be missing or empty. A successful sign-in does not necessarily mean a particular compliant-device policy applied: inspect the relevant policy details and exclusions in Entra.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
// Microsoft Sentinel: requires Entra SigninLogs ingestion
let TargetUPN = "analyst@example.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ TargetUPN
| extend Device = todynamic(DeviceDetail)
| extend DeviceId = tostring(Device.deviceId),
DeviceName = tostring(Device.displayName),
Managed = tostring(Device.isManaged),
Compliant = tostring(Device.isCompliant)
| project TimeGenerated, UserPrincipalName, AppDisplayName,
IPAddress, DeviceId, DeviceName, Managed, Compliant,
ConditionalAccessStatus, ResultType, CorrelationId
| order by TimeGenerated descRead the Conditional Access result correctly
The
For this case, a recent sign-in succeeded because the relevant application was outside the scope of the compliant-device policy. That finding explained the successful access without proving the endpoint was healthy or enrolled. A separate sign-in to a protected application had been blocked.
ConditionalAccessStatus field gives a useful high-level outcome, but it is not a substitute for the applied policy evaluation. Review the sign-in details in Entra, including which policies applied, were not applied or were report-only; check device filters, exclusions, grant controls, authentication strength and any session controls.For this case, a recent sign-in succeeded because the relevant application was outside the scope of the compliant-device policy. That finding explained the successful access without proving the endpoint was healthy or enrolled. A separate sign-in to a protected application had been blocked.
KQL: Look for device-related directory changes
The
AuditLogs table can show Entra directory changes when diagnostic ingestion is enabled. It may capture device registration, deletion and update events, but it is not a complete Intune device-management audit trail. Search broadly first and inspect the event payload rather than relying on one exact activity string.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
// Microsoft Sentinel: requires Entra AuditLogs ingestion
AuditLogs
| where TimeGenerated > ago(14d)
| where Category =~ "Device" or ActivityDisplayName has "device"
| extend Initiator = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, ActivityDisplayName, Category,
Result, Initiator, TargetResources, CorrelationId
| order by TimeGenerated descCheck the Intune audit trail separately
In the Intune admin centre, inspect audit events for device retirement, wipe, delete, enrollment changes and administrative actions. If Intune audit logs are exported to Log Analytics, the destination table and schema depend on diagnostic configuration. Do not assume Entra
Also check enrollment restrictions, MDM authority, licensing, certificate status, Company Portal state, device check-in failures and whether the device was re-enrolled after a reset. Preserve relevant administrative audit records before taking corrective action.
AuditLogs includes every Intune action.Also check enrollment restrictions, MDM authority, licensing, certificate status, Company Portal state, device check-in failures and whether the device was re-enrolled after a reset. Preserve relevant administrative audit records before taking corrective action.
KQL: Build a device-ID timeline from sign-ins
This query groups observed sign-in records by device ID and reported management/compliance state. It can expose changes and inconsistent identifiers, but it does not reconstruct a complete Intune compliance history.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
// Microsoft Sentinel: sign-in observations, not Intune history
let TargetUPN = "analyst@example.com";
SigninLogs
| where TimeGenerated > ago(14d)
| where UserPrincipalName =~ TargetUPN
| extend Device = todynamic(DeviceDetail)
| extend DeviceId = tostring(Device.deviceId),
DeviceName = tostring(Device.displayName),
Managed = tostring(Device.isManaged),
Compliant = tostring(Device.isCompliant)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
SignIns=count(), Apps=make_set(AppDisplayName, 10)
by DeviceId, DeviceName, Managed, Compliant
| order by LastSeen descWhat did the endpoint itself report?
Where the endpoint is still reachable and authorised for examination, check local MDM enrollment status, Windows device registration state, management diagnostics and the last successful sync. Correlate with Microsoft Defender for Endpoint inventory and sensor health if available. Defender device inventory, Entra registration and Intune managed-device records are separate sources; a device appearing in one does not automatically mean it is currently managed by another.
Do not remove or re-enroll a potentially compromised endpoint before preserving the evidence needed to understand what happened.
Do not remove or re-enroll a potentially compromised endpoint before preserving the evidence needed to understand what happened.
A six-stage evidence timeline
The following is an illustrative timeline, not a claim about a real tenant.
Previous day, 16:40 UTCThe last known Intune check-in reports the laptop as compliant.
07:51 UTCA device-management change appears in the administrative audit trail; investigators validate who initiated it.
08:12 UTCThe help desk cannot locate the expected Intune managed-device record.
08:26 UTCA sign-in succeeds to an application not covered by the compliant-device requirement.
08:31 UTCA separate protected application sign-in is blocked by Conditional Access.
09:05 UTCAnalysts correlate device IDs and discover a replacement enrollment record; the cause of the earlier removal remains under review.
The finding: A missing record is not a verdict
In the fictional investigation, the laptop had been reset and re-enrolled under a new management record. The old record was removed as part of a support workflow, but the documentation was incomplete. Some sign-ins belonged to the newly enrolled device, while another originated from an unmanaged browser session. The evidence did not establish account takeover.
The more important control gap was that one Microsoft 365 application remained accessible without the intended compliant-device requirement. The team corrected the Conditional Access scope and validated the outcome with test sign-ins, rather than assuming the device disappearance alone explained every event.
The more important control gap was that one Microsoft 365 application remained accessible without the intended compliant-device requirement. The team corrected the Conditional Access scope and validated the outcome with test sign-ins, rather than assuming the device disappearance alone explained every event.
Containment and recovery
If the evidence indicates unauthorised device removal or suspicious sessions, protect the account and affected resources according to the incident response plan. Review active sessions and tokens, examine sign-in risk and authentication changes, and isolate the endpoint when appropriate. Preserve Intune, Entra, Defender and endpoint evidence first where practical.
For an operational enrollment failure, confirm device ownership, restore a supported management state, check compliance evaluation and test access to both protected and unprotected applications. Avoid applying blanket policy changes without assessing service accounts, break-glass access and business impact.
For an operational enrollment failure, confirm device ownership, restore a supported management state, check compliance evaluation and test access to both protected and unprotected applications. Avoid applying blanket policy changes without assessing service accounts, break-glass access and business impact.
Practical defensive lessons
Use stable device identifiers when correlating telemetry. Monitor Intune administrative changes and device enrollment lifecycle events. Keep Conditional Access policies scoped to the applications and users that need protection, and test their actual enforcement. Separate identity, management and compliance in reports so a missing record cannot masquerade as a complete security conclusion.
Most importantly, treat every observation as evidence with limits. A successful sign-in proves a request was accepted under the evaluated conditions; it does not certify the endpoint.
Most importantly, treat every observation as evidence with limits. A successful sign-in proves a request was accepted under the evaluated conditions; it does not certify the endpoint.
Agent Foskett closes the case
“So the device was not managed?”
“The old record wasn’t. The replacement was.”
“And the sign-in?”
“One was blocked. One wasn’t covered by the policy.”
Agent Foskett picked up his coffee.
“There’s our problem. The laptop wasn’t the only thing missing. So was the policy scope.”
The Logs Already Knew!
“The old record wasn’t. The replacement was.”
“And the sign-in?”
“One was blocked. One wasn’t covered by the policy.”
Agent Foskett picked up his coffee.
“There’s our problem. The laptop wasn’t the only thing missing. So was the policy scope.”
The Logs Already Knew!
Related investigations
The Managed Identity Had No Password — So How Was It Misused?Investigate Azure workload identity permissions and unexpected resource access.The Teams Message Came From a Colleague — But the Link Didn't Belong ThereFollow suspicious links, sender identity and authentication activity.The Certificate Was Valid — But Nobody Knew Who Was Using ItExamine service principal ownership, certificates and workload sign-ins.
