Device Lifecycle & Onboarding

This page covers the full arc of a managed device — from first enrollment through re-assignment to final decommission. For new device provisioning via Windows Autopilot, see Provisioning with Windows Autopilot. This page covers the scenarios that Autopilot doesn't handle on its own.

---

Enrollment Methods

Windows Autopilot (Primary)

The recommended path for new corporate hardware. See Provisioning with Windows Autopilot.

Windows Enrollment Assistant

For a single device that needs enrollment without a full OOBE reset — typically an existing machine being added to management mid-lifecycle.

1. Download the Windows Enrollment Assistant from Intune > Devices > Windows > Windows enrollment > Enrollment assistant
2. Run the installer on the device as a local administrator
3. Sign in with the user's Entra ID credentials when prompted
4. The device enrolls in Intune as a managed device without requiring a wipe or re-image

When to use this vs. Autopilot

Use the Enrollment Assistant for isolated cases: a device missed during a rollout, a contractor machine being brought under management, or an executive's machine where a full wipe is not practical. For any bulk scenario, use Autopilot or bulk enrollment tokens instead.

BitLocker is already at XTS-AES 128 by the time you enroll

Devices brought under management this way have already completed OOBE, which means BitLocker Automatic Device Encryption has already encrypted the OS drive at XTS-AES 128-bit, used-space-only — Microsoft's documented Auto-DE defaults. (Setting the BitLocker encryption algorithm for Windows Autopilot devices) The OIB BitLocker profile that arrives after enrollment will not change the algorithm of an already-encrypted drive — the BitLocker CSP only honors EncryptionMethodByDriveType when BitLocker is first enabled. The device will appear Compliant (because BitLocker is on) while sitting at the wrong algorithm.

To confirm: manage-bde -status C: on the device, then check Intune > Devices > Monitor > Encryption report for the device under "the device is already encrypted, and the encryption method doesn't match policy settings". (Troubleshooting BitLocker with the Intune encryption report)

To remediate: decrypt and let Intune re-encrypt at the policy-defined algorithm:

manage-bde -off C:
# Wait for Conversion Status: Fully Decrypted (manage-bde -status C:),
# then trigger an Intune sync to re-enable encryption per policy.

For a deeper explanation and the Autopilot-path prevention strategy, see BitLocker Auto-Encryption — Apply Policy Before OOBE Finishes.

Bulk Enrollment Token (Provisioning Package)

For enrolling multiple devices without user interaction — useful for shared devices, kiosks, or lab machines that are not candidates for Autopilot (e.g., older hardware pre-dating Autopilot support).

1. In Windows Configuration Designer (available from the Microsoft Store), create a new Provision desktop devices project
2. Under Account Management, set:
   • Enroll in Azure AD: Yes
   • Bulk token expiry: Set to the maximum (180 days) — tokens expire and must be renewed
3. Export the provisioning package (.ppkg file)
4. Apply the package at OOBE (place on USB and connect during setup) or silently via:

   Add-ProvisioningPackage -PackagePath "C:\Packages\BulkEnroll.ppkg" -ForceInstall

Bulk token scope

Devices enrolled via bulk token are enrolled under the token's service account — they appear as Corporate but are not user-affiliated until a user signs in. Ensure your Conditional Access policies account for device-only enrollment scenarios.

Suppress Auto-DE in the image, not after the fact

A .ppkg is typically applied late in OOBE — after BitLocker Automatic Device Encryption has already initialized the drive at XTS-AES 128-bit, used-space-only. Since this scenario is bulk by definition, decrypt-and-re-encrypt per device is impractical. Prevent Auto-DE in the image instead:

Option A — Unattend.xml (preferred for bench reimaging via DISM/MDT):

<settings pass="oobeSystem">
  <component name="Microsoft-Windows-SecureStartup-FilterDriver" ...>
    <PreventDeviceEncryption>true</PreventDeviceEncryption>
  </component>
</settings>

Option B — Registry, applied before first OOBE boot:

Path	Name	Type	Value
HKLM\SYSTEM\CurrentControlSet\Control\BitLocker	PreventDeviceEncryption	REG_DWORD	0x1

With Auto-DE suppressed, the OIB BitLocker policy delivered by Intune after enrollment will be the first thing to enable BitLocker, so the configured algorithm (XTS-AES 256-bit, full-disk per OIB) takes effect on initial encryption.

Do not apply this to Copilot+ / Recall-capable hardware — Microsoft explicitly does not recommend PreventDeviceEncryption on Recall devices because Recall's security model assumes Auto-DE. (OEM BitLocker — Disable BitLocker automatic device encryption; BitLocker overview — Disable device encryption)

BYOD / Personal Device Enrollment (MAM)

For personal devices accessing organizational resources, the recommended posture is Mobile Application Management (MAM) without enrollment — the device itself is never managed, only the apps and data within them.

• Configure App Protection Policies in Intune targeting the user group
• Users install the Microsoft Authenticator and Company Portal apps
• When they open a managed app (Outlook, Teams, Edge), they are prompted to register and apply the protection policy
• No MDM profile is installed — IT cannot wipe the device, only corporate app data

Block full MDM enrollment for personal devices

Ensure your enrollment restrictions block Personally Owned device enrollment so users cannot accidentally (or intentionally) enroll personal devices under full MDM management.

Selective wipe propagation — typically up to 30 minutes

A MAM-WE selective wipe (Intune > Apps > App protection policies > [policy] > Wipe requests > Wipe data) is delivered when the targeted app next checks in with Intune — there is no real-time push channel like MDM has. Microsoft's documented expectation is up to 30 minutes for active apps, with longer delays if the device is offline or the app hasn't been launched. A 20–30 minute wipe is normal, not stuck. See Wipe corporate data with selective wipe for the canonical reference.

To force the wipe faster — ask the user to foreground the targeted app and check for email or refresh the inbox. The foregrounding triggers an immediate Intune SDK check-in, the email refresh forces a token refresh against Entra, and both together typically apply the wipe within 1–2 minutes rather than waiting for the next polling interval. Useful when revoking access from a departing employee, a lost device, or a confirmed-compromised account.

Confirm completion at Intune admin center > Apps > App protection policies > [policy] > Wipe requests — each request shows status Pending, Wiped, or Failed. Investigate only if Pending persists for >2 hours with the device confirmed online (suggests an Intune App SDK version issue, an MDM-MAM conflict, or an app that isn't actually targeted by the policy).

---

Device Re-Assignment

When a device is transferred from one user to another without a factory reset, residual user data and profile configuration from the previous owner remain on the device. The cleanest procedure depends on whether the device was provisioned via Autopilot.

Re-Assignment via Autopilot Reset (Recommended)

Autopilot Reset wipes the user's data and profile, re-runs the ESP, and re-presents the device at the login screen — without removing it from Intune or Autopilot registration.

From the Intune portal (remote):

1. Navigate to Intune > Devices > Windows > All devices > [device]
2. Select Autopilot Reset
3. The device reboots into a clean OOBE-like state, re-applies all policies, and presents the login screen to the new user

From the device (local, admin required):

• Hold Shift and select Restart, then navigate to Troubleshoot > Reset this PC > Remove everything > Cloud download

Autopilot Reset vs. Fresh Start vs. Wipe

Action	Removes User Data	Removes Intune Enrollment	Removes Autopilot Registration	Reinstalls Windows
Autopilot Reset	Yes	No	No	No
Fresh Start	Yes	No	No	Yes (clean Windows)
Wipe (Intune)	Yes	Yes	No	Yes
Full Retire + Delete	Yes	Yes	Yes	Manual

Use Autopilot Reset for re-assignment. Use Wipe only when decommissioning.

Re-Assignment without Autopilot Reset

If a quick hand-off is required without a full reset:

1. Have the previous user sign out and remove their account from Settings > Accounts > Other users
2. The new user signs in — Windows creates a new local profile from their Entra ID credentials
3. Their user-targeted Intune policies (apps, certificates, user config) apply on first sign-in

This is acceptable for a temporary transfer. For permanent re-assignment, an Autopilot Reset is preferred to ensure a clean state.

---

Device Retirement

Before re-provisioning, transferring to a non-managed party, or physically disposing of a device, remove all management records in this order. Order matters — see the warning below.

Trying to repair a wedged device, not retire it?

The procedure below ends in a factory reset and decommissions the device — it's appropriate when the device is leaving the organization, being sold, or being repurposed for non-managed use. If the goal is to repair a single wedged device (broken PRT, duplicate Entra records, stuck Pending state, MDM enrollment failure) and keep the user working on it without losing their profile or local data, use Entra Device Hygiene § Single-Device Remediation instead. That procedure tears down the Entra/AD/Intune state on the same machine and lets it re-onboard via the normal flow — no factory reset, profile preserved.

Step 1: Store the BitLocker Recovery Key

Retrieve and securely store the recovery key before any wipe or reset action removes access.

• Navigate to Intune > Devices > [device] > Recovery keys
• Copy the recovery key and store it in your key management system

Step 2: Retire the Device in Intune

• Navigate to Intune > Devices > Windows > All devices > [device] > Retire
• This removes the Intune MDM enrollment and wipes corporate data (including certificates and managed app data)
• The device must check in for the Retire action to complete — allow ~2–5 minutes, or have the user open the Company Portal app to force a sync

Step 3: Factory Reset the Device

Wipe the device so no organizational data or configuration remains.

From Intune (remote wipe):

• Intune > Devices > [device] > Wipe — select Wipe device and continue even if device loses power for devices being physically disposed of

On-device:

• Settings > System > Recovery > Reset this PC > Remove everything > Local reinstall
• Or: reboot into manufacturer recovery (e.g., F11) and select factory reset

Step 4: Disable the Device in Entra ID

Disabling the device prevents any further authentication attempts using the device's credentials while you complete cleanup.

• Navigate to Entra > Devices > All devices > [device] > Disable

Step 5: Delete from Autopilot (Autopilot-registered devices only)

Skip this step if the device was not registered in Autopilot

For devices enrolled via bulk token, Enrollment Assistant, or manual enrollment, skip to Step 6.

• Navigate to Intune > Devices > Windows > Windows enrollment > Windows Autopilot > Devices
• Find the device by serial number:

  Get-CimInstance win32_bios | Select-Object SerialNumber

• Select the device record and click Delete

Step 6: Delete the Device from Entra ID

• Navigate to Entra > Devices > All devices > [device] > Delete

Order matters — do not skip steps or reorder

• Do not delete from Entra before retiring from Intune — this leaves orphaned MDM enrollment records
• Delete from Autopilot before Entra — if the Autopilot record exists when you delete from Entra, the Autopilot sync will recreate the Entra device object within 24 hours
• Store the BitLocker key first — once you wipe the device, the key escrow in Intune is your only recovery option

---

At-scale stale device cleanup

The steps above cover retiring an individual device. For identifying and removing stale or duplicate device objects across the tenant — including the correct cleanup order for Hybrid Joined devices and a PowerShell script that automates discovery — see Entra Device Hygiene — Stale and Duplicate Object Cleanup.

---

Device Inventory and Naming Standards

Viewing Enrolled Devices

Navigate to Intune > Devices > Windows > All devices to see all enrolled Windows devices. Key filters:

Filter	Use Case
Last check-in > 30 days	Identify stale devices that may have left the organization or been wiped outside Intune
Compliance = Non-compliant	Devices blocked by Conditional Access — investigate and remediate
Ownership = Personal	Verify no personal devices slipped past enrollment restrictions
Enrollment type = Autopilot	Confirm Autopilot-provisioned devices vs. manually enrolled

Exporting the Device Inventory

For compliance audit evidence or asset management:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -All | Select-Object DeviceName, SerialNumber, EnrolledDateTime, LastSyncDateTime, ComplianceState, OwnerType | Export-Csv -Path ".\IntuneDeviceInventory.csv" -NoTypeInformation

Naming Standards

Device names set during Autopilot provisioning (via the naming template in the Deployment Profile) should follow a consistent convention that enables filtering and identification without querying Intune:

Component	Example	Purpose
Department code	ENG, FIN, OPS	Identifies the owning department
Location code	CHQ (City Hall), LAB	Identifies physical location for shared devices
Identifier	%SERIAL% or %RAND:5%	Unique per-device identifier

Example: CHQ-ENG-5CG1234ABC — City Hall, Engineering, serial number.

See Group Tags and Device Naming in the Autopilot guide for the naming template syntax.