How can organisations recover accounts when a user changes device without SMS codes?

Why device-change recovery should not depend on a lost phone number alone

When a user changes device, the recovery problem is not the device swap itself, it is proving continuity of the account holder without reusing the compromised factor. SMS-only recovery breaks down when the old number is unavailable, recycled, or already exposed through SIM swap or message interception. Strong recovery should therefore separate identity proofing from the lost device and support more than one recovery path.

Recovery design works best when organisations treat it as an access control decision, not a convenience feature. The account should be recoverable through pre-registered methods that were set up before the device loss, such as backup codes, alternate authenticators, or a verified help desk process. That approach aligns with the recovery guidance in Account Recovery and Help Desk Security Guide and reduces dependence on a single channel that can fail or be abused.

How to verify the person requesting recovery

The practical question is whether the recovery method can prove the requester without creating a new takeover path. Good recovery workflows use evidence that is harder to fake than knowledge-based questions, and they define which accounts need stronger proofing before access is restored. For identity teams, the key is to predefine acceptable proofing steps, not improvise them during an outage or support call.

For many environments, the safest pattern is a tiered recovery design: low-risk accounts may use pre-issued backup codes or another enrolled authenticator, while privileged or sensitive accounts require stronger support review and step-up approval. This is especially important where recovery touches broader identity relationships, such as delegated access, shared credentials, or mixed human and machine access models, which are covered well in Human vs Non-Human Identity.

Where organisations rely on federation or modern sign-in flows, the recovery path should still preserve the same assurance level. If the user moved to a new device, the organisation should confirm whether the original factor was bound to the old device only, whether another authenticator is already enrolled, and whether the recovery event should trigger re-enrollment of higher-assurance methods such as passkeys or hardware-backed authenticators. The OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful here because recovery often intersects with token issuance, session continuity, and client re-binding.

Operational controls that make recovery safer in practice

Recovery becomes dangerous when it is treated as a one-time exception instead of a governed workflow. Organisations should log every recovery action, review unusual recovery volume, and add extra checks when the account has elevated privileges, financial authority, or access to sensitive data. If recovery requires a support agent, the support workflow must be resistant to impersonation, because help desks are often the easiest route around otherwise strong authentication.

One of the most common mistakes is keeping a recovery path that still depends on the original device or on a weak fallback method the organisation no longer trusts. Another is allowing recovery to restore access without rotating the affected sessions or credentials. In incidents where tokens or support workflows were abused, such as the Internet Archive breach 2024, the lesson was that recovery and re-entry paths can become persistence mechanisms if they are not revalidated and monitored.

Risk and Threat Considerations

Recovery flows are a common takeover target because attackers know users lose devices, forget backup steps, and escalate quickly when locked out. If the fallback channel is weaker than the primary login method, the recovery process becomes the easiest way to bypass the original control rather than restore it.

Failure mechanism: Weak proofing, help desk impersonation, recycled phone numbers, or over-trusted backup channels let an attacker satisfy recovery checks and reset access to the account.

Impact: The attacker can replace authenticators, steal sessions, persist after the user regains the device, and gain access to email, cloud apps, or downstream admin workflows that depend on the account.

Practitioner Guidance

What to verify: Confirm that every recovery method was enrolled before loss, that it does not depend on the lost device alone, and that the organisation can distinguish legitimate recovery from an account takeover attempt.

Decision rule: If the account can reach privileged systems, finance, or sensitive data, require stronger proofing and step-up review before restoration; if it is a routine user account, keep the workflow simple but still fully logged and replay-resistant.

What good looks like: Users can recover with a pre-registered alternate method, support staff can validate requests consistently, and the account is re-enrolled, re-checked, and monitored immediately after recovery.

Practitioner takeaway: The safest recovery design is one that restores access without reusing the old device trust path, because the recovery step itself must be at least as defensible as the original sign-in.

Related resources from NHI Mgmt Group

• How should organisations replace SMS OTP without creating user friction?
• How can organisations reduce device rotation abuse without hurting user experience?
• How should organisations roll out passkeys in a federated user pool without creating duplicate accounts?
• How should organisations roll out two-factor authentication across all user accounts without breaking business workflows?