Stale Devices Are Killing Your Secure Score

Most tenants accumulate device inventory debt over time. Decommissioned VMs, test machines someone joined to Entra ID and never cleaned up, Windows 365 devices from a trial that ended months ago. They sit in Defender doing nothing except skewing your Secure Score.

I ran into this recently with a client. They had 200+ stale end-user devices that hadn’t checked in for months, plus a pile of ad-hoc VMs joined to Entra ID and then discarded. The interesting one was the AVD environment. An autoscale misconfiguration had been spinning up session host VMs and then deleting them without offboarding them from Defender first. The VMs were gone, but Defender still listed 30 to 40 of them as active devices.

What Stale Devices Actually Do to Your Secure Score

Secure Score evaluates recommendations against your full device inventory. If a device is in Defender, it counts. Devices that stopped syncing weeks ago won’t have current AV definitions, won’t appear compliant with onboarding policies, and will show as gaps in endpoint coverage.

Recommendations like “ensure all endpoints are onboarded” or “enable Tamper Protection on all devices” keep failing as long as ghost devices sit in your inventory. Remove them, and those recommendations either pass or stop applying altogether.

The core problem: Secure Score is only useful if the inventory behind it reflects reality. Stale devices inflate the denominator on recommendations you’ve already addressed, so your score looks worse than it actually is.

Finding Inactive Devices

In the Defender portal, go to Device Inventory and filter by:

• Last seen date. Anything not checked in for 30+ days is worth reviewing.
• Onboarding status. Filter for Inactive or Can be offboarded.
• Device name patterns. Particularly useful for AVD hosts, which typically follow a consistent naming convention.

In the autoscale scenario I mentioned, the host pool VMs had a consistent naming pattern, which made it straightforward to identify all the orphans in bulk.

Offboarding Devices Using API Explorer

The portal UI lets you offboard one device at a time. That works for a handful of devices, but not for clearing out 200+ in one go. The Defender for Endpoint API handles bulk operations, and API Explorer in the Defender portal gives you an authenticated way to call it without setting up a separate app registration.

Navigate to: security.microsoft.com → Settings → Endpoints → API Explorer

Step 1: Query Inactive Devices

Pull a list of inactive devices to get their IDs:

GET https://api.securitycenter.microsoft.com/api/machines
    ?$filter=healthStatus eq 'Inactive'

The response is a JSON array of device objects. The field you need is id, the device GUID. Grab the IDs for every device you want to remove.

Step 2: Offboard Each Device

POST to the offboard endpoint, substituting the device GUID:

POST https://api.securitycenter.microsoft.com/api/machines/{id}/offboard

// Request body
{
  "Comment": "Offboarding stale device - decommissioned"
}

Note: The Comment field is required and gets written to the audit log. Put something meaningful there. You’ll thank yourself during the next compliance review.

Step 3: Bulk Offboarding

For large batches, script the process. Query the device list, filter to your criteria, then loop through the IDs and POST each one. PowerShell with Invoke-RestMethod against the Defender API works well. For smaller batches, running each call directly in API Explorer is fast enough.

# PowerShell sketch - adapt to your auth method
$devices = (Invoke-RestMethod `
    -Uri "https://api.securitycenter.microsoft.com/api/machines?`$filter=healthStatus eq 'Inactive'" `
    -Headers $headers).value

foreach ($device in $devices) {
    Invoke-RestMethod `
        -Method POST `
        -Uri "https://api.securitycenter.microsoft.com/api/machines/$($device.id)/offboard" `
        -Headers $headers `
        -Body '{"Comment":"Offboarding stale device - decommissioned"}' `
        -ContentType "application/json"
    Write-Host "Offboarded: $($device.computerDnsName)"
}

Stopping It from Happening Again

A few things worth putting in place once the initial cleanup is done.

AVD lifecycle automation. If autoscale is deprovisioning VMs, add an offboard step to that workflow. A Logic App or Azure Automation runbook triggered on VM deletion handles this cleanly and stops orphans from accumulating.

Regular stale device reviews. Monthly or quarterly, filter Defender inventory for devices not seen in 30+ days and action them. Most will be straightforward to offboard.

Entra ID cleanup alongside Defender. Stale Defender devices usually have a matching stale Entra ID object. Clean both at the same time. The staleSignInAlertThreshold setting in Entra ID Access Reviews can flag these automatically.

Track the “Can be offboarded” count. Defender shows this in the device inventory summary. If it’s growing consistently, something in your lifecycle process isn’t closing the loop.

The Payoff

A cleanup run followed by some basic lifecycle hygiene gets your Secure Score back to something you can actually trust. Once the ghost devices are gone, you’ll often see recommendations flip from failing to passing immediately. Not because anything changed in your security posture, but because the denominator is finally accurate.

If you’re working through a similar cleanup or want to talk through the AVD autoscale offboarding pattern, feel free to reach out.