Temporary Access Pass: The Passwordless Bootstrap Nobody Talks About

A new hire's laptop arrives on day one. They've never signed in before, have no password of their own yet, and need to enroll in Windows Hello for Business before they can do anything else. Or the opposite scenario: an existing user's phone with their only registered authentication method is lost, stolen, or simply reset, and now they can't sign in to register a replacement — the classic passwordless chicken-and-egg problem. Both situations have the same answer, and it's a feature most tenants have sitting unconfigured: a Temporary Access Pass.

The problem — passwordless recovery needs something that isn't a password

A Temporary Access Pass (TAP) is a time-limited passcode Entra ID issues to a specific user, letting them sign in and register a real authentication method — Windows Hello for Business, a FIDO2 security key, phone sign-in via Microsoft Authenticator — without ever touching a password. Microsoft's own documentation is direct about the two situations it exists for: helping users bootstrap passwordless methods when they don't have one yet, and making recovery easier when someone loses or forgets their strong authentication method.

Without TAP, both scenarios usually collapse back into a password: a temporary one set by a helpdesk agent, emailed or read aloud over the phone, that the user then uses to sign in and register their real credential. That's the exact pattern security teams have spent years trying to eliminate — a password, transmitted in the clear, as the weak link in an otherwise passwordless chain. TAP exists specifically to remove that weak link.

Why it happens — nobody enables the policy until they need it in an emergency

TAP has existed as a generally available Entra ID feature for years, yet it's routinely still disabled by default in tenants that would benefit from it the most. The reason is almost always the same: the feature only becomes visible as a need during an actual incident — a locked-out user calling the helpdesk in a panic — at which point enabling and configuring the policy correctly, under pressure, is exactly the wrong time to be reading documentation for the first time.

Configuring the TAP Authentication methods policy requires the Authentication Policy Administrator role. Here's exactly what that looks like in the portal, step by step:

Select Save and the policy is live. Note that "8 hours" for maximum lifetime is only the starting default — every one of these settings can be set anywhere within its allowed range, so a maximum lifetime of several days, or up to the full 30-day ceiling, is entirely valid if that suits how your organisation uses TAP.

The one-time-use setting is where most of the real decision-making happens, because Microsoft's own guidance describes a genuine gotcha in how it interacts with device enrollment timing.

How to verify — check the policy state and one user's TAP status before deploying broadly

Confirm whether TAP is currently enabled, and for which users or groups, before assuming it's available. If it's already enabled, spot-check one real user's TAP status in the portal before building anything larger — no PowerShell needed for this part:

Notice the one thing the portal never shows here: the actual TAP code itself. Microsoft's documentation is explicit that the pass value can only be viewed once, at the moment of creation — after you close that dialog, it is gone permanently. There's no "look it up again later" for a TAP, by design. (If you'd rather check this via PowerShell instead of the portal, Get-MgUserAuthenticationTemporaryAccessPassMethod does the same thing — see the References section at the end of this post.)

The fix — create, use, and correctly scope a Temporary Access Pass

Creating one for a user takes three clicks in the portal. Note the exact role requirements first, because they're stricter and more specific than most authentication method operations: Privileged Authentication Administrators can create, delete, and view a TAP for admins and members (except themselves); Authentication Administrators can do the same for members only (except themselves).

The user then goes to mysignins.microsoft.com/security-info, enters their UPN, and is prompted for the TAP instead of a password. From there they register whatever real method they need — a WHfB PIN and biometric, a FIDO2 key, or Microsoft Authenticator. (Prefer to automate this for many users at once? New-MgUserAuthenticationTemporaryAccessPassMethod does the same thing via PowerShell — see References.)

Troubleshooting the Intune side of TAP-based enrollment

A TAP itself is an Entra ID authentication method, not an Intune policy — Intune never configures or reads it directly. But the moment a device joins using a TAP, Intune's own configuration profiles (which push settings, including the WHfB policy the user is about to register against) and compliance policies (which only evaluate and report a pass/fail state, never configure anything) both come into play through the Enrollment Status Page. Understanding that handoff explains one of the more confusing TAP failure modes.

When a TAP-based enrollment stalls or a user reports their TAP "stopped working" mid-setup, check the Intune side before assuming the TAP itself is at fault:

For the registry-level detail, the same two hives matter here as in any enrollment troubleshooting: SOFTWARE\Microsoft\Enrollments (the enrollment record created the moment the TAP-based join completes) and PolicyManager\current\device (where configuration profile results land once policy actually reaches the device). This site's own local Intune policy export script reads both in one pass rather than opening Registry Editor manually.

Proof it worked — Get-TapAuditReport.ps1

Once TAP is in regular use for onboarding and recovery, the real ongoing risk isn't the feature itself — it's a TAP created during an incident and then forgotten about, sitting active longer than intended, especially on a privileged account. This script audits every user in the tenant with a currently active or recently created TAP, and separately flags any privileged role holder with one, since that's the combination worth a human looking at immediately rather than during a routine review. It also accepts an optional list of specific UPNs via -UserPrincipalName, added after testing this against a large tenant made clear that checking a handful of accounts (a new hire, a recovery incident) shouldn't require enumerating every user in the directory first.

References

• Configure a Temporary Access Pass in Microsoft Entra ID — Microsoft Learn
• New-MgUserAuthenticationTemporaryAccessPassMethod — Microsoft Learn
• Authentication Administrator role — Microsoft Learn
• Session lifetime and Conditional Access — Microsoft Learn
• MVP Feed — EndpointWeekly
• Passkeys Are Now the Default in Entra ID — EndpointWeekly