How do you verify someone's identity before resetting their MFA?

Never on the strength of the request alone. Call the person back on a phone number already on file rather than one they've just given you, or have a manager or colleague who already knows them confirm — ideally on a video call. Correct personal details offered by the caller prove nothing, since that information can often be found online or from a prior data breach. If identity can't be confirmed through an independent channel, the request should wait until it can.

Should MFA be turned off to fix a lockout?

No. The fix is to remove the specific authentication method that's no longer accessible — a lost phone's Authenticator registration, for example — in the user's authentication methods in Microsoft Entra ID, without disabling MFA on the account itself. Turning MFA off, even temporarily, removes the account's main protection for as long as it stays off, and that window is exactly when an account is most exposed.

What is a Temporary Access Pass?

A Temporary Access Pass (TAP) is a time-limited passcode an administrator issues against a user's account in Microsoft Entra ID. The user signs in with it instead of their usual MFA method, and that sign-in can be used to register a new authentication method on a current device — which is what turns a lost-phone lockout into a five-minute fix rather than a drawn-out one. It has to be enabled in the tenant's authentication methods policy before it's needed.

What should be set up before an MFA lockout happens, not during one?

Temporary Access Pass enabled in the tenant, every user registered with more than one authentication method where practical, a documented identity verification process, and a clear record of who is authorised to action a reset. Businesses that set these up in advance turn a lockout into a routine five-minute call. Businesses that don't end up making decisions under pressure, which is exactly when mistakes and successful social engineering happen.

Why is a locked-out MFA call a common social engineering target?

Because a genuine lockout and a social engineering attempt sound identical over the phone — both are urgent, both come from someone claiming to need access restored right now. Attackers rely on that urgency to skip verification. A help desk process that always confirms identity through an independent channel, regardless of how convincing or senior the caller sounds, closes that gap.

Locked out of multifactor authentication: the recovery runbook

A user locked out of multifactor authentication (MFA) is one of the most common calls a small business IT contact gets, and one of the easiest to get badly wrong under pressure. It happens the same handful of ways: a phone is lost, stolen or replaced and the Microsoft Authenticator app on it is gone; the app got wiped along with everything else in a factory reset; or someone left their work phone at home, or at their old job, and has no way to approve a sign-in prompt. In every case, the person is genuinely locked out of their own account, and someone with admin access has to step in and reset their authentication methods to let them back in.

That admin action — resetting or removing someone's registered MFA methods so they can register new ones — is also exactly what an attacker wants a help desk to do for them. A confident phone call claiming to be a locked-out executive, asking for MFA to be reset right now, is one of the oldest tricks in social engineering, and it works precisely because it's dressed up as an urgent, sympathetic, ordinary request. The verification step below isn't bureaucracy for its own sake. It's the one thing standing between a genuine lockout and a stranger talking their way into an account.

Verify who you're actually talking to, before anything else

The request to reset someone's MFA should never be actioned on the strength of the request alone, no matter how convincing, senior, or urgent it sounds. The caller providing correct personal details — a date of birth, an employee number, even a manager's name — proves nothing on its own; that information is often available from a LinkedIn profile, a prior data breach, or a few minutes of searching. What actually confirms identity is a channel the attacker doesn't control.

Call the person back on a phone number already on file, not a number they just gave you.
Ask a manager or a colleague who already knows them to confirm, ideally on a video call where the person is visibly who they say they are.
Treat an out-of-hours, high-pressure request — "I need this right now, I'm about to walk into a meeting" — as a reason to slow down, not speed up.
If none of the above is possible immediately, it is entirely reasonable to make the person wait until it is.

Resetting authentication methods without turning off MFA

Once identity is confirmed, the fix happens in the user's authentication methods in Microsoft Entra ID, where an administrator can remove the specific method that's no longer accessible — the lost phone's Authenticator registration, for instance — without touching anything else registered to the account, and without disabling MFA on the account itself. Turning MFA off, even briefly, to get someone back in is the move to avoid: it leaves the account without its main protection for however long it takes to sort the rest out, and it's a habit that tends to outlive the emergency that started it.

For a full replacement — a new phone, a wiped app, nothing usable left — the practical path is to remove the old, inaccessible method and then have the user register a fresh one, using a Temporary Access Pass to get them through that registration securely. That's the cleaner alternative to an admin trying to manually recreate or transfer an authenticator registration, which generally isn't possible anyway once the original device is gone.

Temporary Access Pass: the clean way back in

A Temporary Access Pass, usually shortened to TAP, is a time-limited, single- or limited-use passcode an administrator can issue against a user's account in Microsoft Entra ID. The user enters it in place of their usual authentication method, which gets them signed in without needing anything from the device they've lost — and, critically, that sign-in can be used specifically to register a new MFA method there and then. It's the mechanism that turns "lost phone, no way in" into a five-minute fix: issue the pass, the user signs in with it, registers Authenticator on their new or replacement phone, and the account is fully back to normal before the call ends.

TAP has to be enabled in the tenant's authentication methods policy before it's needed — it isn't switched on by default, and discovering that on the day of a lockout just adds another delay to an already stressful call. It's worth treating as one of the standard settings enabled during initial tenant setup, alongside MFA itself, rather than something configured reactively.

What has to be in place before the crisis, not during it

The difference between a five-minute fix and a genuinely stressful hour comes down almost entirely to what's already set up before anyone is locked out. A few things make the difference:

Temporary Access Pass enabled in the tenant, so it's available the moment it's needed rather than something to configure under pressure.
Every user registered with more than one MFA method where practical, so a lost phone doesn't mean a total lockout with no fallback at all.
A documented identity verification process that doesn't rely on the judgement of whoever happens to answer the phone that day.
A clear, written record of who is authorised to action an MFA reset, so it isn't whoever's available, and so there's a log of who approved what.
A short internal runbook — the steps above, written down — so a lockout is handled the same way regardless of which staff member takes the call.

The MFA lockout recovery runbook

1Confirm the person's identity through a channel the caller doesn't control — a callback on a known number, or confirmation from a manager or colleague who already knows them.
2Do not action the reset on the strength of the request alone, and do not let urgency shortcut the verification step.
3In the user's authentication methods in Microsoft Entra ID, remove the specific method that's no longer accessible, rather than disabling MFA on the account.
4Issue a Temporary Access Pass for the account, and have the user sign in with it.
5While signed in on the pass, the user registers a new MFA method on their current device.
6Confirm the new method works with a real sign-in before closing out the request, and record what was reset, when, and who approved it.

Handled this way, an MFA lockout is a short, calm process: verify, reset the one thing that needs resetting, issue a pass, watch the person register a new method, done. Handled without the groundwork — no TAP enabled, no documented verification step, whoever picks up the phone making the call — it turns into exactly the kind of pressured, undocumented decision that either leaves someone locked out for hours or lets an attacker in the front door.