How should teams handle account setup when users switch to a new device?

Treat device setup as an opportunity to improve identity hygiene, not just restore access. Move approved credentials into managed storage, confirm 2FA enrollment, and remove obsolete logins that users no longer need. The goal is to reduce password reuse and make recovery predictable when the next device change happens.

Why This Matters for Security Teams

When a user moves to a new device, the security problem is not just restoration of access. It is whether the old device still holds valid sessions, cached secrets, recovery factors, or unmanaged logins that can be reused or stolen. A clean handoff should strengthen identity hygiene, reduce password reuse, and eliminate forgotten pathways that survive the migration.

This matters because device replacement often exposes weak account lifecycle controls that normal operations hide. The NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is a useful signal of how often access cleanup lags behind change. Even in human account flows, the same pattern appears: access persists longer than teams expect, and recovery becomes the easiest time for an attacker to exploit stale credentials. Guidance from the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 both point toward lifecycle-managed access rather than one-time setup. In practice, many security teams encounter account sprawl only after a lost device, a helpdesk reset, or an account takeover has already forced a review.

How It Works in Practice

Account setup for a new device should be handled as a controlled re-enrolment event, not a simple password reset. The practical sequence is: verify the user through a strong recovery path, move approved credentials into managed storage on the new device, confirm multi-factor authentication enrollment, and revoke access that is tied to the old device or no longer needed. That means checking browser-stored passwords, synced tokens, app-specific logins, email sessions, and recovery codes as part of the handoff.

The goal is to make the new device the only trusted endpoint for current access. Current guidance suggests using an identity workflow that is tied to device state and policy, not just the username and password pair. For organisations following NIST Cybersecurity Framework 2.0, this maps cleanly to access control, authentication, and recovery governance. The Ultimate Guide to NHIs is relevant here because the same lifecycle logic used for secrets and service account applies to human recovery flows: stale credentials should be rotated, storage should be centralised, and offboarding should be deliberate.

A practical setup checklist usually includes:

• Confirm the device is enrolled in MDM or equivalent management before restoring privileged access.
• Re-issue MFA enrollment on the new device rather than simply cloning the old factor.
• Remove remembered sessions, backup codes, and app passwords from the retired device.
• Review whether shared accounts, delegated access, or saved credentials should be retired at the same time.
• Log the change so future recovery steps are predictable and auditable.

Where organisations already use zero-trust access, this process should be tied to conditional access checks and device posture. These controls tend to break down when users keep unmanaged personal backups, because the old device can still authenticate through cached sessions or copied recovery material.

Common Variations and Edge Cases

Tighter device-based access controls often increase support overhead, requiring organisations to balance user convenience against stronger account recovery and reduced credential leakage. That tradeoff is real, especially for mobile-first teams, executives, contractors, and employees who switch devices frequently.

There is no universal standard for every recovery scenario, so teams should treat some cases differently. For example, a lost or stolen device requires immediate session revocation and factor reset, while a planned replacement may allow a smoother transition with staged enrolment. Shared devices, kiosk environments, and bring-your-own-device setups also need narrower assumptions because the old device may not be fully under corporate control.

Best practice is evolving toward device-aware access policies, but the exact implementation varies by platform and risk appetite. In high-risk environments, organisations may want to require a fresh proofing step before restoring access to sensitive systems, especially when finance, admin, or customer data is involved. The core rule remains the same: the new device should become the trusted endpoint, and the old one should stop being trusted as quickly as possible. External guidance from the Ultimate Guide to NHIs supports the broader operational principle that access should be rotated, constrained, and removed when it is no longer needed.

Related resources from NHI Mgmt Group

• How should security teams handle device code phishing when users complete real Microsoft MFA?
• How should teams reduce the risk of orphaned service accounts and stale tokens?
• How should security teams handle MFA resets and account recovery?
• How should security teams handle SaaS offboarding when users also use AI tools?