Stale devices in Intune: the cleanup nobody schedules

Nobody argues with a compliance rate. It is one number, it is green, and it goes in the monthly report. What it rarely says is how many of the devices in the denominator have spoken to Intune this quarter — because a device that stopped checking in doesn't leave the list. It keeps the state it had on the day it went quiet, and quietly props the number up. Below are the six questions that come up the first time somebody tries to fix it.

How long is "stale"?

It depends which clock you read, and the two clocks disagree by design.

Intune's is exact. Every managed device carries lastSyncDateTime, documented as the date and time the device last completed a successful sync with Intune, and it supports the lt and gt filter operators — so "everything that hasn't reported since March" is one query, not an export and a spreadsheet.

Microsoft Entra's is deliberately blunt. The device object's activity timestamp is only rewritten when the gap between the stored value and now is more than 14 days (+/-5 day variance). It exists for lifecycle decisions, not for auditing. Which is why the same page tells you not to treat a timestamp younger than 21 days as evidence of anything — and warns that some active devices may have a blank time stamp. A threshold of 30 days will hand you a list containing everyone who took a long holiday. Ninety days is the number you can defend in a meeting.

Why does the compliance rate go up when devices go dark?

Because compliance is something a device reports, not something the service computes on your behalf between check-ins. The complianceState property has seven documented values — unknown, compliant, noncompliant, conflict, error, inGracePeriod and configManager — and none of them means "we haven't heard from this one since March". A laptop that was compliant on its last sync stays compliant in the list, indefinitely, with no flag to say the assessment is eight months old.

Grace periods stretch the same gap on purpose. Every compliance policy includes Mark device noncompliant as a built-in action scheduled to trigger immediately at zero days, but that schedule is editable to anything from 0 to 365 days, and while it runs the device sits at inGracePeriod with a date in complianceGracePeriodExpirationDateTime. Set it generously once, forget it, and a device can hold a non-failing status for a year without being healthy for a minute of it.

Does deleting a stale device give me a licence back?

Usually not, and it's worth knowing why before someone builds a business case on it. Intune is licensed per user — a licence is required for any user or device that benefits directly or indirectly from the service — so removing one of a person's three enrolled devices returns nothing. The exception is the device-only subscription, which covers kiosks, dedicated devices and other unaffiliated hardware enrolled through Autopilot self-deploying mode, Apple ADE without user affinity, Android Enterprise dedicated or a device enrolment manager account. Those seats are assigned against estimated usage, so a retired kiosk that nobody deleted is genuinely holding one.

The larger saving is one table over. A user whose every device has been dark for a quarter, still holding an E5, is a dormant account wearing a device inventory as camouflage — and that one does show up in the licence waste audit.

Which record am I actually deleting?

There are at least two, and deleting one does not delete the other. The Intune Delete action removes the device from management and hides it from the admin center immediately; underneath, it always triggers a Retire on Windows, macOS and Apple mobile, and a Wipe on Android corporate-owned enrolments. The Entra device object survives all of that, which is why Microsoft's own page ends by telling you to go and remove it separately.

What breaks if I delete the wrong one?

Three things, all of them unpleasant and none of them reversible.

BitLocker. Recovery keys for Windows 10 and newer are stored on the Entra device object; delete the object and the keys go with it, with no way to recover them afterwards. Retiring or deleting the Intune record for an Entra joined device also removes key protectors and suspends BitLocker on the OS volume as a safeguard. Autopilot. Deleting an Entra device that was associated with an Autopilot object breaks the pairing: self-deploying and pre-provisioning deployments then fail by design, because the service can't find the device it expects. Don't delete system-managed devices at all. Hybrid join. Delete a Windows 10 or newer device only in Entra and Connect resynchronises it as a new object in Pending, requiring re-registration on the client. Do it in on-premises AD and let the sync carry the change.

How do I run this without wrecking a Friday?

The part that doesn't fit in a runbook is noticing early. Stale devices arrive one at a time, and the surface that would show them — a count of devices not seen in 30, 60 and 90 days, next to the compliance rate rather than buried under it — is exactly the view no admin center puts on one screen. GraphPaaS collects the device inventory per tenant on a schedule and keeps it, so the last-sync distribution is a trend you watch drift instead of a discovery you make during an audit.