Device Reassignment and Reimaging: Clean Handover Between Users Without Cached Credentials

A laptop or phone passed from one employee to another often carries the first user's identity with it: cached sign-ins, browser sessions, tokens, local admin rights and the device's ownership record in the directory. Reassignment is routine (a leaver's laptop goes to a new starter, a loan pool device moves between staff, a team swaps phones), so it is usually handled by the service desk under time pressure, with a quick reset or none at all. The result is a device that the second user can use while the first user's sessions, credentials or data remain reachable, and an MDM and directory record that still names the wrong person. This guide covers the handover itself: choosing between a full reimage, an MDM reset and a user-level clean-up, clearing identity artefacts, fixing ownership records and verifying the device before the next user signs in. It is for endpoint, service desk and IAM teams. Lost or stolen devices are covered in the Remote lock and wipe for lost phones and laptops, and the leaver process in the Employee Offboarding Security Guide.

Platforms are listed alphabetically. Product actions are described from each vendor's documentation as of November 2026; confirm current behaviour there before relying on a setting.

Key takeaways

• Default to a reset that removes user data. A user-to-user handover should remove the previous user's profile, files and sessions; keeping user data is for repairs on the same user, not reassignment.
• Fix the ownership record. MDM primary user, directory device owner and asset register must name the new holder, or self-service, compliance and investigations point at the wrong person.
• Rotate device-held secrets. The local administrator password and disk encryption recovery key were visible to the previous user or helpdesk; rotate them at handover.
• Revoke the previous user's sessions centrally. Wiping a device does not revoke refresh tokens that were copied elsewhere; for leavers, revoke sign-in sessions in the identity provider too.
• Verify before handover. A short checklist (no old profiles, correct owner, compliant, new recovery key escrowed) catches failed or partial resets.

What travels with a reassigned device

Choosing the reset method

Pick the lightest method that removes everything in the table above. As a rule (our recommendation): reassignment to a different person uses a reset that removes user data; a leaver whose device held privileged or developer credentials, or any device with signs of compromise, gets a full wipe and reprovisioning.

Android

For company-owned devices, use the MDM factory reset and re-enrol through zero-touch or the enrolment method in use. Microsoft documents that whether a Google account is needed after reset depends on ownership type, reset method and Factory Reset Protection configuration, and that an Intune admin wipe does not preserve FRP data by default. Check OEM-specific notes: Microsoft documents, for example, that the Intune Wipe action on Zebra devices removes corporate data rather than performing a factory reset, and that OEMConfig or StageNow is used for a factory reset there. See the Android Enterprise Security Guide.

Apple iPhone and iPad

An MDM erase command runs Erase All Content and Settings, which Apple describes as making user data inaccessible by removing the keys in effaceable storage. Return to Service lets the management service include Wi-Fi details and enrolment information with the erase so an iPhone, iPad, Apple TV or Apple Vision Pro resets and re-enrols without manual setup; for devices registered in Apple Business or Apple School Manager the enrolment configuration can be omitted and the device picks up its enrolment profile during activation. With iOS 26, iPadOS 26 and visionOS 26 or later, Return to Service can preserve managed app binaries while erasing user data. Apple notes that in that mode software and app updates are deferred until the device is reset, so plan regular resets. Clear any personal Activation Lock before the erase, as covered in the Remote lock and wipe for lost phones and laptops. See Apple Business Manager Security.

Apple Mac

On Macs with Apple silicon or the T2 chip running macOS 12.0.1 or later, a device management administrator can start Erase All Content and Settings; Apple documents an ObliterationBehavior setting that controls fallback to a full obliteration and macOS reinstall when a Mac does not meet the requirements. A bootstrap token escrowed to MDM can authorise the erase silently on Apple silicon. Re-enrolment then follows Automated Device Enrolment.

Windows

Microsoft documents three constraints that shape the choice: Autopilot Reset needs Windows Recovery Environment enabled (otherwise it fails with ERROR_NOT_SUPPORTED, 0x80070032); it is for Microsoft Entra joined devices, and hybrid joined devices use a full wipe instead; and the local variant needs the policy that enables it (off by default) plus a local admin credential at trigger time. Microsoft also warns that the power-loss wipe option can leave a device unbootable, so use it only on corporate devices with recovery procedures in place. After a full wipe you may also need to remove the device from Windows Autopilot and Microsoft Entra ID before re-registering it.

Clearing identity artefacts

• Tokens and sessions: a reset that removes the user profile removes the device-held tokens with it. Session revocation in the identity provider is still needed for leavers and for anyone whose device may have been compromised, because tokens or cookies copied off the device are not affected by a wipe. See the Employee Offboarding Security Guide.
• Cached domain logons: on shared or frequently reassigned Windows devices, reduce the logon cache. Microsoft documents the "Interactive logon: Number of previous logons to cache" policy (0 to 50, default 10 on clients), notes that cached data does not expire and is only overwritten, and says organisations can set 2 for end-user computers and 0 for high-security systems, with the trade-off that 0 blocks sign-in when no domain controller is reachable.
• Local administrator password: rotate it at handover. Windows LAPS supports rotation on demand through the Reset-LapsPassword cmdlet, the ResetPassword action in the LAPS CSP or, for Active Directory, by changing the expiration time; it can also rotate automatically after the account is used, with a configurable grace period. See the Local Administrator Password Solution (LAPS) Guide.
• Disk encryption recovery key: rotate the BitLocker or FileVault recovery key after any reset where the key was shown to a person, and confirm the new key is escrowed. See BitLocker.
• Local group membership: remove the previous user and any per-user admin grants from local Administrators. Microsoft notes that changing the Intune primary user does not change local group membership.
• Non-human credentials: for developer and admin devices, rotate any keys or tokens the previous user stored locally, not only the device. A wipe removes the copy on the device but not the credential itself.

Fixing ownership records

Three records should agree after every handover: the MDM primary user, the directory device owner and the asset register entry.

• Intune primary user: a remote Autopilot Reset removes the primary user and Entra device owner, and the next user to sign in becomes both. A local Autopilot Reset does not update them. Without a reset, an administrator with the Managed devices/Set primary user permission can change the primary user on Entra joined or hybrid joined Windows devices (Devices > All devices > device > Properties > Change primary user); changes can take up to 10 minutes to appear. For iOS, iPadOS and Android, Microsoft states that enrolment is required to assign a new primary user.
• Enrolled by: Microsoft notes the "Enrolled by" user is not changed by a primary user change. Record it in the asset register so investigators know who enrolled the device.
• Shared devices: a Windows device with no primary user is treated as shared; Company Portal self-service actions such as reset, rename and retire are then unavailable. Use this deliberately for pool devices. See the Kiosk and Shared Device Security Guide.
• Asset register: update holder, date, reset method used and ticket reference. See the IT Asset Inventory Template.

A handover runbook

1. Trigger: a ticket names the device, the previous holder, the new holder and the reason (leaver, mover, loan return, repair swap).
2. Classify: did the previous holder have privileged, developer or high-risk access, or are there signs of compromise? If yes, full wipe and reprovision; if no, MDM reset that removes user data.
3. Preserve if required: for leavers under investigation or legal hold, image or collect the device before any reset. See the Chain of Custody Form Template.
4. Release locks: remove personal Activation Lock or Google accounts while the previous holder is still reachable.
5. Reset: run the chosen method from MDM; record the action and its completion status.
6. Rotate: local admin password and disk recovery key; remove stale local admin grants.
7. Re-own: set or confirm the primary user, directory owner and asset register entry.
8. Verify: the device is compliant, encryption is on with a newly escrowed key, no previous user profiles remain and the first sign-in is by the new holder.
9. Close: attach evidence to the ticket. If verification fails, fall back to a full wipe and repeat from step 5.

Detection and measurement

Useful signals: devices where the most recent sign-in user differs from the primary user for more than a few days; devices with more than one user profile outside shared pools; reset actions that never reported completion; and recovery key views without a following rotation.

Framework mapping

Common failure patterns

• "Keep user data" resets: a Windows wipe that keeps enrolment state and user accounts, chosen because it is quicker, hands the next user the previous user's profile.
• Local reset, stale owner: a local Autopilot Reset leaves the old primary user and device owner in place, so compliance alerts and self-service go to the wrong person.
• Developer secrets survive: the device is reset but the cloud keys and tokens the previous user stored are never rotated.
• Recovery keys never rotated: the helpdesk read out a BitLocker key during the handover and it stays valid for the life of the device.
• Locked out after reset: a personal Activation Lock or Google account is discovered only after the wipe, when the previous holder has gone.
• Hybrid devices skipped: Autopilot Reset fails on hybrid joined devices and the technician hands the device over anyway.

Practitioner checklist

• A written handover runbook defines when to use an MDM reset and when to fully wipe and reprovision.
• Reset methods that keep user data are excluded from user-to-user reassignment.
• Windows Recovery Environment is enabled fleet-wide so Autopilot Reset works.
• Personal activation and factory reset locks are cleared before the previous holder leaves.
• Local admin password and disk recovery key are rotated at every handover.
• MDM primary user, directory owner and asset register are updated and reconciled monthly.
• Leavers' sessions are revoked in the identity provider, independent of the device reset.
• Developer and admin devices trigger rotation of the previous holder's locally stored credentials.
• Each handover is verified (compliance, profiles, owner, escrowed key) before the device is released.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Apple: Use Return to Service for Apple devices
• Apple: Erase Apple devices
• Microsoft: Remove devices by using wipe, retire or manually unenrolling
• Microsoft: Windows Autopilot Reset
• Microsoft: Find the primary user of an Intune device
• Microsoft: Windows LAPS concepts overview
• Microsoft: Interactive logon, number of previous logons to cache

Related NHI Mgmt Group resources: Mobile Device Management Security Guide · Remote lock and wipe for lost phones and laptops · Employee Offboarding Security Guide · Entra ID Primary Refresh Token (PRT) Security Guide · Joiner-Mover-Leaver Guide