Temporary Access Pass: Recovery Checks

A lost phone can leave someone unable to approve sign-in or register its replacement. The support team needs a way to restore access without turning an urgent request into an uncontrolled change to the person’s identity.

A Temporary Access Pass, or TAP, is a time-limited credential that can help a user register another authentication method. Microsoft supports single-use and multi-use passes through the TAP authentication method.

The process needs a known user, an appropriate pass and a verified replacement method.

Verify the person before issuing anything

Write the identity-verification procedure before the first urgent recovery call. The helpdesk should know which established channels or in-person checks are acceptable, which requests require a second reviewer and how to escalate an uncertain identity.

Do not let the caller choose the entire verification route. A telephone number or email address supplied in the recovery request is not independent evidence that the requester owns the account.

Record the outcome of the check and the responsible operator. Keep the pass itself out of general ticket notes, screenshots and shared chat history. Decide how the verified user will receive it through the approved recovery channel.

If the device may have been stolen or the account compromised, start the incident process alongside recovery. Restoring the legitimate user’s access does not establish that an attacker has lost theirs.

Check policy and authority

The user must be included in the TAP authentication-method policy to use a pass. The role that manages the policy is different from the role that issues a pass to a user. Microsoft also distinguishes ordinary member recovery from managing administrators’ authentication methods.

Have the helpdesk verify its assigned authority before the incident. Avoid a procedure whose first step requires finding an unrestricted Global Administrator.

This guide concerns accounts managed in your tenant. An external B2B guest normally needs recovery through its home organisation; you cannot issue that guest a local TAP simply because it appears in your directory.

Choose the shortest practical validity and the appropriate use pattern for the planned task. Allow time for the user to be ready. Issuing a short-lived credential while a replacement device is still being delivered creates another recovery request.

Test the registration path against Conditional Access

A TAP being accepted does not guarantee that the user can reach every application. Microsoft’s authentication-strength documentation places TAP in the MFA strength, but not the built-in phishing-resistant strength.

Test the intended registration route with the policies that apply to the user. If those policies require a method the user has just lost, the recovery design must provide an approved route for registering its replacement.

Keep any recovery exception narrow, recorded and time-limited. A broad exclusion for the whole helpdesk population would change normal access well beyond the recovery task.

For single-use TAP registration, Microsoft documents a ten-minute registration requirement after sign-in. Practise the process with a prepared test user and device so the helpdesk knows where the time is spent.

Require a fresh sign-in with the replacement

Guide the user through registration of the approved replacement method. Then test a new sign-in that uses that method, without relying on the TAP session that performed the registration.

Choose a representative business application. Confirm that the user can complete its required authentication and that the helpdesk can identify the method used.

Use a small completion record:

Do not close the ticket because the person can see the Security info page. That demonstrates access to registration, not successful recovery of everyday work.

Address the lost method and sessions

Microsoft’s authentication-method management guidance provides separate actions for methods, password resets and session revocation. Select the action that matches the incident; these controls are not interchangeable.

Review and remove the obsolete or compromised method as appropriate. Delete an unneeded TAP and close the temporary recovery exception. A pass expiring should not be treated as a universal logout of every established application session.

If compromise is suspected, follow the incident response plan for session and credential containment. Finally, agree a supported backup authentication method so the next lost device does not reproduce the same lockout.

References

• Microsoft — Configure and use Temporary Access Pass. Accessed 17 October 2026.
• Microsoft — Manage user authentication methods. Accessed 17 October 2026.
• Microsoft — Conditional Access authentication strengths. Accessed 17 October 2026.