Every January I go through customer Intune tenants, and the same problem shows up almost every time. The device lists are full of outdated, unused or duplicate entries. Devices that haven't checked in for ages, old test hardware, even laptops that were retired long ago still have active records in Intune or Entra ID. Poor device hygiene is more than clutter. It causes real security and operational trouble, especially when Conditional Access and BitLocker recovery rely on accurate device objects. So for me, "Intune device cleanup" is a practical job I do at the start of every year.

Clean-up rules and compliance settings do most of the work in Intune

Intune has a useful tool for automated cleanup that people tend to overlook: Device clean-up rules (Intune admin center → Devices → Organize devices → Device clean-up rules). There you define how many days a device can stay inactive before Intune removes it automatically. The window ranges from 30 to 270 days. In most environments I've had good results with 90 to 180 days. Go too short and you lose devices that are rarely used but still valid. Go too long and the junk keeps piling up. If you want the details, Microsoft's docs on device clean-up rules are a good reference.

There's a second setting I always check. Under Endpoint security → Device compliance → Compliance policy settings you can have devices without an assigned compliance policy marked as "not compliant" automatically. That closes the gap where unmanaged or forgotten devices show up as compliant and quietly weaken Conditional Access. Also look at the compliance status validity period. If it's set too long, old devices can keep appearing compliant even after months of inactivity. The compliance policy documentation has more guidance.

Stale devices in Entra ID need their own cleanup

When you delete a device from Intune, it stays in Entra ID. The result is orphaned or duplicate device objects in the directory. That becomes a real problem if you use Conditional Access device filters (like "device.state == 'enabled'") or store BitLocker recovery keys on device objects.

In the Microsoft Entra admin center → Devices → All devices you can filter on the "Activity" column and quickly find devices that haven't been active for months. If you prefer PowerShell, the Microsoft Graph PowerShell module can query the ApproximateLastSignInDateTime property:

# Prerequisite: Microsoft Graph PowerShell, Device.Read.All permission
Connect-MgGraph -Scopes "Device.Read.All"
Get-MgDevice -All | Where-Object { $_.ApproximateLastSignInDateTime -lt (Get-Date).AddDays(-180) } | Select DisplayName, DeviceId, ApproximateLastSignInDateTime

You get a list of device objects that haven't been used in 180 days. Microsoft also has a good overview on managing stale devices.

Stale device objects can undermine Conditional Access

A lot of admins underestimate what leftover device objects mean for security. If a device is removed from Intune but not from Entra ID, its object may still look compliant to Conditional Access filters, particularly with filters like "device.state" or compliance claims. I've worked in environments with strict CA policies where ancient, untrusted device objects still got through, simply because nobody had ever cleaned up their Entra entries. Regular device cleanup isn't about keeping things tidy. Without it, you can't really trust your security posture.

Practical tip: Only delete orphaned device objects in Entra ID after checking for BitLocker recovery keys, app registrations, or other linked resources. Otherwise, critical recovery data could be lost.

Deleting device objects can take BitLocker keys with them

When you delete a device object in Entra ID, any BitLocker recovery keys attached to it are deleted too. If the keys were never escrowed properly, or the only copy sits on a "dead" device object, that can go very wrong. Before I remove anything, I check for attached BitLocker keys or attributes. Export them if you need to, and confirm with the helpdesk or the device owners. It's tedious, but you can't skip it, least of all in environments where the BitLocker rollout was inconsistent in the past.

A flowchart shows where device data lingers

This simple diagram shows how Intune, Entra ID and Conditional Access interact during device cleanup:

flowchart TD
    DeviceRegistered["Device registered"]
    InIntune["In Intune"]
    InEntra["In Entra ID"]
    Inactive["Device inactive"]
    IntuneCleanup["Intune clean-up removes device"]
    EntraRemains["Entra ID object remains"]
    CAFilter["CA filter sees orphaned device"]
    BitLockerKeys["BitLocker keys on object"]
    ManualCheck["Manual check/removal in Entra ID"]

    DeviceRegistered --> InIntune
    InIntune --> InEntra
    InEntra --> Inactive
    Inactive --> IntuneCleanup
    IntuneCleanup --> EntraRemains
    EntraRemains --> CAFilter
    EntraRemains --> BitLockerKeys
    EntraRemains --> ManualCheck

Figure: Device lifecycle in Intune and Entra ID, showing where data lingers and how that affects Conditional Access.

My workflow cleans up carefully and in a fixed order

This is the approach that has worked best for me:

  • Turn on device clean-up rules in Intune first and tune the inactivity window.
  • Configure the compliance policy settings so devices without policies are marked "not compliant", and pick a sensible compliance status validity period.
  • Look for stale devices in Entra ID on a regular basis (portal or PowerShell), and only delete them after checking for sensitive data.
  • Put device cleanup on the IT calendar as a recurring task, for example quarterly.

If you stick to this, your device inventory stays reliable, compliance actually means something, and old device objects don't turn into a backdoor past Conditional Access. For more on Conditional Access best practices, read my post Conditional Access in Microsoft Entra ID: The First Policies Every Tenant Needs.