Temporary Access Pass in Entra ID simplifies onboarding and recovery

Almost every Entra ID project runs into the same chicken-and-egg problem at some point. A new hire, or a user who has lost all their authentication methods, needs to register passwordless sign-in, but has nothing to sign in with first. The old workaround was a temporary password, and that annoys users and security teams in equal measure. The Temporary Access Pass (TAP) solves exactly this. A lot of organizations now rely on it for onboarding and for helping users who have locked themselves out. It's a passcode that an admin issues for a limited time, and it allows passwordless registration in a secure and auditable way.

A Temporary Access Pass is a short-lived code for registering new methods

A TAP is a code with a short validity window. An admin or a designated helpdesk hands it to a user who needs to register new authentication methods, whether that's the Authenticator app, a FIDO2 key or Windows Hello for Business. It isn't the same as a one-time password reset. TAP is designed around strong authentication, it's only meant for registration or recovery, and it never turns into a long-term credential. I've watched quite a few IT teams relax noticeably once they started using TAP for onboarding, or for users who lost access after losing a device or after a support incident. For the details, start with the official Microsoft docs.

Admin roles and the methods policy control who issues a TAP and for how long

By default, roles such as Authentication Administrator or Privileged Authentication Administrator can create TAPs. In practice, though, I regularly find that helpdesk staff have been given this right far too generously. Without strict processes and monitoring behind it, that leaves the door open for social engineering. Keep TAP creation limited to dedicated groups that you audit properly, and define TAP usage narrowly in the authentication methods policy (see Microsoft's overview). That's where you decide whether TAPs are single-use or multi-use and how long they can live at most. The default is one hour, and you can go up to eight. My advice is to pick the shortest lifetime your operations can handle. For most scenarios that means 30–60 minutes, with longer windows reserved for special cases like global onboarding.

Practical tip: Use different TAP lifetimes for onboarding and for recovery. Short-lived, single-use TAPs keep the risk down, while longer windows can help with international rollouts or shift workers.

If you want to automate issuance, Microsoft Graph PowerShell keeps it simple. This creates a single-use TAP valid for 30 minutes:

# Example: Single-use TAP valid for 30 minutes
New-MgUserAuthenticationTemporaryAccessPassMethod -UserId [email protected] -IsUsableOnce $true -LifetimeInMinutes 30

TAP and Autopilot work well together for device provisioning

For new devices, and Windows Autopilot in particular, TAP is an excellent fit. Users sign in with their TAP and then set up their passwordless methods (FIDO2, Windows Hello for Business) during the initial out-of-box experience. The helpdesk barely has to get involved, and onboarding goes a lot more smoothly, which matters most for remote and hybrid teams. For first-time device setup, TAP plus Autopilot is now the approach I'd recommend by default. Just make sure the TAP stays valid long enough for the whole registration flow, and not so long that it turns into a security risk.

Conditional Access treats TAP as strong authentication

How TAP interacts with Conditional Access needs careful thought. Since TAP counts as strong authentication, it satisfies many Conditional Access policies, sometimes more of them than you'd like. For highly sensitive apps, think about explicitly excluding TAP or building dedicated policies for the TAP registration process. And review your Conditional Access setup regularly. I've written about some best practices in Conditional Access: Getting Started.

Helpdesk identity verification is where social engineering succeeds

However well the technology works, the real risk sits in the verification step before anyone issues a TAP. Far too many organizations hand out TAPs after a quick phone call or an email, and that practically invites social engineering. Put proper, layered verification in place, such as callbacks, video identification, knowledge-based checks, or supervisor approval for sensitive requests. Audit TAP issuance closely and document every case clearly.

The diagram below shows the TAP flow from the initial request to a successful registration:

flowchart TD
  user["User"] --> helpdesk["Helpdesk/Admin"]
  helpdesk --> tap["Generate TAP"]
  tap --> login["Login with TAP"]
  login --> regauth["Register new method"]
  regauth --> ready["Service access"]

Figure: Typical flow for user registration or recovery with TAP

A small feature like TAP has an outsized impact in my view

Temporary Access Pass doesn't make much noise, but it changes onboarding and recovery considerably, and more so as passwordless authentication becomes the default. I think TAP belongs in every modern identity lifecycle, as long as you pair it with well-designed processes and tight delegation. Set up properly, it gives users a safe and easy path to passwordless sign-in, with fewer tedious support calls, fewer risky workarounds and less frustration for users. If you're planning a migration of your authentication methods, my earlier post on Entra ID authentication methods policy migration may help.