MFA Lockout and Recovery Troubleshooting Guide

When a user is locked out of multi-factor authentication, the pressure to restore access quickly is exactly what attackers exploit, so a lockout ticket is both an availability problem and a security decision. This guide is a diagnostic reference for the lockouts identity teams see most: a lost or replaced phone, rejected one-time codes, smart lockout after failed sign-ins, registration loops, missing push prompts and locked-out administrators. For each symptom it lists the likely causes from most to least common, where to look, the fix and how to stop it recurring. Error codes and admin actions are quoted from Microsoft Entra, Google Workspace and AWS documentation checked on 11 November 2026. It is for help desk leads, identity engineers and IAM owners. Recovery design and help desk verification policy are covered in the Account Recovery and Help Desk Security Guide, which this page does not repeat.

Key takeaways

• Identify which lockout it is before acting. A password lockout, a missing MFA method, a failed MFA challenge and a Conditional Access block return different codes and need different fixes; resetting MFA for a password lockout only adds risk.
• Verify the person before you touch their methods. Re-registering MFA for a caller who only knows a password is the step that turned help desk calls into breaches at MGM Resorts and in the Storm-2949 Azure intrusion.
• Prefer a time-limited bootstrap credential over removing MFA. A one-time Temporary Access Pass or admin-issued backup code restores access without leaving the account single-factor.
• Most "broken codes" are clocks and duplicates. TOTP failures usually come from device time drift, a stale authenticator entry or a hardware token out of sync, not from the identity provider.
• Every recovery should notify and be reviewed. NIST SP 800-63B-4 says an account recovery event always causes notifications to the subscriber; log it, alert on it and sample it.

Triage: classify the lockout in the first two minutes

Ask the user for the exact error text or code, then open the sign-in log entry for the failed attempt. In Microsoft Entra the sign-in log shows the AADSTS code, the authentication requirement and the Conditional Access result for each attempt. The table maps the codes most often attached to "I'm locked out" tickets.

Outside Entra the same split applies. In Google Workspace, an admin with the User management privilege can see a user's 2-Step Verification settings only if 2SV is enforced or the user turned it on. In AWS, the console's Additional verification required page means the password was accepted and only the MFA device is the problem.

Symptom 1: lost, broken or replaced phone

This is the most common ticket. The user has a new phone and the authenticator app, passkey or SIM did not come across, or the device is gone.

Likely causes, most to least common

1. Authenticator app not migrated: software OTP seeds and push registrations are bound to the old device unless the app's own backup and restore was used.
2. Only one method registered: the user never added a second method, so there is nothing to fall back to.
3. Phone number changed or ported: SMS and voice methods point at a number the user no longer holds.
4. Device lost or stolen: treat this as a possible compromise, not only an availability issue.

Diagnose

• Methods registered: in Entra, open the user's Authentication methods blade and check what remains usable (FIDO2 key, Windows Hello, a second phone, an OATH hardware token).
• Recent activity: look for successful sign-ins or method changes after the reported loss date. A sign-in from a new location after the loss changes this from a lockout to an incident.

Fix

1. Try another registered method first. AWS documents the same order: choose Try another MFA method, then resynchronise or deactivate the lost device once signed in.
2. Entra: issue a one-time Temporary Access Pass (TAP). An Authentication Administrator can create a TAP for members, and a Privileged Authentication Administrator for admins as well; neither can create one for themselves. Only users included in the TAP policy can sign in with it. The value is shown once at creation, each user can have only one TAP, and the lifetime is configurable from 10 minutes to 30 days (default one hour). If a one-time TAP is used to register a FIDO2 key or phone sign-in, registration must finish within 10 minutes of the TAP sign-in.
3. Entra: remove the lost method. Require re-register MFA deactivates hardware OATH tokens and deletes phone numbers, Microsoft Authenticator registrations and software OATH tokens, then prompts the user to set up a new method at next sign-in. Pair it with Revoke sessions, which invalidates refresh tokens, if the device was lost rather than replaced.
4. Google Workspace: generate a backup code. In the Admin console go to Directory, Users, select the user, then Security, 2-step verification, Get Backup Verification Codes, and give the user one code. Only super administrators can generate codes for another admin.
5. AWS IAM user: an administrator deactivates the device. IAM users cannot recover an MFA device themselves. If the device was stolen, the administrator should also change the password.

Prevent

• Require two methods at registration: AWS allows root and IAM users up to eight MFA devices of any type, and Entra allows up to five OATH tokens or authenticator apps per user. Use the headroom.
• Prefer phishing-resistant, portable methods: a second FIDO2 key or a synced passkey survives a phone replacement. See Passkey account recovery.

Symptom 2: one-time codes are rejected

Likely causes, most to least common

1. Device clock drift: TOTP codes are derived from the current time step (30 or 60 seconds in Entra's OATH support). RFC 6238 recommends the verifier accept at most one time step of network delay, so a phone set to manual time that has drifted a minute or more will fail consistently.
2. Wrong or stale entry: the user has several entries for the same service (old tenant, previous registration) and types the code from the wrong one.
3. Hardware token out of sync: AWS notes that virtual and hardware TOTP devices can fall out of sync and need resynchronisation; FIDO keys do not.
4. Code reuse or rate limiting: the code was already used, or failed attempts have disabled the authenticator.

Diagnose and fix

• Clock: ask the user to set the phone to automatic network time and retry with a fresh code. This fixes most cases.
• Entry: compare the account label in the app with the user's sign-in name and tenant; delete stale entries after a working one is confirmed.
• Hardware tokens: resynchronise using the platform's resync function (AWS: two consecutive codes on the device's MFA settings) or reassign the token.
• Rate limits: NIST SP 800-63B-4 requires verifiers to limit consecutive failed attempts on one authenticator to no more than 100 by disabling it, and a disabled authenticator must be rebound before reuse. If your platform has disabled the method, recovery is a rebind, not a retry.

Background on OTP algorithms and seed handling is in the Authenticator Apps and OTP Guide.

Symptom 3: account locked after failed sign-ins (smart lockout)

Users describe this as an MFA lockout, but the cause is the password stage. Entra returns AADSTS50053 and shows "Your account is temporarily locked to prevent unauthorized use."

• Likely causes: a device or app retrying an old password after a change (phones syncing mail are the classic source), a password spray against the account, or a misaligned hybrid threshold that lets on-premises AD lock first.
• Diagnose: filter the sign-in log for the user and AADSTS50053; check the client app and IP. Many failures from one legacy client after a reset point to a stale device. Failures from many IPs point to a spray. AADSTS50053 can also mean the source IP was blocked as malicious, which the user cannot fix by waiting.
• Fix: an admin can unlock a cloud account before the duration expires. Self-service password reset choosing I forgot my password resets the lockout duration to zero; I know my password does not. Then update the stored password on the offending device.
• Prevent: align hybrid thresholds, retire legacy authentication clients, and treat repeated lockouts on one account as a detection, not a nuisance.

Symptom 4: stuck in a registration loop

The user signs in, is asked to register security info, and either cannot complete it or is asked again at the next sign-in. Entra returns AADSTS50079 or AADSTS50072.

1. Policy requires registration the user cannot satisfy: for example a policy that allows only FIDO2 for a user without a key. Check the Authentication methods policy targeting for the user's groups.
2. Registration itself is protected by a policy the user cannot meet: a Conditional Access policy on the "register security information" user action that requires a compliant device or a trusted location. Issue a TAP, which satisfies MFA for registration.
3. Interrupt mode limits: users in scope of the SSPR or Identity Protection MFA registration policy are sent to the interrupt mode of combined registration, which Microsoft says does not currently support FIDO2 and phone sign-in registration.
4. One-time TAP expired mid-registration: the 10-minute window for passwordless registration after a one-time TAP sign-in passed. Issue another TAP and complete registration in one sitting.
5. Federated user: for AADSTS50079 on a federated domain, the MFA claim must come from the federated identity provider. The fix is on the IdP side, or in how the federation trust passes MFA.
6. Replication delay: Microsoft notes TAP policy changes can take a few minutes to replicate; retry before escalating.

Migration from legacy per-user MFA and SSPR settings causes many of these loops. See Entra Legacy MFA and SSPR Policy Migration.

Symptom 5: push prompts not arriving, or unexpected prompts

• Not arriving, likely causes: notifications disabled for the authenticator app, battery optimisation killing the app, the registration was lost in a device restore, or the user's network blocks the push service. Fix: have the user open the app and use the in-app code if offered, check notification settings, and re-register if the app shows no account.
• Prompts the user did not start: this is not a lockout ticket; it is a credential compromise. In Entra, when a user reports an unknown prompt through Report suspicious activity, the user is set to High User Risk and the sign-in log shows result detail "MFA denied". Microsoft removed the older Block/unblock users and Fraud alert features on 1 March 2025; if your runbooks still reference them, they are out of date.
• Response: reset the password, revoke sessions, check for newly registered methods and devices, and do not clear the risk until the investigation is done. The Uber breach shows repeated push prompts wearing down a contractor until one was approved. See the MFA Fatigue and Bypass Guide.

Locked-out administrators and root accounts

If an AWS root device was lost or stolen, AWS advises changing the root password after setting up a replacement device, because an attacker may also hold the password. Control-plane recovery accounts are covered in Protecting Cloud Control-Plane Recovery Accounts and Credentials.

Restoring access safely: the recovery decision

NIST SP 800-63B-4 names four recovery classes: saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing. At AAL2 it requires two codes from different methods, one code plus a remaining bound single-factor authenticator, or repeated proofing. That gives a usable rule for help desks.

1. Verify before acting: never accept the caller's knowledge of personal details as proof. The MGM Resorts breach and the Storm-2949 Azure attack both began with a help desk resetting credentials for someone impersonating an employee.
2. Issue the narrowest bootstrap: one-time, short lifetime, scoped to registration.
3. Re-register strongly: steer the user to a phishing-resistant method during the recovery session.
4. Notify: send a recovery notification to every contact address, with instructions if the user did not request it, as SP 800-63B-4 requires.
5. Record: ticket number, verifier, evidence used, method issued and time, linked to the audit log entry.

Detection and measurement

• Audit events to alert on: TAP creation, security info deletion or re-registration required, new method registered within an hour of a recovery, and admin-on-admin method changes. See How to Detect MFA Method Registration Abuse.
• Risk events: user-reported suspicious activity (risk detection type userReportedSuspiciousActivity) and sign-ins from new devices immediately after a recovery.

Common failure patterns

• Disabling MFA "for now": excluding the user from the MFA policy to unblock them and forgetting to put them back. Find them with How to Find Accounts Excluded From MFA and Conditional Access.
• Resetting MFA for a password lockout: AADSTS50053 needs an unlock or password fix, not new methods.
• Multi-day TAPs: a TAP valid for days is a password by another name; keep it one-time and short.
• Admins recovering admins without a second approver: one compromised privileged help desk account can then take over every admin.
• Runbooks citing retired features: procedures that rely on Entra's removed Block/unblock users or Fraud alert settings fail silently.
• Single break-glass path: emergency accounts that depend on the same phone, IdP or Conditional Access policy as everyone else are locked out by the same failure.

Framework mapping

Practitioner checklist

• Help desk runbook starts with the error code and sign-in log, not with a reset.
• Out-of-band identity verification is mandatory before any method change, with a second approver for admins.
• Temporary Access Pass (or equivalent) enabled, one-time, with a short default lifetime.
• Every user, and every admin without exception, has at least two registered methods, one phishing-resistant.
• Hybrid lockout thresholds aligned: Entra lower than AD DS, Entra duration longer.
• Recovery and method-change events alert to the SOC and notify the user.
• Two tested emergency access accounts per tenant, and documented root recovery contacts for each AWS account.
• Runbooks reviewed for retired features at least twice a year.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• Microsoft Learn: Microsoft Entra authentication and authorization error codes
• Microsoft Learn: Configure Temporary Access Pass
• Microsoft Learn: Microsoft Entra smart lockout
• Microsoft Learn: Manage user authentication methods
• Microsoft Learn: Configure Microsoft Entra multifactor authentication settings
• AWS: Recover an MFA protected identity in IAM
• Google Workspace Admin Help: Recover an account protected by 2-Step Verification

Related NHI Mgmt Group resources: Account Recovery and Help Desk Security Guide, MFA backup codes and recovery codes guide, Break-Glass Account Guide, NIST SP 800-63B-4 Authenticator Assurance Levels Guide, JWT Validation Errors Troubleshooting Guide.