Account recovery in Microsoft Entra ID: the complete playbook

Account recovery in Microsoft Entra ID runs through five mechanisms: self-service password reset (SSPR) for users who can still reach a registered method, administrator-initiated reset for users who cannot, a Temporary Access Pass (TAP) for users who have lost their strong authentication method entirely, session revocation to close out an account you believe is compromised, and Account recovery, Microsoft’s self-service flow for users who have lost every method, which proofs them through a third-party identity verification provider before issuing a TAP.

Two of the five are automated: SSPR, for users who can still reach a registered method, and Account recovery, for users who have lost every one. The other three run through a person, and that person has to decide whether the requester is really the account holder. Microsoft builds both halves: the mechanisms themselves and, in Account recovery, an identity proofing step that runs a third-party verification provider and Face Check in front of them. What the administrator-driven mechanisms assume is that the decision has already been made.

Self-service password reset, configured

SSPR “gives users the ability to change or reset their password, with no administrator or help desk involvement” (Microsoft Learn, retrieved 2026-08-18). Users register authentication methods in advance and then reset themselves through the SSPR portal.

Available methods for SSPR: Microsoft Authenticator push notifications, hardware OATH tokens (in preview), software OATH tokens, SMS sign-in, voice call, and email OTP.

Number of methods required can be set to one or two. Two constraints are easy to trip over:

• Authenticator cannot be selected as the only method when one method is required.
• Authenticator plus only one additional method cannot be selected when two are required.

Microsoft’s guidance is to enable at least one additional method beyond Authenticator when requiring one, and at least two additional when requiring two.

Registration can be enforced at sign-in through “Require users to register when signing in.” Users who dismiss the prompt are asked again at each sign-in until they complete it. Reconfirmation can be set from 0 to 730 days, where 0 means users are never asked to confirm their information again.

Hybrid environments need password writeback. With writeback configured, users whose passwords are managed on-premises can reset through SSPR. Without it, they cannot.

Unlock without reset is a separate setting. By default Entra ID unlocks the account when it performs a reset, but you can allow users to unlock an on-premises account without changing the password.

One warning in Microsoft’s documentation produces support tickets in batches. If you change which methods are available, users who have not populated the new fields lose the ability to self-serve. Microsoft’s own example: a policy using office phone and security questions is changed to allow mobile phone and alternate email instead, and every user without those fields populated can no longer reset their password.

The documented paths back to your help desk

SSPR exists to keep recovery away from a human. It is worth counting how many conditions in Microsoft’s own documentation send it straight back to one.

(All quotations Microsoft Learn, retrieved 2026-08-18.)

There is a sixth path that is not a configuration state at all: the user’s phone is gone. That covers most real recovery calls, and it lands in rows two and three.

These rows have one thing in common. Every user who reaches your help desk arrives there because the automated path did not work for them. For some it is configuration; for the largest group it is that no enrolled method is reachable. That second group is also the exact profile an attacker presents.

Microsoft’s table on changing method requirements makes the mechanic explicit:

Tightening SSPR from one method to two is good security hygiene and it moves a slice of your user base into the “unable” row. Those users do not disappear. They call.

When the authenticator phone is gone: Temporary Access Pass

This is the scenario that generates the hardest calls. Microsoft has two answers to it: a TAP issued by an administrator, covered here, and Account recovery, the self-service flow covered further down, which ends by issuing the same TAP.

A TAP is “a time-limited passcode that can be configured for single use or multiple sign-ins. Users can sign in with a TAP to onboard other passwordless authentication methods. A TAP also makes recovery easier when a user loses or forgets a strong authentication method” (Microsoft Learn, retrieved 2026-08-18).

Enabling it: sign in as at least an Authentication Policy Administrator, go to Entra ID > Authentication methods > Policies, select Temporary Access Pass, enable it, and scope the users and groups who may sign in with one. You can create a TAP for any user, but only users in the policy can sign in with it.

Issuing one: as at least an Authentication Administrator, go to Entra ID > Users, select the user, then Authentication methods > Add authentication method > Temporary Access Pass, set activation time or duration, and select Add. Record the value at that moment, because Microsoft’s documentation is explicit: “You can’t view this value after you select Ok.”

Who can issue what:

• Privileged Authentication Administrators can create, delete, and view a TAP for admins and members, but not for themselves.
• Authentication Administrators can do the same for members, but not for themselves.
• Authentication Policy Administrators enable TAP and edit the policy.
• Global Readers can see TAP details without reading the code.

Policy defaults, and the ones to change:

Set one-time use to True, and lower the maximum lifetime. One-time use ships as False, which lets a pass be reused throughout its validity window, and the allowed maximum runs to thirty days. A reusable passcode with a long life is a standing credential, and it is being handed to someone over a phone call.

Two more behaviours worth knowing before you build a runbook on this:

Each user can hold only one TAP. Issuing a new one overrides the existing pass, valid or expired.

Expiry does not contain it either. Microsoft states that “TAP expiration doesn’t retroactively invalidate sessions that are already established.” Tokens issued during a TAP sign-in are capped at the TAP expiry at the moment of issuance, but session lifetime is governed by Conditional Access, so a user who signed in with a TAP can retain access well past the pass’s lifetime unless you configure sign-in frequency. If you issue a TAP to the wrong person, letting it expire does not undo it. Revoke sessions.

A TAP also cannot be added to an external guest account, only an internal guest. And for federated domains, a TAP is preferred over federation, so the user completes authentication in Entra ID rather than being redirected to the federated identity provider.

So a TAP is a well-designed recovery mechanism, and it is also the thing an attacker most wants your help desk to issue. It signs in as the user and lets the holder register their own passwordless method. That is a description of the feature working correctly, and it is why the identity check in front of it matters more than any setting inside it.

Administrator accounts follow a different, stricter policy

By default, administrator accounts are enabled for SSPR under “a strong default two-gate password reset policy,” and Microsoft notes this policy “can’t be changed” (Microsoft Learn, retrieved 2026-08-18).

The two-gate policy “requires two pieces of authentication data, such as an email address, authenticator app, or a phone number, and it prohibits security questions.” Office and mobile voice calls are also prohibited on trial or free versions.

That single clause is worth sitting with, because Microsoft is making a security judgment in its own product: security questions are not considered adequate for privileged accounts. That is a judgment about the method, not about any one platform. If the method is not good enough for an administrator, the reasoning that makes it adequate for anyone else is worth revisiting.

The two-gate policy applies once a trial passes 30 days, or a custom domain is configured, or Entra Connect is synchronizing identities. A one-gate policy, requiring a single piece of authentication data, applies only inside the first 30 days of a trial or where no custom domain is configured and no synchronization is running.

You can disable SSPR for administrators entirely by setting AllowedToUseSspr to false on the tenant authorization policy, which can take up to 60 minutes to take effect. If you do, exclude administrators from the user password reset policy as well, or they will be prompted to register methods and then told they cannot.

The step in front of every one of these

Everything above is configuration, and it is all worth getting right. None of it answers the question your agent faces on the call. Microsoft’s own answer is Account recovery, a self-service flow that proofs the user through a third-party identity verification provider and a Face Check, then issues a Temporary Access Pass. It requires Entra ID P1, Verified ID and Face Check configured in the tenant, and a provider subscription through the Microsoft Security Store. Microsoft is investing here, and the honest planning assumption is that this flow covers more of your users over time, not fewer. The decision itself remains. Coverage is scoped by group, so it is a choice rather than a default. The match runs against the first and last name on the Entra ID profile, and Microsoft warns that a blank or mismatched name breaks it. And it is built for the user who has lost everything. The user still holding one method under a two-method policy is not locked out of everything, so never enters the flow at all. Those calls still land on a person.

Someone says they are Priya in accounts payable, their phone was stolen in a taxi, they are presenting to a client in two hours, and they cannot get in. Every recovery mechanism above is now available to your agent: reset the password, require re-registration of MFA, issue a TAP. Each one hands over control of the account.

The verification tools that used to fill this gap have stopped working.

Voice is not evidence. A voice is a sample, and samples can be reproduced. Nothing about hearing the right voice establishes that the caller controls the account.

Knowledge questions fare no better. Microsoft’s own administrator reset policy prohibits security questions outright, for every privileged account in every tenant.

Callback to a number on file is weaker than it looks. CISA lists SIM swap attacks among Scattered Spider’s core techniques, and a number that moved to a new SIM this morning still matches your directory (CISA, advisory AA23-320A).

And the attack is documented against this precise workflow. CISA records the group conducting “spearphising [sic] calls to convince IT help desk personnel to reset passwords and/or transfer MFA tokens,” and posing as employees “to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control …” (CISA, advisory AA23-320A). Mandiant put voice phishing in 23% of cloud intrusions, first in that category, and 11% overall (Mandiant, M-Trends 2026).

A hardening checklist

• Require two methods for SSPR, and accept that this moves some users into the help desk queue rather than pretending it does not.
• Deploy password writeback if any passwords are managed on-premises, or hybrid users route to your agents by default.
• Enable TAP, set one-time use to True, and lower the maximum lifetime from its eight-hour default.
• Treat TAP issuance as the highest-privilege help desk action and gate it hardest.
• Revoke sessions whenever recovery follows suspected compromise. TAP expiry does not retroactively kill established sessions, and neither does an MFA reset.
• Remind users to delete stale authentication methods after recovering, as Microsoft’s documentation advises.
• Verify identity before any of it, against something the caller does not control.
• Measure how often agents bypass verification. The bypass rate is your real coverage.

Entra ID gives you strong recovery machinery and puts the identity decision in a separate layer, with its own prerequisites. ATO Protect fills that step: it verifies a caller’s government-issued ID against the issuing authority in real time, in the United States against state DMV records over the AAMVA network, and adds SIM swap and port-out detection plus patented man-in-the-middle and anti-replay detection (US Pat. 10,601,859). It requires no pre-registration, which matters because the callers who reach your help desk are disproportionately the ones with no usable enrolled method. It runs no selfie or liveness check, because generative AI defeats those. Agents can use it through a web portal with no integration work, and the ATOP API can run the same check inside your own workflow: it integrates with almost any system that allows it, including Microsoft Entra ID. Many teams run it alongside Entra ID rather than instead of it. See ATO Protect for IT Help Desk and ATO Protect use cases, or the argument for rethinking self-service password resets.

Frequently asked questions

How does account recovery work in Microsoft Entra ID? Through five mechanisms: self-service password reset for users who can reach a registered authentication method, administrator-initiated password reset and MFA re-registration for users who cannot, a Temporary Access Pass for users who have lost their strong authentication method, session revocation to invalidate existing tokens, and Account recovery, which verifies a user’s government-issued ID through a third-party identity verification provider and issues a Temporary Access Pass when every authentication method is gone.

What authentication methods can be used for SSPR in Entra ID? Microsoft Authenticator push notifications, hardware OATH tokens (preview), software OATH tokens, SMS sign-in, voice call, and email OTP. Administrators choose how many methods a user must provide, either one or two.

What happens if a user has not registered enough methods? They cannot use SSPR and must request that an administrator reset their password. Microsoft’s documentation is explicit that a user with one registered method under a two-method policy is unable to reset or unlock.

How do I recover an Entra ID account when the user has lost their authenticator phone? Issue a Temporary Access Pass. As at least an Authentication Administrator, go to Entra ID > Users, select the user, then Authentication methods > Add authentication method > Temporary Access Pass. Record the value immediately, because it cannot be viewed again once you select Ok. The user signs in with the pass and registers a new method.

What is a Temporary Access Pass? A time-limited passcode, configurable for single or multiple use, that lets a user sign in and onboard passwordless authentication methods. It is Microsoft’s mechanism for onboarding and for recovery when a strong authentication method is lost.

Is a Temporary Access Pass safe to issue over the phone? The mechanism is sound, but the pass itself signs in as the user and lets the holder register a new authentication method, so it is only as safe as your certainty about who is asking. Set one-time use to True, lower the maximum lifetime from its eight-hour default, and verify the requester’s identity before issuing one.

Does letting a Temporary Access Pass expire undo the damage if it went to the wrong person? No. Microsoft states that TAP expiration does not retroactively invalidate sessions that are already established. Session lifetime is governed by Conditional Access, so revoke sessions and configure sign-in frequency.

Can administrators use security questions to reset their passwords? No. Administrator accounts fall under a strong two-gate password reset policy that requires two pieces of authentication data and prohibits security questions. The policy cannot be changed.

Do I still need identity verification if SSPR is configured well? Yes. Good SSPR configuration reduces how many users reach a human, but Microsoft documents four conditions where the user is told to contact an administrator, plus a fifth where SSPR cannot be used at all. The population that arrives there is disproportionately the population with no usable enrolled factor.

Entra ID can tell you the account is locked, which method is missing, and how to hand access back. Microsoft now ships the verification step too: Account recovery uses a third-party identity verification provider to check a government ID, adds Face Check against a live selfie, and issues a Temporary Access Pass at the end. It is a serious answer, and it is built for exactly the user who has lost everything. The differences worth understanding are what the ID gets checked against, since Microsoft matches the provider’s claims to the first and last name on the Entra ID profile and warns that the name on the government ID may not match, and whether you want a live selfie in the loop at all.