Skip to main content
Multi-factor authentication (MFA) is one of the most effective controls against account compromise, but it also introduces a new class of access problems when authenticator apps fall out of sync, phones are lost, or users switch devices without migrating their tokens. This guide walks you through every common MFA failure scenario and shows you how to restore access safely, without weakening the security posture that MFA is there to enforce.

​
Common MFA Failure Scenarios

Time-based One-Time Passwords (TOTP) — used by Microsoft Authenticator, Google Authenticator, Authy, and similar apps — are mathematically derived from the current time. If your phone’s clock is even 30–90 seconds out of sync with the server, every code you generate will be invalid.
When the device holding your authenticator app is unavailable, you cannot generate TOTP codes or approve push notifications. Access must be restored through an alternate verification method or an admin reset.
Getting a new device and restoring from a backup does not always carry over authenticator tokens (especially Google Authenticator on older versions). The codes on the new device will be incorrect because they are tied to a different secret key.
Microsoft Authenticator and Duo rely on push notifications, which can be silently blocked by battery optimisation settings, corporate MDM profiles, or notification permission changes after an OS upgrade.
If your MFA backup method is SMS and you have travelled internationally or switched SIM cards, SMS codes may not be delivered or may arrive late enough to expire.

​
Step-by-Step Resolution

1

Fix Time Sync on Your Authenticator App

Before escalating or requesting an admin reset, always check the time sync on your mobile device — it resolves the majority of “code not working” tickets.Microsoft Authenticator:
  1. Open the app → tap the three-dot menu (top right) → Settings.
  2. Tap Time correction for codes → Sync now.
  3. You should see “The time has been synced”. Try signing in again.
Google Authenticator:
  1. Open the app → tap the three-dot menu → Time correction for codes → Sync now.
On the device itself:
  • iOS: Settings → General → Date & Time → enable Set Automatically.
  • Android: Settings → General Management → Date and Time → enable Automatic date and time.
Even a 60-second clock drift is enough to invalidate every TOTP code. Automatic time sync via NTP is the permanent fix — make sure it stays enabled.
2

Use a Backup Code

Most MFA-protected services let you generate one-time backup codes at enrolment time. These are the fastest way to regain access without admin involvement.
  1. On the login page, when prompted for an MFA code, look for a link such as “Try another way”, “Use a backup code”, or “I can’t access my authenticator app”.
  2. Enter one of your saved backup codes. Each code is single-use and will be invalidated after you enter it.
  3. Once inside, immediately re-enrol MFA on your current device (see steps below) so you do not get locked out again.
Backup codes are as powerful as your password. Store them in a password manager or a physically secure location — not in plain text on your desktop or in an email draft.
3

Reset MFA in Microsoft 365 Admin Center

Use this procedure when a user cannot access their authenticator app and has no backup codes. You must be a Global Administrator or Authentication Administrator.
  1. Sign in to the Microsoft 365 Admin Center: https://admin.microsoft.com
  2. Go to Users → Active users and search for the affected user.
  3. Click the user’s display name to open their profile.
  4. In the Account tab, scroll to the Sign-in section and click Manage multifactor authentication.
  5. Locate the user in the MFA management portal and click Manage user settings.
  6. Tick Require selected users to provide contact methods again and click Save.
The user will be prompted to re-enrol their MFA method on next sign-in.Alternatively, via Azure Active Directory / Entra ID:
  1. Open https://entra.microsoft.com → Identity → Users → All Users.
  2. Select the user → Authentication methods.
  3. Click Require re-register MFA (or delete a specific method such as the old phone number or authenticator entry).
If you need to temporarily bypass MFA for a federated or B2B user to let them re-enrol, use a Conditional Access policy exclusion scoped to that single user for no more than 24 hours, then remove the exclusion once they have re-enrolled.
4

Reset MFA in Google Workspace Admin Console

Use this procedure to reset MFA for a Google Workspace user. You must be a Super Admin or have the User Management admin privilege.
  1. Sign in to the Google Admin Console: https://admin.google.com
  2. Go to Directory → Users and search for the affected user.
  3. Click the user’s name to open their profile.
  4. Click the Security tab at the top of the user’s account page.
  5. Click 2-step verification, then click Turn off 2-Step Verification — this clears all enrolled MFA methods for the user.
Turning off 2-step verification entirely removes all enrolled factors. The user’s account will be protected only by their password until they re-enrol. Complete the reset, notify the user, and confirm they have re-enrolled within your organisation’s SLA window (typically same business day).
To generate new backup codes for a user:
  1. Still in the user’s Security tab, click 2-step verification.
  2. Click Get Backup Verification Codes to generate a new set of codes you can securely share with the user via phone or in person.
Google Workspace also supports account recovery options such as a recovery phone number or email. Review these under the user’s Security tab to ensure users have a self-service path next time.
5

Re-enrol MFA After a Reset

Once the admin reset is complete, guide the user through setting up MFA on their new or current device before ending the session.Microsoft 365:
  1. Direct the user to https://aka.ms/mfasetup.
  2. Sign in with username and password only (MFA will not be prompted yet).
  3. Follow the prompts to add Microsoft Authenticator or a phone number.
  4. Confirm by approving a test push or entering a test code.
Google Workspace:
  1. Direct the user to https://myaccount.google.com/security.
  2. Under How you sign in to Google, click 2-Step Verification.
  3. Add the Google Authenticator app or a hardware security key.
Encourage users to enrol at least two MFA methods (e.g., authenticator app + backup phone number) so that losing one device does not result in a full lockout.
6

Fix Push Notification Delivery Issues

If the user’s app is installed and time-synced but push notifications are not arriving, work through these checks:
  1. Battery optimisation: On Android, go to Settings → Battery → Battery Optimisation and set the Authenticator app to Unrestricted or Don’t optimise.
  2. Notification permissions: Settings → Notifications → [Authenticator App] — ensure notifications are Allowed and not silenced.
  3. VPN interference: Some corporate VPNs block the push notification relay. Switch from push to the TOTP (six-digit code) method temporarily to confirm.
  4. Force-close and reopen the authenticator app, then attempt sign-in again.
  5. Re-register the device in the app if the above steps do not resolve it: in Microsoft Authenticator, tap your account tile → remove it → add it back via the Microsoft 365 Admin Center registration link.

​
Escalation

Escalate to a senior administrator or the Security team for full account recovery if:
  • The user has no backup codes, no access to their registered phone, and no alternate email on file — standard self-service and tier-1 resets will not be sufficient.
  • You suspect the MFA re-registration request is fraudulent (social engineering attempt) — do not reset MFA without verifying the user’s identity through an out-of-band channel (video call with employee badge, in-person visit, or manager confirmation).
  • The account shows sign-in activity from an unexpected location or IP address immediately before the lockout — this may indicate that the account has already been compromised and the MFA reset request is coming from the attacker.
  • Hardware security keys (FIDO2/WebAuthn) need to be de-registered — these require specific portal access and, in some environments, physical key return procedures.
Include the affected username, the platform (M365 / Google Workspace / other), the last successful login timestamp, and any anomalous sign-in details in your escalation ticket.