How to reset MFA for a user in Entra ID

Resetting a user's MFA in Entra ID means removing the method they can no longer use, forcing a fresh registration at next sign-in, and — when they have nothing left to sign in with — handing them a Temporary Access Pass so they can get back in. The whole thing takes two minutes once the roles and the TAP policy are in place; most of the pain comes from doing only half of it.

This is the most common helpdesk request in a tenant that has passwordless authentication or a strict Conditional Access baseline, so it is worth getting the procedure into a runbook rather than relying on whoever is on shift.

Prerequisites

• A role that can manage authentication methods: Authentication Administrator for ordinary users, Privileged Authentication Administrator if the target holds any admin role. See Microsoft 365 admin role design for why these are separated.
• Temporary Access Pass enabled in Entra admin center → Protection → Authentication methods → Policies, scoped to at least the helpdesk-served population. Set a sensible default lifetime (one hour) and decide whether passes are one-time use.
• Identity verification for the caller. A reset is the exact thing an attacker asks a helpdesk to do; have a verification step that does not rely on the phone you are about to replace (manager confirmation, video call, in-person, an HR-held question). This is the control that stopped the MGM-style attacks, not anything in the portal.
• The Microsoft Graph PowerShell SDK if you want to script it; the portal is fine for one-offs.

Steps

1. Open the user's authentication methods

Entra admin center → Users → All users → the user → Authentication methods. You will see every registered method: Authenticator app entries (with device name), phone numbers, FIDO2 keys, Windows Hello registrations, email for SSPR, and any current Temporary Access Pass.

2. Delete the method that is gone

Click the ellipsis on the lost phone's Authenticator entry (or the old phone number) and Delete. Do this even if you also intend to re-register: a stolen phone with an Authenticator entry still approves push prompts until the method is gone.

With PowerShell:

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
Get-MgUserAuthenticationMethod -UserId user@contoso.com
# then, for the Authenticator entry you want gone:
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId user@contoso.com -MicrosoftAuthenticatorAuthenticationMethodId <id>

3. Require re-registration

Still on Authentication methods, click Require re-register multifactor authentication. This flags the account so combined registration runs at the next interactive sign-in. On its own it does not remove anything — hence step 2.

4. Revoke existing sessions

Revoke sessions on the same page (or Revoke-MgUserSignInSession -UserId user@contoso.com). This invalidates refresh tokens so an attacker holding a token from the old device is signed out within the token's lifetime, and so the user actually sees the re-registration prompt instead of coasting on cached sessions.

5. Issue a Temporary Access Pass

If the user has no remaining usable method, Add authentication method → Temporary Access Pass. Set the lifetime (one hour is plenty for a helpdesk call), tick one-time use unless they need to register several methods across devices, and read the code to them over the verified channel. They sign in with the TAP, are prompted to register a new method, and are done.

If the user still has one working method (a FIDO2 key, a second phone), skip the TAP — they can register the new Authenticator entry themselves from My Security Info.

Verify

• Sign-in logs (Entra → Monitoring → Sign-in logs, filter by user): the next sign-in should show the TAP or the remaining method, followed by a registration event under Audit logs → Authentication methods.
• Authentication methods for the user now lists the new Authenticator entry and no longer lists the old device.
• If the account was potentially compromised rather than just a new phone, follow the compromised account runbook — MFA reset is one step of that, not the whole response.

Roll back

There is nothing to roll back for a legitimate reset. If the request turns out to have been social engineering, treat it as a compromise: block sign-in, revoke sessions again, delete the new method the attacker registered, and review what the account touched in the sign-in log investigation runbook. The audit log entry for the TAP creation names the admin who issued it, which is why every reset should be ticketed.