Guides  ·  5 min read

Intune wipe: Purge or Clear? It depends on encryption, not the OS

Two Windows laptops go through the same Intune wipe action this afternoon. One comes back with a certificate stating NIST 800-88 Purge. The other states Clear. Same action, same console, same click. The difference is not the OS build or the Intune policy. It is whether BitLocker was on.

Most offboarding checklists treat "Intune wipe sent" as one event with one meaning. It is not. Intune's wipe action tells the device to run its own built-in reset: Reset This PC on Windows, Erase All Content and Settings on iPhone and iPad, a factory reset on Android, and an erase on a Mac. Intune does not run a separate sanitization method on top of that reset. What the reset achieves on the drive depends on the state the device was in when it ran.

Where NIST 800-88 draws the line

NIST SP 800-88 Rev. 2 defines three sanitization methods: Clear, Purge and Destroy (Sec. 3.1). Clear protects against simple, non-invasive recovery through the same interface the user has, and Rev. 2 accepts a manufacturer reset as a Clear technique where rewriting is not supported, as long as the device interface does not allow the original data to be retrieved (Sec. 3.1.1). Purge makes recovery infeasible even with state-of-the-art laboratory techniques (Sec. 3.1.2). Cryptographic erase, which sanitizes the keys that encrypted the data, is a Purge technique (Sec. 3.2).

So the line falls at the encryption key. If the reset discards the key of a volume that was encrypted, that is a cryptographic erase, and the classification can be Purge. If the volume was never encrypted, a reset is at best Clear. That is the logic WipeCert applies to every Intune wipe, platform by platform, using the encryption state Intune reports for the device.

Platform by platform

• iPhone and iPad: every wipe is classified Purge. Erase All Content and Settings discards the file-system encryption keys, and storage on supported devices is always encrypted.
• Android: Purge only when Intune reports the device as encrypted. Otherwise the certificate states Clear, and the dashboard warns before you send the wipe that it is a factory reset, not a cryptographic erase.
• macOS: Purge only when Intune reports FileVault as enabled. Otherwise Clear, with the same kind of warning.
• Windows: Purge only when Intune reports BitLocker as enabled; the reset discards the volume encryption key. Without BitLocker the certificate states Clear and records that no drive-level sanitization was performed. Before you send it, the dashboard warns that data may be recoverable from the drive and recommends booting the WipeCert ISO or PXE image on that device for drive-level sanitization.
• Anything else: if WipeCert cannot tell the platform from what Intune reports, it does not guess. The certificate states Clear rather than assuming the better case.

The Intune page in the WipeCert dashboard shows which result each device will get before you queue anything, so the Clear devices are visible while there is still time to handle them another way.

The catch with BitLocker recovery keys

Even when a Windows wipe is classified Purge, BitLocker recovery keys backed up to Microsoft Entra ID are not removed by the wipe. They are deleted when the device object is deleted from Entra ID, which is a separate step. A drive can be correctly classified Purge while the organization still holds a working recovery key for it in the directory.

NIST takes that seriously. Rev. 2 says cryptographic erase should not be trusted on media whose keys have been backed up or escrowed unless the organization has a high level of confidence about how and where those copies are stored and managed (Sec. 3.2.2). WipeCert certificates issued under Rev. 2 say so in plain words: for an Intune wipe, the Purge method is met only when no copy of the key exists outside the device. We cover that gap, and the opt-in setting that closes it, in The BitLocker key Intune leaves behind after a wipe.

What the certificate verifies, and what it does not

The certificate is specific about its own evidence. Its verification statement says that verification is the MDM action state Microsoft Intune reported, and that WipeCert did not read the storage medium. That matches how Rev. 2 describes verification for logical techniques: checking the completion status of the tools and identifying errors and anomalies (Sec. 4.5.1). Intune tells us the reset ran and what it reported about encryption. Nobody outside the device read the drive afterward, and the certificate does not pretend otherwise.

Offline devices and ticketing

A wipe queued through Intune does not always run the moment you click it. If a laptop is offline, Microsoft holds the action. WipeCert keeps checking for up to 30 days, so a device that reconnects on day three still gets its certificate instead of sitting in the record as a failure. If the device never comes online in those 30 days, WipeCert stops waiting, marks the wipe failed, and tells you to check the device in Intune before assuming the data is intact.

On Professional and higher plans, a completed or failed wipe can also send a signed webhook to your own system. The completed event carries the certificate number, so a ticketing tool can attach it to the offboarding ticket without anyone checking two consoles.

What this replaces

None of this replaces an offboarding checklist. It replaces the line on that checklist that used to be a guess: whether "we wiped it in Intune" was a Purge or only a Clear, and whether the recovery key in your directory needs its own cleanup step. For why a console status is not proof on its own, see Intune retires the device. It does not prove the drive was sanitized. For how the integration works end to end, see the Microsoft Intune integration page.

The free trial includes two wipes and needs no card. The Intune connection is the Intune Add-On, available on any paid plan and included with Enterprise, and new customers can request a 30-day Intune pilot.