Temporary Access Pass and Secure Onboarding

We’ve spent the previous parts of this series talking about stronger authentication.

Passkeys.

FIDO2 security keys.

Authentication Strengths.

Trust Levels.

Conditional Access.

But all of this creates a surprisingly difficult problem.

How does somebody securely register their first authentication method when they don’t have an authentication method yet?

It’s the authentication equivalent of a chicken-and-egg problem.

We’ve decided that an administrator must use a FIDO2 security key.

Great.

But they don’t have one registered yet.

We’ve decided that users should authenticate using passkeys.

Great.

But they need to register the passkey before they can use it.

And registering a new authentication method is itself a security-sensitive operation.

So how do we establish enough initial trust to allow somebody to register the credential that we’re going to trust in the future?

This is where Temporary Access Pass (TAP) becomes incredibly useful.

Microsoft describes Temporary Access Pass as a time-limited passcode that can be used to bootstrap passwordless authentication methods.

You can find Microsoft’s technical guidance in Configure Temporary Access Pass to register passwordless authentication methods.

But I think TAP is more important architecturally than simply being another Microsoft Entra authentication feature.

TAP solves the bootstrap problem.

And it can also solve one of the most difficult problems we face with passwordless authentication:

Recovery.

What Is Temporary Access Pass?

Temporary Access Pass is a time-limited passcode issued through Microsoft Entra.

It can be used to bootstrap authentication methods such as:

Passkeys
FIDO2 security keys
Microsoft Authenticator
Windows Hello for Business

A TAP can be configured for:

Single use
Multiple use

and is valid for a defined period.

That makes it particularly useful for two scenarios.

Bootstrap

A new user has no existing authentication method and needs to establish their first strong credential.

Recovery

An existing user has lost access to their authentication method and needs to securely establish a replacement.

In both cases, TAP provides something incredibly useful:

A temporary bridge into stronger authentication.

The Chicken-and-Egg Problem

This is where passwordless authentication gets interesting.

Imagine we’ve decided that a TL1 administrator must authenticate using a dedicated FIDO2 security key.

We’ve created our Authentication Strength.

We’ve built our Conditional Access policy.

We’ve issued the administrator their security key.

There’s just one problem.

The security key isn’t registered yet.

The administrator needs to go to Security Info and register the FIDO2 security key against their privileged identity.

But before we allow somebody to register a new authentication method, we need confidence that the person performing the registration is actually the owner of the identity.

So we have a circular problem:

You need strong authentication to register strong authentication, but the user doesn’t have strong authentication because that’s what they’re trying to register.

This is exactly the problem TAP solves.

After appropriate identity verification, we can issue a temporary credential that allows the administrator to establish their permanent high-assurance credential.

The journey becomes:

Verify Identity → Issue TAP → Sign in to Security Info → Register FIDO2 Key → Validate FIDO2 Key → TAP No Longer Required

For a controlled TL1 onboarding process, this is one of the scenarios where I particularly like a single-use TAP.

The administrator is ready.

The security key is ready.

The TAP is generated.

They go directly to Security Info, register the key and the bootstrap credential has served its purpose.

Clean.

Controlled.

Short-lived.

Is TAP Really MFA?

This is where my view differs slightly from how we normally talk about authentication methods.

Microsoft Entra can treat Temporary Access Pass as an authentication method capable of satisfying authentication requirements in supported scenarios.

Technically, that’s important.

Architecturally, however, I don’t think of TAP as MFA in the same way I think about a passkey or dedicated FIDO2 security key.

To me, TAP is closer to a glorified temporary password.

That’s not intended as criticism.

In fact, it’s precisely why TAP is so useful.

Think about traditional new starter onboarding.

Historically, we might create an account and provide the user with:

Username + temporary password

That password provides enough initial trust for the user to establish their account.

TAP gives us a much better modern equivalent.

Instead of:

Temporary Password → Permanent Password

we can have:

Temporary Access Pass → Passkey

or:

Temporary Access Pass → Dedicated FIDO2 Security Key

The important distinction is this:

TAP isn’t the authentication experience we’re trying to build. It’s the temporary credential that gets us there.

Once the user’s proper authentication method has been established, the TAP has served its purpose.

Bootstrap, Don’t Depend

This distinction matters when designing Authentication Assurance.

I don’t want a TL1 administrator routinely authenticating using TAP.

I want TAP to allow that administrator to securely register the dedicated FIDO2 security key they’ll use going forward.

Likewise, I don’t want a workforce user repeatedly using TAP because it’s convenient.

I want TAP to help them establish their passkey, Windows Hello for Business credential or another approved authentication method.

Think of TAP as scaffolding.

It’s incredibly useful while you’re constructing something.

But once the structure exists, the scaffolding shouldn’t become the building.

Single-Use or Multi-Use?

One of the first decisions organisations need to make is whether Temporary Access Pass should be single-use or multi-use.

At first glance, this seems easy.

Single-use must be more secure.

In isolation, it is.

One credential.

One successful use.

Then it’s gone.

But Authentication Assurance can’t just consider the credential.

We also need to consider the journey.

And that’s where the decision becomes much more interesting.

The Credential You’re Registering Matters

I don’t believe organisations should blindly mandate either single-use or multi-use TAP.

The right choice depends partly on what the user is trying to establish.

Different authentication journeys behave differently.

Microsoft Authenticator Passkey

For a device-bound passkey in Microsoft Authenticator, I find single-use TAP works extremely well.

The journey can be beautifully simple:

Verify Identity → Issue TAP → Sign In → Register Passkey → Done

That’s exactly what I want from a bootstrap credential.

There’s little reason for the TAP to remain available afterwards.

The user now has their permanent phishing-resistant authentication method.

The temporary credential has done its job.

For this type of controlled registration journey, single-use TAP is ideal.

Dedicated FIDO2 Security Key

The same is true for privileged administration.

If I’m onboarding a TL1 administrator and their dedicated FIDO2 security key is physically available, the workflow can be tightly controlled.

For example:

Verify Identity → Issue FIDO2 Key → Generate Single-Use TAP → Sign In to Security Info → Register FIDO2 → Validate FIDO2 → Done

Again, single-use makes perfect sense.

We don’t need the TAP hanging around afterwards.

We’ve used temporary trust to establish permanent high-assurance authentication.

This is one of the cleanest onboarding journeys we can create.

Synced Passkeys

Synced passkeys can make the journey more complicated.

The eventual user experience of a synced passkey can be excellent.

But getting the user from:

No authentication method

to:

Passkey registered and available where they need it

isn’t necessarily as simple as the Authenticator passkey or controlled FIDO2 registration scenarios.

The user may be working across different devices.

Their passkey provider may need to be configured.

The registration process may be part of a broader device onboarding journey.

Additional authentication events may occur before the process is complete.

Suddenly, our beautifully secure single-use TAP can become an operational obstacle.

The user consumes it.

Then later in the process they’re asked to authenticate again.

And they can’t.

Now they need another TAP.

Which means another support interaction.

Potentially another identity verification event.

Another administrator action.

And another opportunity for social engineering.

This is where multi-use TAP starts to make considerably more sense.

Device Onboarding Makes This Even More Important

The same problem appears when TAP is used during Windows device onboarding.

A new starter might need to:

Sign into their new device.
Complete Microsoft Entra join.
Complete Intune enrolment.
Wait for policies and applications.
Configure Windows Hello for Business.
Access Security Info.
Register additional authentication methods.

That’s not necessarily one authentication event.

And it doesn’t necessarily happen quickly.

Microsoft specifically documents scenarios where a single-use TAP used during Windows onboarding can result in the user needing another TAP later in the process.

You can read Microsoft’s current behaviour and guidance in Configure Temporary Access Pass to register passwordless authentication methods.

This is where we need to stop thinking about single-use and multi-use as a simple security score.

The Case for Single-Use TAP

Single-use TAP provides a very clear security property:

One credential. One use.

Once it’s consumed, it can’t simply be reused.

That’s particularly attractive where:

The user has already been verified.
The authenticator is ready.
Registration is happening immediately.
The workflow requires a single authentication event.
Support is available if something goes wrong.

That’s why I particularly like single-use TAP for:

Microsoft Authenticator passkey registration
Controlled FIDO2 security key registration
High-assurance administrator onboarding

When the workflow supports it, single-use is clean and predictable.

The Case for Multi-Use TAP

Multi-use TAP provides something different.

Operational flexibility.

The same TAP can be used more than once during its validity period.

That may be appropriate where the user needs to complete several authentication events before their permanent authentication methods are fully established.

For example:

TAP → Device Sign-in → Enrolment → Security Info → Passkey Registration → Windows Hello

The advantage is obvious.

The user doesn’t need to contact the Helpdesk every time another authentication prompt appears.

But there’s an equally obvious trade-off.

The TAP remains a valid credential until it expires.

That means duration becomes extremely important.

How Long Should a TAP Last?

The obvious security answer is:

As short as possible.

And I agree.

But I’d add something important:

As short as possible while still being operationally useful.

There’s little value in creating a TAP with such a short lifetime that users routinely fail to complete onboarding before it expires.

Imagine a new starter receives their TAP at 08:00.

Their laptop isn’t available until 10:30.

They join an induction call.

They speak to their manager.

They start configuring the device at 11:30.

Their TAP has expired.

What happens next?

They call the Helpdesk.

The Helpdesk needs to verify them again.

Another TAP is generated.

We’ve technically reduced the lifetime of the credential.

But we’ve also created another recovery event.

Another Helpdesk interaction.

Another opportunity for social engineering.

Security controls that routinely force users into exception processes aren’t necessarily improving security.

Duration Should Reflect the Scenario

I don’t think there should be a universal TAP lifetime.

Instead, the duration should reflect the workflow.

Controlled TL1 Registration

A TL1 administrator is sitting in front of their PAW.

Their dedicated FIDO2 security key is ready.

Their identity has been verified.

Generate the TAP.

Validate it.

Done.

That could justify an extremely short-lived, single-use TAP.

Remote Administrator Onboarding

The administrator may be working remotely.

Their device may still be completing enrolment.

They may need several authentication events.

A slightly longer multi-use TAP may be more appropriate.

Workforce Onboarding

A new starter may have an entire onboarding journey to complete.

The TAP may need to remain valid long enough for them to complete device setup and establish their permanent authentication methods.

That might mean several hours.

Potentially longer depending on the organisation’s onboarding process.

That doesn’t mean we should casually issue long-lived TAPs.

It means we should design the TAP lifetime around the real process, not an arbitrary security number.

Should TAP Be Valid Until the Permanent Method Is Registered?

Conceptually, I like this model.

Traditional onboarding often works like this:

Temporary credential → establish permanent credential

TAP should serve a similar purpose.

For a workforce user:

TAP → Register Passkey → Validate Passkey → TAP No Longer Required

For a privileged administrator:

Identity Verification → TAP → Register Dedicated FIDO2 Key → Validate FIDO2 → TAP No Longer Required

Microsoft Entra doesn’t dynamically expire the configured TAP simply because the user has successfully registered their permanent method.

So we still need to configure an appropriate validity period and operational process.

But architecturally, I think this is the right way to think about it.

The TAP exists until we’ve successfully established the authentication method we actually want the user to use.

Not indefinitely.

Not because we’ve decided that “eight hours is secure”.

It exists to support a defined process.

The TAP Is Only as Secure as Its Issuance

There’s another important problem.

We can build an incredibly strong authentication architecture and undermine the entire thing during onboarding.

Imagine a TL1 administrator who will eventually have:

Dedicated privileged identity
Dedicated FIDO2 security key
Privileged Access Workstation
PIM
Restrictive Conditional Access
High-assurance Authentication Strength

Excellent.

Then the Helpdesk receives a phone call:

“Hi, I’m the new administrator. Can you send me my TAP?”

And sends it.

We’ve just placed enormous trust in the weakest part of the process.

The strength of the credential we’re registering doesn’t matter if we haven’t established confidence in the person registering it.

Before issuing TAP, we need appropriate identity verification.

And the level of verification should once again reflect the Trust Level.

Microsoft’s passwordless deployment guidance also considers identity verification and credential bootstrap as part of the deployment journey.

For Microsoft’s current guidance, see Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID.

TAP and Trust Levels

Just like authentication methods, TAP processes shouldn’t necessarily be identical for every identity.

TL1 – Strategic Control

For TL1, I want a highly controlled process.

Potentially:

Strong identity verification
Dedicated administrative identity created through an approved process
Dedicated FIDO2 security key issued
TAP generated immediately before registration
Short validity period
Single-use where operationally practical
Registration performed from the appropriate administrative environment
FIDO2 authentication validated
Backup or recovery method established
TAP allowed to expire or removed when no longer required

For TL1, I’d favour control over convenience.

TL2 – Service Administration

For TL2, the process can potentially be slightly more flexible.

We still need strong identity verification.

If the administrator has their FIDO2 key ready and registration is controlled, single-use TAP may still be ideal.

But if the onboarding journey requires several authentication events, a short-lived multi-use TAP may provide a better operational experience.

Again, the objective isn’t maximum inconvenience.

It’s appropriate assurance.

TL3 – Operational Administration

For operational administrators, multi-use TAP can become particularly useful.

These users may be geographically distributed and onboarded through standard enterprise processes.

A TAP lasting long enough to complete device setup and passkey registration can provide a good balance between security and usability.

If the administrator is simply registering a Microsoft Authenticator passkey, however, single-use may still be perfectly appropriate.

The journey matters as much as the Trust Level.

TL4 – Workforce

For workforce onboarding, usability and scalability become particularly important.

If thousands of users are being onboarded, requiring Helpdesk intervention every time a single-use TAP is consumed during device enrolment isn’t a scalable architecture.

A carefully controlled multi-use TAP with an appropriate lifetime may provide a significantly better onboarding experience.

But again, if the user’s registration journey is simple enough to complete with a single-use TAP, there’s no reason not to use one.

This isn’t:

TL1 = Single-use

and

TL4 = Multi-use

It’s more nuanced than that.

Trust Level influences the assurance requirement.

The onboarding journey determines how we practically deliver it.

Recovery Changes the Context

TAP isn’t only useful when somebody joins the organisation.

It’s also one of the best recovery mechanisms available when a user loses access to their authentication method.

Imagine an administrator loses their phone.

Their Microsoft Authenticator passkey is gone with it.

Or they lose their FIDO2 security key.

We need a way to securely bootstrap a replacement credential.

TAP gives us that mechanism.

Microsoft documents the wider recovery architecture in Account recovery in Microsoft Entra ID.

But recovery can actually be more dangerous than initial onboarding.

Why?

Because attackers know recovery processes exist.

If I can’t compromise your FIDO2 security key, perhaps I don’t need to.

Maybe I can convince the Helpdesk that I’ve lost it.

That’s why recovery must involve appropriate identity verification before a TAP is issued.

For privileged identities in particular:

Recovery should never become an easier route around the Authentication Assurance we’ve deliberately designed.

Recovery Is Part of Authentication Assurance

This is something organisations frequently overlook.

They design extremely strong authentication.

Then create a weak recovery process.

But the real authentication strength of an identity is effectively constrained by the easiest route an attacker can use to obtain or replace its credentials.

If a TL1 administrator requires a dedicated FIDO2 security key but can obtain a replacement after answering a few Helpdesk questions, the FIDO2 key isn’t really the weakest part of the architecture.

The recovery process is.

Authentication Assurance therefore has to include:

Identity proofing
Bootstrap
Registration
Authentication
Recovery
Replacement
Revocation
Offboarding

The credential lifecycle matters just as much as the credential itself.

Remove What Was Lost

When TAP is being used for recovery, don’t forget the original credential.

If a user has lost their phone or security key, registering a replacement is only part of the process.

The missing authenticator should also be reviewed and, where appropriate, removed from the account.

Otherwise, we’ve successfully restored access while potentially leaving the lost credential registered.

Recovery should therefore look more like:

Verify Identity → Issue TAP → Register Replacement → Validate Replacement → Remove Lost Credential → Review Sessions

rather than simply:

Issue TAP → User Can Sign In Again

Consider a Backup Authentication Method

High assurance doesn’t have to mean a single point of failure.

In fact, for important identities, I’d generally prefer administrators to have an appropriately controlled backup authentication method.

For example, a TL1 administrator might have:

Primary dedicated FIDO2 security key
Secondary dedicated FIDO2 security key stored securely

That can significantly reduce the need to invoke emergency recovery processes.

The backup credential still needs the same lifecycle controls.

But having a properly managed backup is very different from falling back to a weaker authentication method when something goes wrong.

Protect Security Information Registration

TAP becomes particularly interesting when combined with Authentication Strengths and Conditional Access.

Rather than allowing TAP to become a general-purpose sign-in method, we can design policies around the registration of security information.

Microsoft documents how Authentication Strengths can be used with Conditional Access, including bootstrap and recovery scenarios.

For more detail, see How Conditional Access Authentication Strengths work.

Conceptually, we can separate:

Normal Access

Require the Authentication Strength appropriate to the user’s Trust Level.

Bootstrap and Recovery

Allow TAP specifically for establishing or recovering approved authentication methods.

This creates a much cleaner security boundary.

TAP exists because we need a bootstrap mechanism.

That doesn’t mean we need to treat it as a normal day-to-day authentication method.

Single-Use vs Multi-Use Isn’t a Security Score

I think this is one of the most important operational lessons with TAP.

It’s tempting to say:

Single-use = secure

Multi-use = less secure

Reality is more nuanced.

Single-use provides excellent protection against credential reuse.

And where the registration journey can be completed immediately — such as registering a Microsoft Authenticator passkey or a dedicated FIDO2 security key — I think it’s an excellent option.

But if the onboarding process requires multiple authentication events, single-use can create operational friction and repeated credential issuance.

Multi-use provides a smoother onboarding experience.

But because the credential remains usable during its lifetime, its duration, distribution and monitoring become more important.

The question therefore shouldn’t simply be:

Should we use single-use or multi-use TAP?

It should be:

What is the user trying to establish, how many authentication events will that journey realistically require, and what TAP configuration safely supports it?

That’s a much better architectural question.

This Is Where Organisations Need to Think Beyond the Policy

This is where I think organisations sometimes haven’t thought the entire authentication journey through.

It’s relatively easy to define the desired end state:

Administrators must use FIDO2.

Users must use passkeys.

Privileged access must require phishing-resistant authentication.

Those are good objectives.

But they’re only the destination.

You also need to design the journey that gets the identity there.

How is the user’s identity initially verified?

How do they receive their bootstrap credential?

How long is that credential valid?

Does the registration journey require one authentication event or several?

What happens if registration fails?

Who can issue another TAP?

How is the user verified during recovery?

How do we know the permanent credential was successfully registered?

When does the temporary credential stop being usable?

And what happens when that permanent credential is lost?

These aren’t simply Helpdesk implementation details.

They’re part of the Authentication Assurance architecture.

A beautifully designed Conditional Access policy doesn’t compensate for a poorly designed bootstrap process.

Likewise, requiring a dedicated FIDO2 security key for a Global Administrator doesn’t provide the assurance we think it does if obtaining or replacing that credential ultimately depends on a weak recovery process.

Authentication Assurance therefore needs to consider the entire credential lifecycle:

Identity Proofing → Bootstrap → Registration → Authentication → Recovery → Replacement → Revocation

Not just the authentication event in the middle.

My Approach to TAP

If I were designing a TAP strategy, my starting principles would be:

Use TAP as a bootstrap and recovery credential, not a normal authentication method.
Use single-use TAP where the registration journey supports it.
Use multi-use TAP where multiple authentication events are genuinely required.
Keep the lifetime as short as reasonably practical, not arbitrarily short.
Base the lifetime on the actual onboarding or recovery journey.
Apply stronger identity verification for higher Trust Levels.
Validate the permanent authentication method before considering onboarding complete.
Remove or revoke lost authentication methods during recovery.
Provide appropriately controlled backup credentials for high-assurance identities.
Monitor TAP issuance and use.
Don’t allow recovery to undermine the assurance of the primary authentication method.

Most importantly:

Design the journey first, then configure TAP to support it.

Don’t start with:

“TAPs will be single-use and valid for 60 minutes.”

and then force every user, device and onboarding scenario to fit around that decision.

Understand the journey.

Then choose the control.

TAP Is Temporary Trust

Ultimately, that’s how I think about Temporary Access Pass.

It’s temporary trust.

We’re allowing an identity to temporarily authenticate using a credential that exists specifically so they can establish something stronger.

That’s why I don’t personally think of TAP as MFA in the same way I think about a passkey or dedicated FIDO2 security key.

Microsoft Entra may technically allow TAP to satisfy authentication requirements.

Architecturally, I treat it differently.

It’s a temporary bootstrap credential.

A deliberately time-limited bridge between:

Identity Verification

and

High-Assurance Authentication

And the quality of that bridge matters.

Because the strongest FIDO2 security key in the world can’t compensate for a weak process used to issue it.

Perhaps more importantly:

The assurance of a credential starts before the credential exists.

If we haven’t thought about bootstrap, registration and recovery, we haven’t really designed Authentication Assurance.

We’ve only designed authentication.

What’s Next?

We’ve now established how an identity can securely bootstrap and recover its authentication methods.

That means we have most of the individual pieces.