Agent Foskett Investigation • Microsoft Intune • Microsoft Entra ID • Conditional Access • KQL
The Intune Device Was Retired — But It Was Still Accessing Microsoft 365
The device had been retired in Microsoft Intune.
It was supposed to be leaving management.
Then the sign-in logs showed something awkward.
The same device was still appearing in Microsoft 365 activity after the retire action.
The obvious conclusion was that Intune had failed.
Agent Foskett looked at the timeline and asked a better question.
When did the retire action actually reach the device?
Requested Is Not The Same As Completed
An Intune retire action is a device command. The important question is not only when the administrator clicked Retire, but when the client actually received and processed that command.
✓ Separate retire request time from device completion
✓ Match Microsoft 365 activity to the real device ID
✓ Check Conditional Access before assuming access should have been blocked
The device had been retired
The help desk had done exactly what the ticket required. The device was no longer needed, so a retire action was issued from Microsoft Intune. A later review of Microsoft Entra sign-in activity appeared to show Microsoft 365 access after that point. The first reaction was understandable: if the device was retired, why was it still getting in?
Retire was requestedThe administrative action had been issued in Intune.
Microsoft 365 activity continuedSign-in telemetry still contained events associated with the user and device context.
The timestamps did not agreeThat gap became the investigation.
Retire is not an instantaneous network kill switch
Microsoft documents the Intune Retire action as a command that removes company data and unenrols the device without factory-resetting it. Critically, the command is triggered when the device next checks in with Intune. That means the moment an administrator clicks Retire and the moment the client processes retirement are not necessarily the same moment.
Investigation point: “Retire requested at 14:00” does not automatically prove “retire completed on the endpoint at 14:00.” Build the timeline before calling the later access a control failure.
Build the sign-in timeline around the retire event
Start with the affected user and a known retire timestamp. Microsoft Entra SigninLogs can expose the target application, resource, source IP, client application and device details recorded during each sign-in.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
let User = "alex@contoso.com";
let RetiredAt = datetime(2026-09-07 02:00:00Z);
SigninLogs
| where TimeGenerated between (RetiredAt - 1h .. RetiredAt + 6h)
| where UserPrincipalName =~ User
| extend DeviceId = tostring(DeviceDetail.deviceId),
IsManaged = tostring(DeviceDetail.isManaged),
IsCompliant = tostring(DeviceDetail.isCompliant),
OperatingSystem = tostring(DeviceDetail.operatingSystem),
Browser = tostring(DeviceDetail.browser)
| project TimeGenerated, UserPrincipalName,
AppDisplayName, ResourceDisplayName,
IPAddress, ClientAppUsed,
DeviceId, IsManaged, IsCompliant,
OperatingSystem, Browser,
ConditionalAccessStatus, ResultType
| order by TimeGenerated asc
Read the device fields carefully: DeviceDetail is dynamic data. A missing device ID, managed flag or compliance value is itself useful context, but it should not be treated as proof of a particular physical device without correlation.
The timeline changed the story
14:00The administrator issues Retire from Microsoft Intune.
14:08The device has not yet completed another Intune check-in.
14:17Microsoft 365 sign-in activity is recorded with the device identity still present.
14:24The device checks in and processes the retirement action.
After 14:24The investigation checks whether fresh access continues and what Conditional Access actually requires.
The suspicious-looking 14:17 event was no longer “access after retirement completed.” It was access after the retirement request but before confirmed client processing.
Follow the actual device ID
Names can be recycled, devices can be rebuilt, and old records can remain in administrative views. Agent Foskett pivots on the device identifier recorded in the sign-in evidence rather than assuming that every record with a familiar display name represents the same object.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
let TargetDeviceId = "00000000-0000-0000-0000-000000000000";
SigninLogs
| where TimeGenerated > ago(7d)
| extend DeviceId = tostring(DeviceDetail.deviceId),
IsManaged = tostring(DeviceDetail.isManaged),
IsCompliant = tostring(DeviceDetail.isCompliant)
| where DeviceId =~ TargetDeviceId
| summarize FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated),
SignIns=count(),
SuccessfulSignIns=countif(ResultType == "0"),
Apps=make_set(AppDisplayName, 20),
Resources=make_set(ResourceDisplayName, 20)
by DeviceId, IsManaged, IsCompliant,
ConditionalAccessStatus
| order by FirstSeen asc
Why this matters: if the DeviceId changes, you may be looking at a new registration, a rebuilt endpoint or a sign-in with no device claim at all. Do not let the hostname do all the thinking.
Retired does not automatically mean every Microsoft 365 path is blocked
Device retirement and cloud access enforcement are related, but they are not the same control. Microsoft Entra Conditional Access decides whether a cloud sign-in satisfies the policies that apply to that user, application, device and session. If the organisation does not actually require a compliant or otherwise acceptable device for the resource being accessed, retirement alone should not be assumed to create an immediate universal block.
IntuneManages the device and issues the retire command.
Microsoft Entra IDRecords sign-in and device identity context.
Conditional AccessEnforces the cloud access requirements that are actually configured.
Hunt for successful sign-ins from non-compliant devices
Microsoft publishes a security-operations hunting pattern that looks for non-compliant device sign-ins where the overall Conditional Access status is successful. This is a useful investigation pivot when testing whether cloud access occurred from a device that no longer met the expected compliance state.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
SigninLogs
| where TimeGenerated > ago(7d)
| extend IsCompliant = tobool(DeviceDetail.isCompliant),
DeviceId = tostring(DeviceDetail.deviceId)
| where IsCompliant == false
| where ConditionalAccessStatus == "success"
| project TimeGenerated, UserPrincipalName,
AppDisplayName, ResourceDisplayName,
IPAddress, DeviceId,
ClientAppUsed, ConditionalAccessStatus
| order by TimeGenerated desc
Important: ConditionalAccessStatus == “success” does not mean a specific “require compliant device” control was necessarily enforced. Review the individual policies applied to the sign-in before deciding why access was allowed.
Platform behaviour matters
Retire does not have identical consequences on every operating system and enrolment type. Microsoft documents different outcomes for Windows, Apple and Android devices, including differences in management profile removal, Microsoft Entra device records, email behaviour and company data. That means the investigation must establish the platform and enrolment type before interpreting what “retired” should have done.
WindowsRetirement can remove Entra join or registration depending on the device state, with additional behaviour for Autopilot records.
Apple / macOSManagement profiles and managed configuration are removed, while Entra-record behaviour can differ by platform.
AndroidOutcome depends heavily on enrolment type, work profile and management model.
What the evidence can and cannot prove
SupportedMicrosoft 365 sign-in activity occurred after the retire action was requested.
Needs correlationWhether the client had actually processed retirement before that sign-in.
Do not overclaimA later sign-in does not by itself prove Intune failed or that Conditional Access was bypassed.
The investigation question changed
The original question was, “Why did a retired device still have access?” The evidence produced three better questions: Had the retire command actually completed? Was the sign-in really tied to the same device object? And did Conditional Access require a compliant or managed device for that resource in the first place?
Check completionSeparate the admin request from client-side processing.
Check identityCorrelate the device ID, not only the friendly name.
Check enforcementRead the Conditional Access result and the policies behind it.
Investigation findings
The retire action was realThe help desk had issued the correct device action.
The timing was the missing evidenceThe first post-retire-request access occurred before confirmed device processing.
The control boundary matteredIntune retirement and Microsoft 365 access policy had to be investigated separately and then correlated.
Related investigations
Continue following device identity, access state and Microsoft 365 evidence.
The User Was Disabled But The Account Was Still ActiveInvestigate why an administrative identity action and active cloud sessions are not always the same timeline.Microsoft Entra Conditional Access Device ConditionsUnderstand device identity, compliance and the claims evaluated during access decisions.The Password Was Never Stolen — The Browser Cookie WasFollow session evidence when authentication state outlives the assumption that created it.
Final thought
The device had been retired. The log showed Microsoft 365 access afterwards. Both statements were true — but they did not describe the same moment in the control lifecycle. Once Agent Foskett separated the retirement request, the client check-in, the device identity and the Conditional Access decision, the contradiction disappeared. The Logs Already Knew! 🔎
Retire clicked?Find when the endpoint actually processed it.
Device still appears?Match the immutable device identity and platform behaviour.
Access still succeeds?Read the Conditional Access policies that were actually evaluated.
