Passwordless account recovery in Entra ID depends on TAP and Face Check

Many Microsoft 365 and Entra ID tenants already run passwordless authentication, and for security that is a big step forward. In real projects, though, one question always comes up: what happens when a user loses their only passwordless sign-in method, be it a passkey or a phone with Authenticator and passkey? On paper, passwordless account recovery looks elegant. In practice it turns out to be a surprisingly complex area, and it needs careful, practical design.

The recovery path becomes the new attack vector

Going passwordless removes the most common attacks against passwords, but it also turns the recovery path into the new main target. In many tenants I look at, self-service options like Self-Service Password Reset (SSPR) are either far too open or locked down so tightly that users are completely stuck once their last device is gone. The real danger lies in fallback methods that are still enabled, such as email links or unverified phone numbers. If you're committed to passwordless, this is where you have to take the new risks seriously. I've covered the details in Temporary Access Pass in Entra ID: Onboarding and Recovery.

The helpdesk issues a Temporary Access Pass only after verification

Today, a secure passwordless account recovery process is built around the Temporary Access Pass (TAP). With the right role, usually Authentication Administrator, the helpdesk can issue a TAP directly (Entra admin center → Users → select user → Authentication methods → Add authentication method → Temporary Access Pass). The user signs in with it and registers a new passwordless method, for example a new passkey, or re-enrols Authenticator. The hard part is confirming who the user actually is before the TAP goes out.

Several well-established options exist for verifying identity:

• Confirmation from the user's direct manager
• Verified ID Face Check
• A combination of process security questions and direct contact

In my experience, Verified ID Face Check works particularly well and respects privacy. The helpdesk keeps no ID documents, and the workflow scales nicely. If your organisation doesn't have a solid verification step yet, add it to your roadmap. A TAP should never be issued without one.

The diagram below shows the recommended process with the manager confirming the user's identity:

sequenceDiagram
  participant User as "[User]"
  participant Helpdesk as "[Helpdesk]"
  participant Manager as "[Manager]"
  participant System as "[Entra ID System]"
  User->>Helpdesk: "[Reports lost device]"
  Helpdesk->>Manager: "[Identity confirmation]"
  Manager-->>Helpdesk: "[Identity confirmed]"
  Helpdesk->>System: "[Issue TAP]"
  System-->>User: "[TAP delivered]"
  User->>System: "[Register new passwordless method]"

Figure: Recovery with a Temporary Access Pass and manager confirmation

Multiple passkeys per user prevent most recovery cases

This one is easy to miss. The best way to avoid painful recovery situations is to make sure every user registers more than one passwordless factor. When someone has passkeys on their phone and their laptop (or a FIDO2 token as backup), losing one device stops being a crisis. Entra ID now allows multiple passkeys per account (details here). Most users still set up just one device, so it falls to us to make them aware of it and build it into onboarding.

Practical tip: Make users register at least two passwordless devices during onboarding. You'll see far fewer helpdesk tickets, and users feel more confident.

Self-service recovery through SSPR has clear limits and risks

SSPR (Self-Service Password Reset) is still around. Once all legacy methods are disabled and only passwordless is allowed, however, it only helps if the user has another authenticator app, a FIDO2 device or a verified phone number. In high-security tenants without any backup methods (I'm seeing these more often), users need to be told plainly that recovery only works through the helpdesk and a TAP. Unsecured SSPR methods such as email recovery are a backdoor and should be turned off. Keep your recovery communication and documentation completely unambiguous. If you're also moving to the new authentication method policy, have a look at Migrating to the Authentication methods policy in Entra ID.

Recovery workflows need tight roles, auditing and governance

Who gets the Authentication Administrator role is a serious governance question. In production, don't hand it to the whole helpdesk. Use Privileged Identity Management so the role is activated just in time for each recovery case. All recovery operations are audited, and a second admin should spot-check them regularly. In high-assurance environments I'd also add approval steps or additional logging.

Recovery is half of the passwordless story

A passwordless rollout is about more than the first sign-in; planning for recovery matters just as much. After several implementations, my conclusion is that recovery belongs at the centre of your security model, not in a footnote. TAP and Verified ID Face Check are mature tools, but they only become secure with a solid process, clearly defined roles and users who know what to do. In the end, the right person has to get back into their account quickly, while an attacker gets nowhere.