Architectural Perspective: What Each Erase Option Actually Does

Intune provides four primary options for erasing data from devices. Each serves a distinct purpose and operates differently at the platform level. Understanding what each option touches — and what it deliberately leaves behind — is the starting point for any serious data governance posture.

Retire

The Retire action unenrolls a device from Intune management. It removes Intune-managed policies, profiles, and company app data, but it leaves user data, personal applications, and locally stored files intact. On a corporate-owned device, this is rarely the right choice for decommissioning. On a BYOD device, it is the appropriate action because removing personal data would be both legally problematic and outside the scope of corporate authority.

The critical detail: Retire does not remove data that was synced to OneDrive or SharePoint before the action was triggered. If a user had been syncing sensitive files to a personal OneDrive account, those files remain accessible after the device is retired.

Wipe

The Wipe action is the most commonly misunderstood option. It removes user data, settings, and applications, and it retains the operating system and — depending on configuration — the device enrollment state. Administrators can configure Wipe to retain the enrollment profile so the device re-enrolls automatically after reset, which is useful for shared device scenarios.

What Wipe does not do: it does not cryptographically erase the drive. On devices encrypted with BitLocker, the encryption keys may still reside in the device's Trusted Platform Module (TPM) or in Microsoft Entra ID (formerly Azure AD) as escrowed recovery keys. The data blocks on disk are overwritten by the OS reinstallation process, but the recovery key in Entra ID remains until an administrator explicitly removes it. If that key is not purged, a determined actor with physical access and the recovery key can potentially access residual data.

Fresh Start

Fresh Start removes most third-party applications and reinstalls Windows, updating the device to the latest version in the process. It retains user files stored in the user profile by default, though administrators can configure it to remove user data. This option is designed for performance remediation scenarios — a device that has become bloated or misconfigured — not for decommissioning.

The retention of user files is the operational trap here. Administrators who reach for Fresh Start when they mean to fully wipe a device will leave behind everything in the user's profile folder, including locally cached credentials, browser data, and any files not synced to cloud storage.

Reset (Autopilot Reset)

Autopilot Reset restores the device to a business-ready state while keeping it enrolled in Intune and joined to Entra ID. It removes user-installed applications and user data but preserves the device's identity and management configuration. This is not a data destruction tool — it is a reprovisioning tool. Using it in a decommissioning workflow is an architectural error.

Operational Impact: Where Residual Data Lives After a Wipe

The operational risk is not just theoretical. Residual data surfaces in predictable locations, and each one requires a deliberate remediation step that Intune's built-in actions do not automatically trigger.

BitLocker Key Persistence in Entra ID

When a device is enrolled in Intune and BitLocker is enforced via policy, the recovery key is escrowed to Entra ID. After a Wipe or Reset action, that key remains in the Entra ID portal under the device record until the device record is deleted or the key is manually removed. An administrator with sufficient permissions can retrieve that key and use it to unlock a drive that was supposedly wiped.

Administrators can audit and remove BitLocker recovery keys using PowerShell:

Connect-MgGraph -Scopes "BitlockerKey.Read.All", "BitlockerKey.ReadBasic.All"

$deviceId = "<Entra-Device-Object-ID>"
Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '$deviceId'" | 
    Select-Object Id, CreatedDateTime, DeviceId, VolumeType

$volume = Get-BitLockerVolume -MountPoint "C:"
foreach ($protector in $volume.KeyProtector) {
    if ($protector.KeyProtectorType -eq "RecoveryPassword") {
        Remove-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $protector.KeyProtectorId
    }
}

Disable-BitLocker -MountPoint "C:"

Deleting the Entra ID device record after a wipe removes the associated recovery key from the portal, but administrators should verify this explicitly rather than assuming it occurs automatically.

OneDrive and SharePoint Data Persistence

Cloud backup services retain copies of files independently of device state. When a device is wiped, OneDrive does not receive a signal to purge the associated data. Files synced before the wipe remain in the user's OneDrive, in SharePoint document libraries, and in the Microsoft 365 recycle bin for up to 93 days after deletion.

This matters in offboarding scenarios. If an employee's device is wiped but their Microsoft 365 account remains active — even temporarily — their data is still fully accessible via any browser or another device. The wipe addressed the endpoint; it did nothing to the cloud data plane.

Use KQL in Microsoft Purview or Microsoft Sentinel to audit file activity before and after a wipe action:

// Identify files synced from a specific device to OneDrive in the 30 days before wipe
CloudAppEvents
| where Timestamp > ago(30d)
| where ActionType in ("FileUploaded", "FileSynced", "FileDownloaded")
| where Application == "Microsoft OneDrive"
| extend DeviceName = tostring(RawEventData.DeviceName)
| where DeviceName == "<target-device-name>"
| project Timestamp, AccountDisplayName, ActionType, FileName, FolderPath, IPAddress
| order by Timestamp desc

// Audit SharePoint activity tied to a user account post-device-wipe
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType in ("FileUploaded", "FileDownloaded", "FileAccessed")
| where Application == "Microsoft SharePoint Online"
| where AccountUpn == "<user@domain.com>"
| project Timestamp, ActionType, FileName, SiteUrl, IPAddress
| order by Timestamp desc

These queries surface whether sensitive files were exfiltrated before the wipe or accessed from another location after it.

TPM State and Credential Residue

On devices using Windows Hello for Business, the TPM stores cryptographic keys tied to the user's identity. A Wipe action triggers a TPM clear as part of the Windows reset process on most modern hardware — but this behavior is hardware-dependent and not universally guaranteed across all OEM implementations. Administrators deploying mixed hardware fleets should validate TPM clear behavior on each device model before assuming it occurs.

Cached credentials from Microsoft Entra ID hybrid join scenarios can also persist in ways that survive a Wipe if the device is not properly disenrolled from both Intune and Entra ID before the action is triggered. The sequence matters: disenroll from Intune, remove the Entra ID device record, then issue the wipe — not the other way around.

Governance Considerations: Regulatory Exposure by Erase Type

The gap between perceived and actual data destruction has direct regulatory consequences. The specific exposure depends on which regulation governs the data and which erase action was used.

GDPR and the Right to Erasure

Under GDPR Article 17, data subjects have the right to erasure of personal data. When an employee or customer invokes this right, the organization must demonstrate that data has been removed not just from the device but from all systems where it was processed — including cloud backups, audit logs, and escrowed encryption keys. Issuing a Wipe in Intune and calling it done does not satisfy this requirement. The Entra ID device record, the BitLocker recovery key, and any OneDrive-synced files must each be addressed separately and documented.

HIPAA and Protected Health Information

Healthcare organizations subject to HIPAA must follow the NIST SP 800-88 guidelines for media sanitization when disposing of devices that processed Protected Health Information (PHI). Intune's Wipe action does not meet the NIST SP 800-88 "Clear" standard for SSDs unless the device's firmware-level Secure Erase is also invoked. Organizations that rely solely on Intune's Wipe for device decommissioning in clinical environments are operating outside HIPAA's technical safeguard requirements.

SOX and Financial Data Controls

For organizations subject to SOX, the concern is audit trail integrity as much as data removal. SOX requires that controls over financial data be documented and verifiable. If a device processed financial records and was wiped without a documented chain of custody — including BitLocker key removal, cloud data audit, and Entra ID record deletion — the control is unverifiable. That gap is exactly what auditors look for.

Recommendations: Building a Defensible Erase Workflow

The goal is not to avoid using Intune's erase options — they are the right tools for most scenarios. The goal is to build a workflow around them that closes the gaps they leave open.

Define Erase Scenarios Before You Need Them

Map each erase action to a specific operational scenario and document it in your runbook. Retire is for BYOD offboarding. Wipe is for corporate device decommissioning with follow-up steps. Fresh Start is for performance remediation only. Autopilot Reset is for reprovisioning, not decommissioning. Mixing these up under pressure — during an incident or a rapid offboarding — is where mistakes happen.

Build a Pre-Wipe Checklist in PowerShell

Automate the pre-wipe steps so they are not skipped:

param (
    [string]$DeviceId,
    [string]$UserUpn
)

Connect-MgGraph -Scopes "BitlockerKey.ReadBasic.All"
$keys = Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '$DeviceId'"
if ($keys) {
    Write-Output "WARNING: BitLocker recovery key exists in Entra ID. Remove after wipe."
    $keys | Select-Object Id, CreatedDateTime | Format-Table
} else {
    Write-Output "No BitLocker recovery key found for device $DeviceId."
}

Write-Output "Review OneDrive data for $UserUpn before proceeding."
Write-Output "Run KQL query in Purview to audit file activity in the last 30 days."

Connect-MgGraph -Scopes "Device.Read.All"
$device = Get-MgDevice -Filter "deviceId eq '$DeviceId'"
if ($device) {
    Write-Output "Entra ID device record found: $($device.DisplayName). Schedule deletion post-wipe."
} else {
    Write-Output "No Entra ID device record found. Verify device ID."
}

Validate Erase Outcomes in Your Lab First

Before deploying any erase option against production devices — especially in a new hardware fleet or after a major Windows update — test it in a controlled environment. Confirm that the TPM is cleared, that the BitLocker key is removed from Entra ID after device record deletion, and that no user data persists in the profile folder. Document the results per device model.

Audit Cloud Data as a Separate Workflow

Treat cloud data remediation as a parallel workflow, not an afterthought. When a device is wiped as part of an employee offboarding, the Microsoft 365 account review — including OneDrive data retention, mailbox hold status, and SharePoint permissions — should happen simultaneously, not after the device action is complete.