Intune wipe vs retire: which action to use, and the order that stops data being orphaned

Intune wipe vs retire is not a choice between two strengths of the same action. Retire strips organisational data, profiles and certificates and unenrols the device, leaving the user’s own files alone. Wipe is a factory reset. The decision that actually goes wrong is neither of those: it is Delete, which reads like a console tidy-up and which quietly issues a retire, or on some Android enrolments a full wipe, to the device itself. Here is what each of the five device actions removes, what each leaves behind in Entra ID and Autopilot, and the order to run them in.

None of this behaves the same way across platforms, and the asymmetries are where data gets orphaned. The same record hygiene problem turns up at the other end of the device lifecycle, which I covered in Autopilot device preparation.

The five actions at a glance

Intune wipe vs retire is a question about ownership

Pick the action from who owns the hardware, not from how badly you want the data gone.

On a personally owned device, retire is the only defensible choice. It removes the managed apps and their data, revokes and removes certificates, drops the Wi-Fi and VPN profiles, stops Intune policy being enforced, and on Windows removes Intune provisioned mail accounts along with EFS enabled mail sitting in the Mail app. Personal photos, personal apps and personal documents are left alone. Microsoft frames it as removing company data without performing a full wipe or factory reset, and the retire documentation carries the per-platform tables that say what that means on each OS.

On a corporate device you are reissuing or disposing of, wipe. Two checkboxes on the Windows wipe dialog are worth understanding before you press it. Wipe device, but keep enrollment state and associated user account leaves the machine enrolled with its primary user attached, which is what you want when the same person is keeping it and you are only clearing a broken software state. Wipe device, and continue to wipe even if device loses power is what you want when the hardware is leaving the building, because a wipe interrupted by a flat battery can otherwise leave a half reset machine that still holds data. The wipe documentation lists both, plus the eSIM data plan option on iOS/iPadOS and the two ChromeOS modes.

Retire needs Help Desk Operator, School Administrator, or a custom role carrying Remote tasks/Retire. Wipe needs Remote tasks/Wipe. Delete is different again: School Administrator, Endpoint Security Manager, or Managed devices/Delete. An operator who can retire cannot necessarily delete, which is usually the right split.

Delete is not a console tidy-up

This is the one that catches people, and most of the comparison articles currently on page one either skip Delete or describe it as the option that leaves the device untouched.

It does not leave the device untouched. Per the delete device documentation, the action triggers a retire command on Windows at any enrolment type, on macOS at any enrolment type, on Apple mobile at any enrolment type, and on Android device administrator and BYOD. On Android corporate owned fully managed, dedicated, corporate owned work profile and AOSP enrolments it triggers a wipe.

So on a corporate Android estate, Delete factory resets the handset. That is a materially different outcome from the same button on a Windows laptop, and the console gives you a near identical confirmation dialog for both.

What each action leaves behind

The device is only half the cleanup. Three records outlive most of these actions, and each has to be handled separately.

Microsoft states the wipe case plainly and points you at stale device management in Entra ID and at deregistering from Windows Autopilot as two separate jobs you still have to do. Neither happens on its own.

Two consequences worth stating flatly. First, on a Windows Entra joined device, once retire has run you cannot sign in with a Microsoft Entra account. If the user still needs that machine, they need a working local account before you press the button, not after. Second, retire on Windows does not remove Microsoft 365 Apps, and it does not uninstall Win32 apps deployed by the Intune management extension once the device is unenrolled. Retire is not an uninstall pass.

Stale Entra device records are not cosmetic either. They sit in device based filters and can keep a decommissioned machine inside the scope of a policy long after it has gone, which is one of the reasons I put record hygiene into the design checks in Conditional Access policy design.

Fresh Start and Autopilot Reset

Both are Windows only, and both are narrower than their names suggest.

Fresh Start removes apps from a managed Windows device. Its actual purpose is stripping OEM preinstalls off a new PC. With Retain user data on this device selected, the machine stays Entra joined, re-enrols in MDM automatically when an Entra enabled user signs in, and the contents of the user’s Home folder survive. Apps and settings do not. Leave it unselected and the device returns to the default out of box experience completed state, keeping the built-in administrator account, and a BYOD device is removed from Entra ID and from MDM. Fresh Start needs Remote tasks/Clean PC on a custom role. As of today it carries no deprecation notice.

Autopilot Reset is the reissue action. It removes user data, settings and apps, then reapplies the configuration the device is assigned, keeping the Entra join and the Intune enrolment rather than sending the machine back through enrolment from scratch. Wi-Fi connection details, previously applied provisioning packages, provisioning packages held on a USB drive, the Entra device membership and MDM enrolment information, and SCEP certificates all survive the reset. That is the point of it: same identity, clean state.

Driving it from Graph

Both actions are single POSTs with no meaningful response body, which makes bulk offboarding straightforward and bulk mistakes equally straightforward. Both need DeviceManagementManagedDevices.PrivilegedOperations.All, delegated or application, and both return 204 No Content on success.

# Retire: unenrol and remove company data. No request body. Returns 204.
POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{managedDeviceId}/retire

# Wipe: factory reset. keepEnrollmentData and keepUserData map to the two
# Windows checkboxes. macOsUnlockCode is the six digit recovery PIN required
# on Macs without a T2 chip. Returns 204.
POST https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/{managedDeviceId}/wipe
Content-Type: application/json

{
  "keepEnrollmentData": false,
  "keepUserData": false,
  "persistEsimDataPlan": false
}

A 204 means Intune accepted the command, not that the device did anything. On a co-managed estate it is also worth confirming which authority owns the workload before you fire either of these, because the console will happily accept a command the device will not honour. I set out that split in co-management as a valid end state.

The order that matters

1. Decide from ownership. Personally owned means retire. Corporate and leaving the estate means wipe.
2. Confirm the device is actually reachable before you send anything. A command issued to a device that will never check in again is a false record of a cleanup that did not happen.
3. Run retire or wipe, and wait for it to report complete. The device may keep appearing in the admin centre until it next checks in.
4. Only then delete the Intune record. Deleting first destroys the record the queued command needs.
5. Clean up the Entra device record separately. After a wipe, and after a retire on iOS, iPadOS, macOS or an Autopilot registered Windows device, it is still there.
6. Deregister from Windows Autopilot last, and only if the hardware is genuinely leaving. If it is being reissued internally, that registration is the thing you want to keep.

The failure modes

Autopilot Reset silently is not an option on hybrid joined devices. Microsoft is explicit: Windows Autopilot Reset does not support Microsoft Entra hybrid joined devices or Surface Hub devices, and both need a full device wipe instead. A hybrid device that has been fully reset can take up to 24 hours before it is ready to be deployed again, which is not a delay you want to discover on the morning of a reissue.

Autopilot Reset fails with ERROR_NOT_SUPPORTED (0x80070032). The Windows Recovery Environment is not correctly configured or not enabled. WinRE is a prerequisite, and imaging pipelines that strip it produce exactly this.

Local Autopilot Reset does nothing on the lock screen. It is disabled by default. You enable it through the CredentialProviders/DisableAutomaticReDeploymentCredentials CSP, which in Intune means a Device restrictions profile with Autopilot Reset set to Allow.

A Samsung device fails the wipe and then goes dark. If Factory Reset is set to Block in a Device Restrictions policy, the wipe action causes the device to lose contact with Intune and fail. You have to lift the restriction before the wipe, not after, because afterwards you have no channel to lift it through.

A Zebra device reports success but is not factory reset. On Zebra Android, wipe removes corporate data only. A true reset needs Zebra StageNow or the OEMConfig Data Wipe path.

A wiped ChromeOS device re-enrols itself. It has to be deprovisioned before the powerwash, otherwise it auto-enrols the moment it sees Wi-Fi.

A Mac cannot be unlocked after a remote wipe. Devices without a T2 chip, broadly 2018 and earlier or macOS 10.14 and earlier, need a six digit recovery PIN, the macOsUnlockCode. Record it somewhere durable at the moment you issue the wipe.

Nothing appears to happen at all. Retire and wipe are queued and delivered at the next check-in, and the action may additionally be held by an Intune access policy requiring Multiple Administrative Approval. Before assuming the command failed, rule out the check-in itself: the diagnosis order is in Intune device not syncing, and the mechanics of a manual sync are in forcing an Intune sync.

What I would do differently

I have not run a bulk offboarding against a production estate, and I am not going to pretend otherwise. My tenant is a lab with no enrolled fleet behind it, so what follows is judgement about the documented behaviour rather than a war story.

The change I would make to most offboarding runbooks is to stop treating Delete as the last step and start treating it as a separate decision with its own approval. Every other action on this list is reversible in the sense that you can re-enrol, re-register and rebuild. Delete is the one that removes your ability to observe whether the cleanup worked. Running it before the device has confirmed the retire converts a recoverable situation, a device that still has certificates on it, into an invisible one.

I would also split the roles. Remote tasks/Retire and Remote tasks/Wipe belong with the service desk. Managed devices/Delete does not. The default reflex of granting one operator all three is what turns a mis-clicked row into a factory reset with no record left of which device it was.

And on corporate Android specifically, I would rename the runbook step. Calling it “delete the stale record” is accurate on Windows and dangerously wrong on COBO, COSU, COPE and AOSP, where the same word means factory reset the handset.

Last verified: 16 August 2026, against Microsoft Learn.