> ## Documentation Index
> Fetch the complete documentation index at: https://docs.derekdinh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MFA Troubleshooting: Codes, Lost Devices, and Resets

> Fix MFA code failures caused by time sync, recover access after losing your device, and reset MFA in Microsoft 365 and Google Workspace.

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

<AccordionGroup>
  <Accordion title="TOTP Code Is Rejected Despite Looking Correct">
    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.
  </Accordion>

  <Accordion title="Lost, Stolen, or Broken Phone">
    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.
  </Accordion>

  <Accordion title="New Phone Without Migrating MFA">
    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.
  </Accordion>

  <Accordion title="Push Notifications Not Arriving">
    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.
  </Accordion>

  <Accordion title="Country or SIM Change Blocking SMS Codes">
    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.
  </Accordion>
</AccordionGroup>

***

## Step-by-Step Resolution

<Steps>
  <Step title="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**.

    <Note>
      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.
    </Note>
  </Step>

  <Step title="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.

    <Warning>
      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.
    </Warning>
  </Step>

  <Step title="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).

    ```powershell theme={null}
    # Require MFA re-registration via MSGraph PowerShell
    Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"

    # List authentication methods registered for the user
    Get-MgUserAuthenticationMethod -UserId "jsmith@contoso.com"

    # Delete a specific TOTP software token (replace {methodId} with the Id from above)
    Remove-MgUserAuthenticationSoftwareOathMethod `
      -UserId "jsmith@contoso.com" `
      -SoftwareOathAuthenticationMethodId "{methodId}"
    ```

    <Tip>
      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.
    </Tip>
  </Step>

  <Step title="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.

    <Warning>
      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).
    </Warning>

    **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.

    <Note>
      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.
    </Note>
  </Step>

  <Step title="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.

    <Tip>
      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.
    </Tip>
  </Step>

  <Step title="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.
  </Step>
</Steps>

***

## 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.