Decommissioning Windows Devices in Intune: Retire, Wipe, Cleanup

Answer first: Choose Retire for supported selective corporate-data removal and Wipe for a factory reset, then verify each asynchronous action before cleaning up records in Microsoft’s order: delete the device from Intune, then deregister it from Windows Autopilot

Related KBY guidance: verify BitLocker recovery-key escrow before decommissioning.

#Operational requirement

Hardware refreshes and leaver offboarding generate a recurring, unglamorous task: taking a Windows device out of active management without leaving orphaned objects behind. This is usually one of the first real production assignments handed to a new endpoint engineer — “decommission these fourteen laptops from the finance floor refresh” or “process this leaver’s device by Friday”. It looks trivial. It is not.

Get the sequencing wrong and you produce one of three production incidents. First: you issue a full Wipe against the wrong serial number and destroy a working device’s local data with no way to recover it, because Wipe is irreversible by design. Second: you Retire a device and remove it from Intune but forget to delete the Windows Autopilot device identity, so when that laptop is reimaged and handed to the next starter, Autopilot enrolment fails or silently reapplies the departed user’s old deployment profile. Third: on a hybrid-joined estate, you clean up Intune but leave the on-prem AD computer object in place, so Entra Connect keeps resyncing a stale device record that a security audit will flag months later as an unaccounted-for endpoint.

This runbook walks a junior administrator through the correct decommission sequence: inventory and confirm, obtain change approval, execute the correct removal action (Retire versus Wipe), delete the device from Intune, deregister it from Windows Autopilot, clean up any hybrid AD remnants, and produce verifiable evidence that the device is retired from every system of record. Follow it step by step; do not skip the confirmation steps because the ticket seems routine.

#Prerequisites and required permissions

• An Entra ID account assigned the Intune Administrator role, or a custom Intune RBAC role granting Managed Devices “Delete” and “Wipe” permissions.
• Entra ID Cloud Device Administrator role, or equivalent, to remove device objects.
• Microsoft Graph PowerShell SDK installed on your admin workstation:

Install-Module Microsoft.Graph -Scope CurrentUser

• Graph delegated scopes: DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.ReadWrite.All, Device.ReadWrite.All, and DeviceManagementServiceConfig.ReadWrite.All for Autopilot identity deletion.
• An approved change record in your service management tool — bulk device wipe actions should never proceed on a verbal request alone.
• Confirmation that user data preservation, such as OneDrive Known Folder Move, has already completed, or an explicit written sign-off that no data preservation is required, for any device going through Wipe rather than Retire.
• Read access to your asset register so serial numbers can be cross-checked before any destructive action is issued.

#Step 1: Inventory and confirm device identity

Before touching anything, pull the exact managed device record and confirm you have the right hardware. Serial numbers and device names get transposed in spreadsheets constantly — this is the single most common cause of the “wrong device wiped” incident, and it is entirely preventable with one extra query.

1Connect-MgGraph -Scopes "DeviceManagementManagedDevices.PrivilegedOperations.All","DeviceManagementManagedDevices.ReadWrite.All","Device.ReadWrite.All"
2
3Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'FIN-LT-0231'" | Select-Object Id, DeviceName, SerialNumber, UserPrincipalName, ManagedDeviceOwnerType, EnrolledDateTime, LastSyncDateTime, ComplianceState

Expected result: a single device record returned with a serial number matching your asset register. Evidence to capture: export this record into the change ticket before proceeding. Checkpoint: if ManagedDeviceOwnerType shows personal, stop. BYOD devices go through a Retire, never a full Wipe, and require a separate consent conversation with the user.

#Step 2: Confirm data preservation

For corporate-owned devices going to full Wipe, verify OneDrive sync health for the assigned user, or obtain explicit written confirmation from the requesting manager that no data preservation is needed. Record the confirmation reference number in the ticket. This step exists because Wipe with keepUserData set to false is destructive, and Microsoft does not offer a recovery path from the managed-device side once the command has processed.

#Step 3: Raise and approve the change

Log a standard change with the device list, the action per device (Retire or Wipe), and a rollback plan attached. For batches larger than five devices, route the request through your change advisory board or equivalent lightweight approval. This is not because the technical risk is high; it is because the blast radius of a scripting mistake against the wrong device group is large enough to justify a second pair of eyes on the filter logic before execution.

#Step 4: Execute the correct removal action

Retire and Wipe are not interchangeable. Use the decision table below before issuing either command.

Before you Retire a Microsoft Entra joined device, back up its BitLocker recovery key and local administrator account credentials. Microsoft lists both as critical data that may be lost in the process, and says a Retire removes the device’s Entra ID record unless the device is registered in Autopilot. This backup

Issue the action via Graph:

1$deviceId = (Get-MgDeviceManagementManagedDevice -Filter "deviceName eq 'FIN-LT-0231'").Id
2
3# Wipe example
4Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$deviceId/wipe" -Body (@{ keepEnrollmentData = $false; keepUserData = $false } | ConvertTo-Json)
5
6# Retire example
7Invoke-MgGraphRequest -Method POST -Uri "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$deviceId/retire"

Expected result: HTTP

#Step 5: Remove the Windows Autopilot device identity

First, delete the device from Intune. Microsoft’s order is fixed: a device has to be deleted from Intune before it can be deregistered from Windows Autopilot. In the Intune admin centre, go to Devices, then Windows, select the device, note its serial number, and select Delete. Only then remove the Autopilot identity below.

This step is skipped constantly, and it is the reason reissued hardware breaks on the next starter’s first day. If the Autopilot identity remains registered, the next enrolment attempt either fails outright or silently reapplies the previous deployment profile and Enrollment Status Page settings.

1$autopilotDevice = Get-MgDeviceManagementWindowsAutopilotDeviceIdentity -Filter "contains(serialNumber,'PF3XK912')"
2Remove-MgDeviceManagementWindowsAutopilotDeviceIdentity -WindowsAutopilotDeviceIdentityId $autopilotDevice.Id

Expected result: the serial number no longer appears under Devices, Enrollment, Windows Autopilot Devices in the Intune admin centre. Evidence: a before-and-after screenshot of the Autopilot device list. Checkpoint: if the hardware was purchased through a reseller with Autopilot registration tied to the OEM, deletion here only removes the tenant assignment. The hardware hash itself may need re-registration on next enrolment, which is expected and not a fault.

#Step 6: Clean up hybrid AD remnants, and leave an Autopilot device’s Entra ID object alone

If the device is registered with Windows Autopilot, don’t delete its Entra ID device object by hand. Microsoft’s Autopilot guidance is that, for Microsoft Entra joined devices, no further steps are needed after deregistering the device from Windows Autopilot through Intune, and that manual deletion from Entra ID should be avoided unless a specific scenario requires it: the Autopilot deployment process relies on that object, and deleting it can cause enrolment failures. Microsoft notes the object can remain in Entra ID after deregistration.

For a device that isn’t registered with Autopilot, Microsoft’s Wipe guidance is different: after the action, you might also want to remove its record from Entra ID. It points to its guidance on managing stale devices in Microsoft Entra ID for how to do that. If the action was a Retire and the device is Microsoft Entra joined, Microsoft’s Retire guidance says the Retire itself removes that record, which is why Step 4 has you back up the BitLocker recovery key and local administrator credentials before retiring it.

If the device is Microsoft Entra hybrid joined, delete its computer object from on-premises Active Directory so that it isn’t resynced to Entra ID. Before you do, back up any BitLocker recovery key for the device that is stored in Active Directory and that you might still need. Microsoft says that recovery information is stored in a child object of the computer object itself, and that old recovery keys aren’t removed automatically from AD DS unless the computer object is deleted. This backup step and the command below have not been tested for this guide, including on a computer object that holds BitLocker recovery information:

Remove-ADComputer -Identity "FIN-LT-0231" -Confirm:$false

Finally, unassign the Microsoft 365 licence from the associated user if this decommission is tied to a leaver, so the seat is reclaimed on the next billing cycle rather than left consumed indefinitely. Log this action separately, as licence reconciliation is often audited independently of device cleanup.

#Verification

• Intune admin centre: device no longer listed under Devices, All devices.
• Autopilot device list: serial number absent.
• Entra ID: for an Autopilot device, the object may still be listed; Microsoft notes it can remain after deregistration. Don’t delete it by hand (Step 6). For a hybrid-joined device, it shouldn’t be resynced once the on-prem computer object is gone.
• Hybrid AD, where applicable: computer object absent from the relevant organisational unit.
• Licence report: seat reassigned or returned to the available pool.
• Change ticket: closed with all screenshots and command output attached, referencing the original change record.

Cross-check the Entra ID audit log for the Delete device and Retire device events to confirm the actions were performed under your account and not duplicated by another administrator working the same batch. For recurring monthly refresh cycles, build a small dashboard query that lists devices marked for decommission against devices still appearing in Intune after seven days, so stalled offline devices surface automatically rather than being forgotten.

#Failure Modes

#Rollback

Treat a submitted Retire action as asynchronous but not safely reversible. Confirm the device action state in Intune; do not promise cancellation. If Retire has processed, restore management only through the approved enrolment path and reapply the device baseline. If the device has not checked in, escalate to the Intune owner before issuing any competing action.

Wipe actions cannot be rolled back once the device has processed the command. That is the entire point of Wipe. There is no vendor-supported reversal. Your rollback plan for a mistaken Wipe is: re-enrol the device through Autopilot or manual enrolment, reassign the user’s configuration profiles and app assignments from your baseline group, and restore any user data from the last known OneDrive or backup snapshot. Document the incident regardless of whether data was recoverable, and note the timestamp of the original mistaken command for the post-incident review.

If you deleted the wrong Autopilot identity, re-register the device using the hardware hash captured from Get-WindowsAutoPilotInfo, upload it via the Intune admin centre or partner portal, then reassign the correct deployment profile before returning the device to the field.

#Operational Summary

The deliverable for this task is a fully decommissioned device (deleted from Intune, deregistered from Windows Autopilot and, where hybrid-joined, removed from on-prem AD, with an Autopilot device’s Entra ID object left in place rather than deleted by hand) and a closed change ticket carrying command output, timestamps and before-and-after screenshots as evidence. Practise the full sequence on a single test device in a lab tenant before running it against a production batch: create a test managed device object, run all six steps, and confirm Intune, Autopilot and, where applicable, on-prem AD show the device as gone. That one successful dry run, captured in your own notes, is what tells your manager you are ready to run this against a real hardware refresh without supervision.

Treat the Retire-versus-Wipe decision as a data-protection decision, not a technical one. The moment you issue a Wipe, the outcome is final, so the discipline in this runbook is entirely about verifying identity and intent before the irreversible step, not about the mechanics of the API call itself. A newly hired engineer who can run this sequence cleanly, with evidence, on the first attempt has demonstrated exactly the kind of careful, verifiable operational discipline that endpoint management teams depend on.

Correction, 18 September 2026: earlier versions of this guide told you to delete an Autopilot device’s Entra ID object by hand, to remove the Autopilot identity without first deleting the device from Intune, and to Retire rather than Wipe a lost or stolen device. Each contradicted Microsoft’s documentation, and the steps above now follow it. The corrected steps have not been tested in a tenant. A worked example built on the Retire-first advice has been removed. Later the same day, the advice not to delete the Entra ID object by hand was limited to devices registered with Autopilot, as Microsoft’s guidance is. A further revision the same day added two things the guide had left out. The guide suggested removing a device’s Entra ID record after a Retire, but Microsoft’s documentation says a Retire itself removes the record of a Microsoft Entra joined device unless it is registered in Autopilot, and says to back up its BitLocker recovery key and local administrator credentials before retiring it. The guide also told you to delete a hybrid-joined device’s on-premises computer object with no backup of any BitLocker recovery keys stored in Active Directory, which Microsoft says sit in a child object of the computer object. Steps 4 and 6 now say to back these up first. These additions have not been tested in a tenant.