How to add or reset your Microsoft 365 sign-in verification method (MFA)

When you sign in to Microsoft 365 with your work or school account, Microsoft asks for a second proof that it is you, such as approving a notification in the Microsoft Authenticator app, typing a code, or tapping a security key. That second proof is your verification method (also called a sign-in method or security info). It is tied to the phone or key you registered, so you have to change it when the phone changes. You might be here because:

• you got a new phone, or you are about to wipe or hand back the old one;
• your phone number changed;
• you lost the phone, and the sign-in page keeps asking you to approve on it;
• your organisation asked you to register a method (or a stronger one, such as a passkey);
• you are the admin, and a user has asked you to reset theirs.

Applies to: Microsoft 365 work or school accounts, which use Microsoft Entra ID. It does not apply to a personal Microsoft account (Outlook.com, Xbox), which has its own recovery process. The first half is for the user. The second half, from “For admins”, is for the person with an admin role.

What is going on

Your registered methods are stored on your account in Microsoft Entra ID, not on the phone. A new phone has nothing registered until you add your account to Authenticator on it, and adding a method requires you to prove who you are with a method you already have. That is why the order matters: add the new method before you give up the old one. If you already lost the old one, only an admin can help, because letting you replace your own verification without proof is exactly the gap an attacker wants.

There are three different setups behind the scenes, and they change what the admin sees. Check which your organisation uses, because it affects the admin steps:

• Conditional Access policy (Entra ID P1 or P2). Microsoft calls this the best way to require MFA. The user’s per-user MFA state shows Disabled, which is normal.
• Security defaults. The free-tier alternative, for tenants with no Conditional Access policies. Everyone has to register for MFA.
• Per-user MFA. The older method, where an admin enables each user. Microsoft does not recommend changing user states unless your licences do not include Conditional Access and you do not want security defaults, and says not to enable it if you use Conditional Access policies.

The steps for adding and resetting methods are the same in all three. What differs is whether, and when, a user is forced to register.

Before you start / check first

1. Which situation are you in?

Your situation	What to do
You can still sign in (new phone, but the old one still works, or another method works)	Section “I can still sign in” below. Add the new method first, then remove the old one.
You cannot sign in (lost or broken phone, no other method)	Section “I cannot sign in” below, then ask your admin. You cannot reset this yourself.
You are the admin	Section “For admins” below.

2. Do not wipe the old phone yet

If you are changing phone and the old one still works, keep it working until the new one is registered and tested. If you remove your work account from the old Authenticator app first, you may lock yourself out. This is the single most common cause of the problem in this article.

Root cause

The sign-in methods on your account no longer match the device you hold. Nothing is broken. Adding the new method, or having an admin clear the old ones, brings the account and your device back in step.

The fix

I can still sign in: add or change a method

1. Open https://mysignins.microsoft.com/security-info (also reached through aka.ms/mysecurityinfo) in a web browser and sign in with your work or school account. Complete the MFA prompt.
2. Select Add sign-in method, then choose the method from the list. Microsoft describes the flow as Add sign-in method, Choose a method, then the method name. The methods you can add depend on what your organisation allows. Typical ones are Microsoft Authenticator, Phone, and Passkey (including a FIDO2 security key). [UNCONFIRMED: the exact wording of the Microsoft Authenticator and Phone entries on the Add sign-in method list. The Passkey path is from Microsoft Learn.]
3. Microsoft Authenticator: install the app on the new phone, and follow the prompts on the page. Approve the test notification. Then check that you can see the account in the app.
4. Phone: enter the number and choose text or call. Complete the verification. Phone verification (text and voice) is weaker than an app or a passkey, so use it as a backup, and your organisation may turn it off.
5. Passkey or security key: choose Passkey, select Next, and pick where to save it. If you are using a physical key, choose the security key option, then insert or tap it and enter its PIN or touch it when asked. Give it a name you will recognise, and select Done.
6. Change a phone number: on the Security info page, select the Phone entry and choose Change.
7. Remove the old method: find the old phone (or old Authenticator entry) in the list and delete it. Do this last, after you have signed out and back in with the new method and it worked.

Deleting a passwordless method needs a second proof. If you try to delete a passwordless sign-in method (for example, Authenticator set up for phone sign-in), Microsoft asks you to sign in with two-factor authentication first. Have another method registered, such as the new Authenticator or a phone, before you delete the old one, or you can get stuck.

Remember to keep at least two methods registered, for example Authenticator plus a security key or a phone number, so one lost device does not lock you out again.

I cannot sign in: the old phone is lost, broken or gone

1. On the sign-in page, look for I can’t use my Microsoft Authenticator app right now or Sign in another way. If you have a second method registered (a phone number, a security key, a code in an app on another device), use it. If it works, go straight to the steps above and add the new method.
2. If no other method works, contact your IT help desk or admin. An admin in your organisation has to reset your methods, because only an admin can change them for you. Say that you lost the phone and when, so the admin can also sign out any session still open on it.
3. Expect to be asked to prove who you are. That is not the help desk being difficult. See “Helping a locked-out user safely” below.
4. When the admin has reset you, sign in again, and you will be asked to set up a new method. Or the admin may give you a one-time Temporary Access Pass to use instead. Register the new method on the Security info page as above and, if the phone is lost or stolen, tell your admin, so they can sign out sessions and wipe it if it is managed.

If the phone was stolen or may be in someone else’s hands: change your password as well (your admin or the self-service password reset page can do this), and tell your admin at once. A thief with your unlocked phone may be able to approve your sign-in prompts.

For admins: reset someone’s methods in the Microsoft Entra admin center

Before you reset anything, verify who is asking. A reset is how an attacker takes over an account, so every step below assumes you have already done the identity check in the next section. If you are not sure, stop.

What you need

• The Authentication Administrator role or higher, to manage a standard user. To reset an admin account you need a higher role. For a Temporary Access Pass, Microsoft says Privileged Authentication Administrators can create one for admins and members (except themselves), and Authentication Administrators can create one for members (except themselves). [UNCONFIRMED: the role needed for “Require re-register multifactor authentication” on an administrator account. Check the Microsoft Entra permissions reference before you rely on a lesser role.]
• The user’s sign-in name (user principal name), taken from the directory and not from the person who contacted you.

Step 1: open the user’s Authentication methods

1. Sign in to the Microsoft Entra admin center.
2. Browse to Entra ID, Users, and select the user.
3. Select Authentication methods. You see every method the user has registered. Take a screenshot or note what is there, for the ticket.

Microsoft calls this the updated experience. The earlier “legacy” experience was retired on 30 September 2025, so if you see menu names in older guides that do not match (such as a separate MFA page for these tasks), follow the current Authentication methods blade instead. The navigation labels have changed a few times in Microsoft’s own pages, for example “Identity” and “Entra ID” for the top-level node. [UNCONFIRMED: which of these two names your portal shows today. The steps are the same.]

Step 2: choose the right action

Action in the Authentication methods blade	What it does	Use it when
Require re-register multifactor authentication (some Microsoft pages call it “Require re-register MFA”)	Deactivates the user’s hardware OATH tokens and deletes their phone numbers, Microsoft Authenticator apps and software OATH tokens. If needed, the user is asked to set up a new method the next time they sign in.	The phone is lost or replaced and you want the old methods gone, forcing a clean registration.
Revoke sessions	Invalidates the user’s refresh tokens, so they have to authenticate again across active sessions and applications.	The phone or device is lost or stolen, or you suspect the account is being used by someone else. Do this after the reset.
Add authentication method	Lets you add a method for the user. It can add a phone number or email, and the modern experience also handles Temporary Access Pass and passkeys.	You want to give the user a Temporary Access Pass, or add a phone number for them.
Reset password	Resets the password and gives a temporary one that must be changed at next sign-in.	The password may be compromised as well, for example a stolen phone. This is separate from MFA.

Older pages and answers also mention a button called Revoke multifactor authentication sessions. Microsoft’s current guidance lists Revoke sessions, and Microsoft Q&A answers say the older button can fail with “Failed to revoke multifactor authentication” and that Revoke sessions is the replacement. [UNCONFIRMED: whether the old button has been removed from your portal. Use Revoke sessions and Require re-register.]

Require re-register multifactor authentication is hard to undo. It deletes the user’s phone numbers, Authenticator registrations and software tokens at once, and the user cannot sign in with them again until they register new ones. Do not use it on someone who still uses a working method, unless the reason is a lost device. The list in Microsoft’s description does not name passkeys or FIDO2 security keys, so after a reset, look at the method list and remove any old passkey or security key that is no longer in the user’s hands. [UNCONFIRMED: whether Require re-register also removes passkeys or FIDO2 keys. Microsoft’s description lists phone numbers, Authenticator apps, software OATH tokens and hardware OATH tokens only.]

Step 3: give the user a safe way to register the new method

After a re-register, the user is prompted to set up a new method at their next sign-in, but they still have to get past sign-in, which needs a working method. The usual way to bridge this is a Temporary Access Pass (TAP): a time-limited passcode that lets the user sign in and register a new method without the old one. Microsoft describes it as making recovery easier when a user loses a strong method.

One-off: turn the policy on. A TAP can be created for any user, but only users in the TAP policy can sign in with it. An Authentication Policy Administrator (or higher) does this once:

1. In the Microsoft Entra admin center, browse to Entra ID, Authentication methods, Policies, and select Temporary Access Pass.
2. Choose Enable, then pick the users or groups who can use it (for example, a group for staff who need account recovery). Optionally select Configure to change the lifetime and length. Select Save.

The defaults are: minimum lifetime 1 hour, maximum lifetime 8 hours, default lifetime 1 hour, one-time use off, and an 8-character code. The allowed lifetime range is 10 to 43,200 minutes. If you turn on one-time use in the policy, every pass in the tenant is one-time.

Create one for the user:

1. Open the user, then Authentication methods and Add authentication method.
2. Choose Temporary Access Pass. Set a start time and a duration, and choose one-time use if the policy allows it. Select Add.
3. Copy the code now. It is shown only once, and you cannot view it again after you select OK.

A TAP is as good as the user’s identity for as long as it is valid. Use the shortest lifetime that works, one-time use, and a start time when the user is ready. Give it to the verified person only, by a different channel than the one they asked on (see the next section), and never paste it into the ticket or a chat. A user can only have one TAP, and creating a new one replaces the old one.

The user then goes to Security info, enters their sign-in name, and enters the TAP when asked. Once in, they register the new method (Authenticator, passkey or others). A TAP does not replace their password. For a one-time TAP, they must finish registering a passwordless method, such as a security key or phone sign-in, within 10 minutes of signing in with it. A multi-use TAP does not have that limit. Microsoft also says that users who update their methods because they lost a device should make sure they remove the old methods.

Step 4: sign out old sessions, then check the result

1. Select Revoke sessions in the Authentication methods blade, if you have not already. For a lost device, do this straight away, before the TAP, so the old phone cannot keep working.
2. Check that the user can sign in and register, and that the method list shows only methods they hold. Delete anything old.
3. After they have registered, delete the TAP if it is unused and still valid (for example, a multi-use pass). An expired pass can be deleted from the same blade (Delete next to the pass).
4. Add the new method to the ticket, and note the time and who verified the user.

Per-user MFA, Conditional Access and security defaults. If your tenant uses Conditional Access or security defaults, do not go to the Per-user MFA page to “enable” the user again. Microsoft says it is normal for users to appear Disabled there when those are in use, and that you should not enable per-user MFA if you use Conditional Access. If the tenant does use per-user MFA, the page is under Users, Per-user MFA (needs at least the Authentication Policy Administrator role). [UNCONFIRMED: the top-level menu name above Users in the Entra admin center for this page. Microsoft’s pages show both “Identity” and “Entra ID”.]

The same with Microsoft Graph PowerShell

Useful for repeat work and for an audit trail. These cmdlets are in the Microsoft Graph PowerShell SDK and are documented on Microsoft Learn. You sign in with permission scopes, so you can only do what your admin role allows.

# Install once, then sign in as an admin with the scopes this job needs
Install-Module Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Install-Module Microsoft.Graph.Users.Actions -Scope CurrentUser
Connect-MgGraph -Scopes 'UserAuthenticationMethod.ReadWrite.All','User.RevokeSessions.All'

$upn = 'jane.doe@contoso.com'

# See the phone methods the user has (each has an Id)
Get-MgUserAuthenticationPhoneMethod -UserId $upn

# Remove one phone method (use the Id from the line above)
Remove-MgUserAuthenticationPhoneMethod -UserId $upn -PhoneAuthenticationMethodId '<method-id>'

# Remove one Microsoft Authenticator registration (get the Id from the Authentication methods page in the admin center)
Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId $upn -MicrosoftAuthenticatorAuthenticationMethodId '<method-id>'

# Sign the user out everywhere (revokes refresh tokens and browser session cookies)
Revoke-MgUserSignInSession -UserId $upn

To create a Temporary Access Pass:

# Create a one-time Temporary Access Pass that is valid for 60 minutes from now
$params = @{
    isUsableOnce      = $true
    lifetimeInMinutes = 60
}
$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $upn -BodyParameter $params
$tap.TemporaryAccessPass     # show it once, on screen only, and do not paste it into a ticket

# Later: check whether a TAP exists (the code is not shown again) and delete one if it is not needed
Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId $upn
Remove-MgUserAuthenticationTemporaryAccessPassMethod -UserId $upn -TemporaryAccessPassAuthenticationMethodId '<method-id>'

[UNCONFIRMED: a Microsoft Graph PowerShell cmdlet equivalent to the portal button “Require re-register multifactor authentication”. I found cmdlets that delete a specific method (phone, Microsoft Authenticator) and that revoke sessions, but none that does the whole reset in one step, so the commands above remove methods one at a time.] [UNCONFIRMED: the cmdlet to list a user’s Microsoft Authenticator method Ids. Use the Authentication methods page for the Id, or look up the cmdlet in the Microsoft Graph PowerShell reference.] Microsoft’s page for managing methods also shows Select-MgProfile -Name beta after connecting. I have left it out, because the cmdlets above are the version 1.0 ones, and [UNCONFIRMED: whether that line is still needed with the current SDK].

Helping a locked-out user safely: verify identity first

The person asking you to reset someone’s MFA may not be that person. Attackers phone or message the help desk saying they lost their phone and are in a hurry. Treat every reset as a request to bypass your own security, and decide how you check identity before the next request arrives. Microsoft does not publish one required procedure for this, so what follows is practical good practice, not a Microsoft procedure. Follow your organisation’s policy where there is one.

• Do not verify through the channel they contacted you on. If the request came by email, chat or a call from an unknown number, call back on a number you already hold for them (the staff directory or HR record), not one they give you.
• Use something an attacker would not easily have. A manager’s approval through your ticketing system, a video call where you can see them and their ID badge, or confirmation in person. Do not use details that are in public profiles or on a social media page: date of birth, the manager’s name, job title.
• Be slower when it feels urgent. “I am about to board a plane and the CEO is waiting” is the classic pressure. A short delay costs little. A takeover costs a lot.
• Extra care for privileged accounts. Do not reset an administrator, finance or executive account from the help desk queue alone. Use a second approver and a higher role (see above).
• Deliver the recovery path to the right person. Give the Temporary Access Pass, if you use one, by voice to the verified person or through an approved route that only they can read, not by email to a mailbox they can no longer reach, and not in the ticket. Use one-time use and a short lifetime.
• Tell the user through another route. Send a notification to a second address or their manager saying that the methods were reset, so a real owner notices if the request was not theirs.
• After the reset: revoke sessions, confirm the user registers at least two methods, remove the old method, and review the user’s recent sign-ins and any changes to their authentication methods for signs of anything else. Record who asked, how you verified them, and what you changed.
• If anything felt wrong, do not complete the reset. Report it to your security contact. A user who really is locked out can wait a few hours, but an account that has been taken over cannot be un-taken over quickly.

Prepare for the worst case in advance. An organisation with a single administrator and no other recovery route is the most exposed. Keep at least two admins, and consider break-glass accounts. [UNCONFIRMED: Microsoft’s official recovery process if the only Global Administrator loses their only method. Microsoft Q&A answers say to contact Microsoft support and the Data Protection team, but I did not find it documented in Microsoft Learn.]

Verification

• For the user: sign out of Microsoft 365, sign in again, and use the new method when prompted. Open Security info and check that the old phone or app is gone and the new one is listed, ideally with a second method as a backup.
• For the admin: open the user’s Authentication methods blade and confirm the methods listed are the ones you expect. Run Get-MgUserAuthenticationPhoneMethod -UserId <upn> if you used PowerShell. Check that any Temporary Access Pass has expired or been deleted, and that the ticket records the verification.
• If the user is still prompted to approve on the old phone, the old method is still registered, or the sign-in is using a cached session. Revoke sessions again, then sign in from a new private browser window.

Notes

• The portal moves. Microsoft renames and moves Entra menu items regularly. The paths here follow the Microsoft Learn pages checked on 14 October 2026. If a label differs, the task is the same: user, Authentication methods.
• Do not use SMS or voice as the only method where you can avoid it. The Microsoft Authenticator app or a passkey is stronger. Keep a phone number as a backup if your policy allows it, and note that Microsoft warns against using public contact fields for MFA. Users should add their own numbers as authentication methods.
• Remember MFA on trusted devices can keep a user signed in after a phone is lost. That is another reason to Revoke sessions, which Microsoft says revokes the trusted status from all devices.
• App passwords. If the user has app passwords for old non-browser apps, an admin can delete them from the per-user MFA settings. Those apps stop working until a new one is created.
• Microsoft sources: Manage user authentication methods for Microsoft Entra multifactor authentication, Configure Temporary Access Pass, Enable per-user Microsoft Entra multifactor authentication, How it works: Microsoft Entra multifactor authentication, Troubleshoot combined security information registration, Register a passkey with a FIDO2 security key, Can’t set up MFA because five devices are already registered, Security defaults, New-MgUserAuthenticationTemporaryAccessPassMethod, Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod, Revoke-MgUserSignInSession.

Still locked out, or stuck on a step that is not covered here? Describe what the sign-in page says, with names and codes removed, in The Patch Panel and we will work through it. The best answer earns points on Top of the Stack.