Temporary Access Pass in Entra ID: passwordless onboarding and recovery

A Temporary Access Pass (TAP) is a time-limited passcode in Microsoft Entra ID that an administrator issues so a user can sign in and register strong credentials, such as a passkey or Windows Hello for Business, without a password or an existing MFA method. To use it, enable the Temporary Access Pass method in the Authentication methods policy for the right groups, issue a one-time or multi-use pass to the user, and have them sign in to Security info, Microsoft Authenticator or Windows setup to register a passwordless method. The same flow recovers users who lost their phone or security key.

Who this is for and what you will have at the end

This guide is for identity administrators who want new employees to start passwordless on day one, and for helpdesk teams who need a safe way to get a locked-out user back in after a lost or replaced device.

At the end you will have:

• A Temporary Access Pass policy scoped to the users who need it, with lifetimes that match your onboarding and recovery processes.
• A Conditional Access policy that protects security info registration and accepts a TAP.
• A repeatable onboarding flow for browser, Microsoft Authenticator and Windows Autopilot.
• A recovery runbook for lost MFA methods.
• PowerShell to issue, inspect and remove passes.

How a Temporary Access Pass works

A TAP is a passcode with a start time and a lifetime. It can be limited to one sign-in or reused during its lifetime. Microsoft Entra ID treats it as a strong credential: it satisfies Conditional Access requirements for MFA, so a user who signs in with a TAP can register other methods without being asked for a second factor they don't have yet.

Key behaviours to design around:

• One pass per user. Creating a new pass replaces the existing one, whether that pass is still valid or has expired.
• Policy scope controls sign-in, not creation. You can create a TAP for any user, but only users included in the TAP policy can sign in with it.
• The value is shown once. After you close the details pane, the passcode can't be read again. Microsoft Graph returns it only in the response to the create request and returns null on later reads.
• Federated users stay in Entra ID. For federated domains, a TAP is preferred over federation; the user completes authentication in Microsoft Entra ID and isn't redirected to the federated identity provider.
• Tokens are capped, sessions are not. Tokens issued during a TAP sign-in have their maximum lifetime capped at the TAP expiry, but expiry doesn't end sessions that already exist. Use a sign-in frequency session control if you need to limit how long access lasts after a TAP sign-in.
• It's not a password replacement. Users who have a password can still use it.

Policy settings and defaults

When One-time use is False, each pass can be created as one-time or multi-use. When it is True, every pass in the tenant is one-time use.

Who can do what

Prerequisites

• An Authentication Policy Administrator to configure the policy.
• Authentication Administrators or Privileged Authentication Administrators for the helpdesk staff who will issue passes.
• Microsoft Entra ID P1 for the Conditional Access policy in Step 2.
• Combined security info registration, where users manage methods at https://mysignins.microsoft.com/security-info.
• The Microsoft Graph PowerShell SDK if you want to script issuance. The TAP policy and pass cmdlets used here are in the Microsoft.Graph.Identity.SignIns module; Revoke-MgUserSignInSession is in Microsoft.Graph.Users.Actions.
• For Windows onboarding: devices that will be Microsoft Entra joined. TAP isn't supported for Windows Autopilot with Microsoft Entra hybrid join.

Step 1: Enable the Temporary Access Pass policy

1. Sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator.
2. Go to Entra ID > Authentication methods > Policies and select Temporary Access Pass.
3. Select Enable, then include the groups that should be able to sign in with a pass. Exclude groups that never should, such as shared mailbox accounts.
4. Select Configure to change lifetimes, length and one-time use, then Update.
5. Select Save.

Pick lifetimes that match how you work. A new starter who picks up a laptop on their first morning may need a pass that starts at 08:00 and lasts a few hours. A helpdesk recovery call needs a pass that is usable immediately and expires within the hour.

You can set the same values through Microsoft Graph. The @odata.type property is required in the request body:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
 
$params = @{
    "@odata.type"            = "#microsoft.graph.temporaryAccessPassAuthenticationMethodConfiguration"
    isUsableOnce             = $false
    minimumLifetimeInMinutes = 60
    maximumLifetimeInMinutes = 480
    defaultLifetimeInMinutes = 60
    defaultLength            = 8
}
 
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "TemporaryAccessPass" `
    -BodyParameter $params

Leaving isUsableOnce set to $false at the policy level doesn't make every pass reusable. It lets the issuer choose per pass, which you need for Windows onboarding (see Step 4).

Step 2: Protect security info registration

Without a policy on registration, anyone who learns a user's password could register their own MFA method. Microsoft's template policy secures the Register security information user action and is designed to work with TAP:

1. Sign in as at least a Conditional Access Administrator and go to Entra ID > Conditional Access > Policies > New policy.
2. Name it, for example Combined Security Info Registration with TAP.
3. Users: include All users; exclude All guest and external users (TAP doesn't work for guest users) and your emergency access accounts.
4. Target resources > User actions: select Register security information.
5. Conditions > Locations: include Any location, exclude All trusted locations.
6. Grant: Require authentication strength and pick a strength the TAP can satisfy.
7. Set Enable policy to Report-only, create it, review the results, then switch it On.

Choose the strength carefully. A TAP satisfies the built-in Multifactor authentication strength only. If you require Passwordless MFA or Phishing-resistant MFA for registration, a new user holding only a TAP can't register anything. Use the Multifactor authentication strength, or a custom strength that includes Temporary Access Pass, for this policy.

Microsoft announced that from July 6, 2026, policies targeting Register security information also apply when users register Windows Hello for Business and macOS Platform SSO credentials. Test the policy against your Windows onboarding flow in report-only mode before enforcing it.

Step 3: Issue a pass

In the admin center

1. Sign in as at least an Authentication Administrator.
2. Go to Entra ID > Users, select the user, then Authentication methods > Add authentication method.
3. Select Temporary Access Pass, set a custom activation time or duration if needed, and select Add.
4. Copy the pass from the details pane before you select OK. You can't view it again.

With PowerShell

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All"
 
$params = @{
    startDateTime     = [System.DateTime]::Parse("2026-10-12T07:30:00Z")
    lifetimeInMinutes = 240
    isUsableOnce      = $false
}
 
$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId "adele@contoso.com" -BodyParameter $params
$tap.TemporaryAccessPass

lifetimeInMinutes must be between 10 and 43,200 and within the policy limits; if you omit it, the policy default applies. If you omit startDateTime, the pass is usable immediately. A multi-use pass (isUsableOnce = $false) can only be created if the policy allows it.

Deliver the pass through a channel separate from the username, such as handing it to the new starter's manager or reading it out on a verified call. Treat it like a password for its whole lifetime.

Step 4: Onboard a new user

Browser and Microsoft Authenticator

1. The user opens https://mysignins.microsoft.com/security-info and enters their UPN.
2. If they are in scope of the TAP policy, they are prompted for the pass instead of a password.
3. They select Add sign-in method and register a passkey, a security key or Microsoft Authenticator.

Alternatively, the user adds their work account in Microsoft Authenticator, signs in with the TAP, and registers a passkey or passwordless phone sign-in directly in the app.

With a one-time pass, the registration must finish within 10 minutes of sign-in. This 10-minute window applies to any new method registration that requires MFA, not only to TAP. For where phishing-resistant sign-in fits in a wider access model, see the zero trust remote access architecture.

Windows setup and Autopilot

On devices being Microsoft Entra joined, the user can enter the TAP during join setup, with no password, and register Windows Hello for Business in the same flow. Windows Autopilot supports TAP for Microsoft Entra join in user-driven mode, pre-provisioning, and self-deploying mode for shared devices. It isn't supported for Autopilot hybrid join and isn't applicable to self-deploying kiosks.

Plan for the time the enrollment takes:

The standard Windows credential provider doesn't accept a TAP. If the device restarts and shows the normal sign-in screen, the user needs Web sign-in, which you enable with the EnableWebSignIn policy:

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Authentication/EnableWebSignIn
Format:  Integer
Value:   1  (0 = default behaviour, 1 = enabled, 2 = disabled)

Web sign-in is supported only on Microsoft Entra joined PCs, and Microsoft intends TAP sign-in to Windows through it only for initial device setup or recovery when the user doesn't know or have a password.

On devices that are already joined, and on hybrid joined devices, the user must first sign in with another method, such as a password, smart card or FIDO2 key, before using a TAP to set up Windows Hello for Business.

Step 5: Recover a user who lost their MFA method

A TAP is also the cleanest recovery path when a user loses their phone or security key:

1. Verify the person. Confirm identity through a process you trust, such as a video call with their manager or an in-person check, before issuing anything. The TAP is only as strong as this step.

2. Revoke sessions if a device was lost or stolen. This invalidates refresh tokens and browser session cookies for the user. Microsoft notes there can be a delay of a few minutes before tokens are revoked.

   Connect-MgGraph -Scopes "User.RevokeSessions.All"
   Revoke-MgUserSignInSession -UserId "adele@contoso.com"

3. Issue a short, one-time pass that starts immediately.

4. Have the user register a new method in Security info and remove the old one. Microsoft's guidance is that users who update methods after losing a credential or device should remove the old methods.

5. Delete the pass if it hasn't expired, so nothing usable is left on the account.

If your tenant uses certificate-based authentication for some users, a TAP is also one of the documented ways to get a CBA user through MFA when they can't use their certificate; see configuring Entra certificate-based authentication.

Verify

Check a user's pass state without exposing the code:

Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId "adele@contoso.com" |
    Select-Object Id, IsUsable, IsUsableOnce, MethodUsabilityReason, StartDateTime, LifetimeInMinutes

MethodUsabilityReason explains IsUsable: EnabledByPolicy, DisabledByPolicy, Expired, NotYetValid or OneTimeUsed.

Then confirm:

• The user's Authentication methods blade shows the new passkey or Windows Hello for Business method.
• The sign-in logs show the TAP sign-in, followed by sign-ins with the new method.
• Users can see the TAP and its expiry in Security info, and can delete it themselves once they have another method.

To remove a pass:

Remove-MgUserAuthenticationTemporaryAccessPassMethod -UserId "adele@contoso.com" `
    -TemporaryAccessPassAuthenticationMethodId "<pass id from Get-MgUserAuthenticationTemporaryAccessPassMethod>"

Troubleshooting

The user isn't prompted for a TAP. The user isn't in scope of the TAP policy, the pass isn't valid yet or has expired, or a one-time pass was already used. Changes can take a few minutes to replicate, so a new pass may not prompt immediately, and an expired one may still prompt briefly.

Temporary Access Pass sign in was blocked due to User Credential Policy. Check that the user is in the policy scope, that a one-time pass hasn't already been used, and that the user doesn't hold a multi-use pass while the policy requires one-time use.

Temporary Access Pass cannot be added to an external guest user. The account is an external guest. Only internal guests can be issued a pass. For partner users, trust MFA from their home tenant instead, as described in Entra cross-tenant access settings for B2B.

The user is forced into a registration wizard that won't offer passkeys. Users in scope of the SSPR registration policy or the ID Protection MFA registration policy are redirected to interrupt-mode registration after a TAP browser sign-in, and that experience doesn't support FIDO2 or phone sign-in registration. Exclude onboarding users from those policies or have them register in Microsoft Authenticator.

Registration is blocked by Conditional Access. The Register security information policy requires a strength the TAP can't meet, such as phishing-resistant MFA. Switch the policy to the Multifactor authentication strength or a custom strength that includes TAP.

Windows doesn't show a TAP prompt during Windows Hello setup on a federated domain. If FederatedIdpMfaBehavior is enforceMfaByFederatedIdp, the user is sent to the federated IdP for MFA instead. With acceptIfMfaDoneByFederatedIdp, the TAP prompt appears.

RADIUS or AD FS sign-ins fail with a TAP. A TAP can't be used with the NPS extension or the AD FS adapter.

Checklist

• TAP method enabled and scoped to onboarding and recovery groups, with lifetimes set deliberately.
• Policy one-time use left off if you need multi-use passes for Autopilot.
• Register security information policy in place, using a strength a TAP satisfies.
• Helpdesk issuers hold Authentication Administrator, and only admin-recovery staff hold Privileged Authentication Administrator.
• Identity verification step written into the recovery runbook.
• Web sign-in enabled for Entra joined Autopilot devices that need it.
• Sessions revoked and old methods removed after a lost device.
• Leftover passes deleted once users have a passwordless method.

References

• Configure a Temporary Access Pass in Microsoft Entra ID
• temporaryAccessPassAuthenticationMethodConfiguration resource type
• Update temporaryAccessPassAuthenticationMethodConfiguration
• Create temporaryAccessPassMethod
• temporaryAccessPassAuthenticationMethod resource type
• Control security information registration with Conditional Access
• Overview of Conditional Access authentication strengths
• Windows Autopilot scenarios and capabilities
• Authentication Policy CSP
• user: revokeSignInSessions