Today there are a lot of options to work passwordless, you can work passwordless with the Phone Sign-in option from the Authenticator App, use Windows Hello for Business (hybrid) from Windows 10 & 11 or use FIDO2 Security Keys for web-based or Windows or mobile sign-ins. But what about new joiners which we don’t want to provide a password, because working passwordless starts with simply not providing one 😉. Besides new joiners we have existing users as well for which in some cases they need to recover their passwordless methods like the Authenticator App or FIDO2 security keys, again preferably not using a password of course!

For this Microsoft has invented the Temporary Access Pass (TAP) which is a time-limited password issued by an administrator which is satisfying strong authentication (like when using the Microsoft Authenticator App, Windows Hello for Business or FIDO2 Security keys). The TAP therefore allows the user to either bootstrap their passwordless method(s) or enables the user to recover their lost or forgotten passwordless / MFA methods

In this blog we are going to have a look at how to enable the Temporary Access Pass in your environment and once enabled we will have a look at the following use cases:

• Bootstrapping via https://aka.ms/mysecurityinfo.
• Bootstrapping via the Authenticator App.
• Bootstrapping via Windows.
• Bootstrapping via Mobile Devices (Android Zero Touch & Apple Business Manager).
• Using the Temporary Access Pass for a single day (not recommended though 🙂 ).

But first, let’s have a look at some of the limitations of a Temporary Access Pass:

• When using a one-time Temporary Access Pass the user must complete the registration of the Authenticator App or FIDO2 Security key within 10 minutes of the sign-in with the one-time Temporary Access Pass (if you’re not using a one-time TAP this limitation doesn’t apply).
• Users in scope for the Self-Service Password Reset (SSPR) registration policy will be required directly after the sign-in with a Temporary Access Pass to register the authentication methods, this doesn’t support the registration of FIDO2 Security Keys and Phone Sign-in today. If the SSPR policy is set to not require registration this doesn’t apply.
• A Temporary Access Pass can’t be used with a Network Policy Server Extension or the Active Directory Federation Services Adapter.
• After a Temporary Access Pass is added to an account or when it Is expired it can take a few minutes for changes to replicate, users may still see a prompt for a Temporary Access Pass during this time while it is already expired or removed from the user account.

Now we now the limitations let’s have a look at how to enable the Temporary Access Pass functionality in your environment before looking at the use cases in detail.

---

Step 1 – Enable the Temporary Access Pass feature in your tenant.

To enable the Temporary Access Pass feature in your tenant we need to make sure it’s enabled as an Authentication Method within your tenant. If you didn’t execute these steps, you won’t be allowed to issue Temporary Access Passes for your end users. Therefore, within the ‘Policies’ settings in the Authentication Methods blade, select ‘Temporary Access Pass’.

In the ‘Basics tab’set the Enable value to ‘Yes’ and select ‘All users’ or include a specific group.

In the ‘Configure tab’ we can edit the settings of the Temporary Access Passes which will be issued, therefore hit ‘Edit’.

NOTE: The below settings can be treated as a recommended example for regular use, however they can differ case by case, e.g. if you’re planning to use TAP within Identity Lifecycle Workflows the lifetimes could be required to be extended.

Within the Temporary Access Pass settings, we can configure the:

• Minimum lifetime – The minimum lifetime for which a Temporary Access Pass can be generated.
• Maximum lifetime – The maximum lifetime for which a Temporary Access Pass can be generated.
• Default lifetime – The default lifetime set when an admin creates a Temporary Access Pass for a user.
• Length (characters) – The character length of a newly created Temporary Access Pass.
• Require one-time use – When set to ‘Yes’ the Temporary Access Pass can only be used once in the valid lifetime, when set to ‘No’ the Temporary Access Pass can be used as long as the lifetime is valid.

In my example I’ve used the settings below, whereby I specifically have chosen to allow a one-time use as this can be disabled when generating Temporary Access Passes as well.

NOTE: When using an Android Zero-Touch deployments and Apple Business Manager deployments to bootstrap Mobile Devices and the Authenticator App or Windows Autopilot deployments with WHfB enrollment in one go you can’t use a one-time Temporary Access Pass as this process requires you to authenticate more than once.

Once you have configured the settings, hit ‘Update’.

Verify the settings and hit ‘Save’ when done.

Now we have configured both the Temporary Access Pass Authentication method, we can now generate Temporary Access Passes for end users which we look at in the next step.

---

Step 2 – Generate a Temporary Access Pass

As we have enabled the Temporary Access Pass feature, we can now generate Temporary Access Passes beneath the user accounts in Azure Active Directory. As I’ve set this in my configuration to ‘All Users’ all users are eligible for this feature, if you have scoped this down to groups, make sure the user for which you are generating the Temporary Access Pass is included within that specific group.

Now to generate a Temporary Access Pass, go to the user account of the user for which you want to generate one, hit the ‘Authentication Methods’ tab and hit ‘+ Add authentication method’

In here select as method ‘Temporary Access Pass’, configure the duration / lifetime (and eventually the delayed start time) and define if it’s a one-time use Temporary Access Pass or if the Temporary Access Pass can be used more than once within the allowed activation time.

As explained earlier the latter is especially helpful when you have Android Zero-Touch deployments, Apple Business Manager deployments to bootstrap these Mobile Devices and the Authenticator App in one go. Or Windows Autopilot deployments with WHfB enrollments, where you want to bootstrap the device and WHfB enrollment in one go.

Once ready hit ‘Add’.

Once added the ‘Temporary Access Pass password’ is shown, and only shown once!

Now we got a Temporary Access Pass, let’s have a look at the different use-cases for it in Step 3.

---

Step 3 – Temporary Access Pass Use-Cases

Option 1: Bootstrapping via https://aka.ms/mysecurityinfo.

In the past Microsoft and other system integrators advised to ‘Block’ the security registration information via Conditional Access unless you were working from an office location or other conditions. With the Temporary Access Pass this has changed, this as a Temporary Access Pass counts as Multi-Factor Authentication as well.

For that the Conditional Access Policy below is an example which can be created to Enroll or Re-enroll Multi-Factor Authentication in a secure manner.

With the above policy enabled and trying to enroll or re-enroll Multi-Factor Authentication with my username and password will result in the following ‘block’ message:

Now once we assign a Temporary Access Pass to the user, the enrollment or re-enrollment for Multi-Factor Authentication can be executed by the user with the Temporary Access Pass.

At this point the user can register a new Authenticator App, Security Key or eventually Mobile Phone number(s).

Summarizing option 1:

• The Temporary Access Pass can be used to enroll Multi-Factor Auth or Passwordless via https://aka.ms/mysecurityinfo.
• The Temporary Access Pass can be used as a one-time assignment and can therefore only be used once.
• Users have 10 minutes to complete the enrollment process after they first used their Temporary Access Pass (if one-time usage is enabled).
• This scenario is helpful if users do have access to a web-browser and already have a working Android or iOS device.
• With the correct Conditional Access Policy applied, end users are required to have ‘strong authentication’ to enroll for Passwordless or Multi-Factor Authentication.

---

Option 2: Bootstrapping via the Authenticator App.

The same process applies of course to Bootstrapping directly from the Authenticator App. For that you can open your Authenticator App, add an account, choose for ‘Work or School’ and hit ‘Sign in’.

Again, with the Conditional Access Policy applied, as described in Option 1, we can see that if I don’t have any MFA methods or Temporary Access Pass assigned to the account, I’m not able to enroll or re-enroll for Multi-Factor Authentication.

Once the Temporary Access Pass is assigned however, I can use that directly from the Authenticator App to connect my account!

And the beauty of it, it’s not only a Multi-Factor Authentication enrollment, during this enrollment (if the account is eligible) Passwordless Phone Sign-in is turned on automatically. More of this and the different options to enroll the Authenticator App can be found in this blog.

Summarizing option 2:

• The Temporary Access Pass can be used to enroll directly via the Microsoft Authenticator App.
• The Temporary Access Pass can be used as a one-time assignment and can therefore only be used once.
• Users have 10 minutes to complete the enrollment process after they first used their Temporary Access Pass (if one-time usage is enabled).
• This scenario is helpful if users don’t have access to a web-browser or want to enroll Passwordless Phone Sign-in directly and already have a working Android or iOS device.
• With the correct Conditional Access Policy applied, end users are required to have ‘strong authentication’ to enroll for Passwordless or Multi-Factor Authentication.

---

Option 3: Bootstrapping via Windows 10 / 11.

When you’re joining a company who are using Azure AD Joined devices managed by Intune and you are using your existing Mobile device and aren’t provided with a password you can use the Temporary Access Pass. This is shown below, after the sign-in the user is guided through the OOBE deployment process and can go to My Security Info to setup the Authenticator App.

Summarizing option 3:

• The Temporary Access Pass can be used to enroll Windows devices for new joiners.
• Users are using a phone which does contain the Authenticator App already.
• Users can enroll the Authenticator App after the Windows deployment completes by using their Temporary Access Pass.
• Depending on the time it takes to deploy the Windows device a one-time access pass could work but only when this process completes in 10 minutes including Windows Hello for Business enrollment. In most cases you therefore can’t use one-time Temporary Access Passes.

---

Option 4: Bootstrapping via Mobile Devices (Android Zero Touch & Apple Business Manager).

When you’re using Android Zero Touch for your users and want to use the Temporary Access Pass it’s important that the Temporary Access Pass can be used more than once.

This as during the Zero-Touch process end users are required to enroll their device in Intune first, which brings them to the sign-in page below during the Android Zero Touch process.

This page of course supports Temporary Access Pass usage, however once the Zero-Touch process finished you want to enroll the Authenticator App for which you need the Temporary Access Pass as well. Hence the reason why you can’t use a one-time Temporary Access Pass in this scenario (unless you still got your ‘old’ mobile device with the Authenticator App enrolled, a FIDO2 security key configured and a working Windows device which you can use to access the My Security Info portal).

When you enroll via Apple Business Manager you’ve got the same experience when using ‘Enroll with User Affinity’ option, once out you’ve finished the out-of-the-box experience you first need to enroll the Intune Company Portal to get all the applications installed (including the Authenticator App). For that you first need to sign-in to the Intune Company Portal with a Temporary Access Pass before you can start enrolling the Authenticator App with your Temporary Access Pass. This is again the reason why you can’t use a one-time Temporary Access Pass in this scenario (unless (as explained earlier) you still got your ‘old’ mobile device with MFA enrolled, a FIDO2 security key configured and a working Windows device which you can use to access the My Security Info portal).

To summarize Option 4:

• This scenario (in most cases) does apply to new joiners who do get a mobile devices and laptop whereby they first need to enroll their phone to get the Authenticator App to enroll their Azure AD Joined device.
• The Temporary Access Pass can be used to enroll Android Zero-Touch or Apple Business Manager device.
• Once the mobile phone or tablet is enrolled end users can use the same Temporary Access Pass for the Authenticator App Enrollment (as explained in Option 2).
• The Temporary Access Pass (in most cases) can’t be a one-time Temporary Access Pass as end users in this scenario are (as described in this example) new joiners and therefore need to enroll their phones first before they can enroll their Azure AD Joined Windows 10 or 11 device.

---

Option 5: Using the Temporary Access Pass for a single day (not recommended though 😉 ).

The last option is using a Temporary Access Pas for a single day. This because one of your end users have i.e. lost their Mobile Phone and/or FIDO2 Security Key and isn’t able to perform his daily job. These users, in most cases, won’t use a device which does support Windows Hello for Business as Windows Hello for Business counts for Multi-Factor Authentication (aka Strong Authentication) as well. For that they do need another option to perform Multi-Factor or Passwordless authentication, which indeed could be a Temporary Access Pass which is usable for a longer time (i.e 8 or 9 hours).

Now with this Temporary Access Pass, as described above, people can do their daily job for 9 hours, and when they return back home, they are able to perform their regular Passwordless or Multi-Factor Authentication as they are back to their Mobile Device or Security Key.

My personal opinion, in this example, is however to provide the user with a clean (temporary) FIDO2 Security Key. Temporary Access Passes, just like with passwords, are generating post-its on desks, which is what we are trying to avoid for years already. The Temporary Access Pass in this scenario is helpful for these users to add a new FIDO2 Security Key to their account and once added the Temporary Access Pass is destroyed and people are required to do their daily job with their (temporary) FIDO2 Security Key.

To summarize Option 5:

• This scenario can be used for people who have lost or forgotten their Mobile Phone and / or FIDO2 Security Key.
• In this scenario I would rather recommend you assigning a Temporary Access Pass to an end user and let them enroll a (temporary) FIDO2 Security Key to their account.

---

Step 4: TAP Reporting and Sign-in views

Now we have walked through some use-case examples, let’s have a look at the sign-in logs which are available. When looking at a user which is using their Temporary Access Pass to sign-in, we can see in the Sign-in Logs of the user and grab one of their sign-ins.

When we open one, we can see that the Authentication Requirement is ‘Multifactor Authentication’. Meaning the user was required to perform strong authentication, either via the Authenticator App, Voice Calls, Windows Hello for Business, FIDO2 Security keys or another second factor method.

When we from here go to the ‘Authentication Details’ tab, we can see that the user has signed in with their Temporary Access Pass and with that method Strong Factor Authentication a.k.a. Multifactor Authentication has been executed.

With this we can see the Temporary Access Pass has been used, and more important you can even check the ID of the Temporary Access Pass which has been issued to the end user.

Now as an IT Admin you perhaps want to see all the Temporary Access Passes in your environment, this can easily be checked by running the following PowerShell Script:

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes "User.Read.All","UserAuthenticationMethod.Read.All"

$users = Get-MgUser -All

foreach ($user in $users) {
    Get-MgUserAuthenticationTemporaryAccessPassMethod -UserId $user.id
}

The output of the script is shown below, where we again can see the ID of the Temporary Access Pass and that the ‘MethodUsabilityReason’ is set to ‘EnabledByPolicy’ which means the Temporary Access Pass can be used by the end user from the ‘StartDateTime’. If the Temporary Access Pass was expired the ‘MethodUsabilityReason’ would be set to ‘Expired’.

Important to know is that expired Temporary Access Passes aren’t shown within the Security Info to the end user, only active Temporary Access Passes are shown to a user within the Security Info and if required users are also able to delete them from their account.

At last, if you want to check the total amount of Sign-ins within your tenant related to the Temporary Access Pass you can go to ‘Azure Active Directory’, click on ‘Security’, hit ‘Authentication Methods’ and select ‘Activity’. On the top hit ‘Usage’ and as you can see on the right side of the screen it states ‘Sign-ins by Authentication Method’. In here you can see that a Temporary Access Pass has been used once in the past 7 days in my tenant.

---

Conclusion

The Temporary Access Pass is a great solution to onboard your users passwordless or to let the users bootstrap Multi-Factor Authentication for their account. Using a Temporary Access Pass as a solution to let users do their day-to-day job isn’t something I would recommend even not if it’s a single day as that will result in post-its on desks. For that scenario I would recommend you having some spare (temporary) FIDO2 Security Keys (as described in this blog) available to provide to end users and let them onboard those with a (one-time) Temporary Access Pass.

At last, please do provide Temporary Access Passes in a safe manner, things you can consider are sending them over via SMS / WhatsApp (without any other details of course).

I hope you enjoined reading this blog and are now ready to bootstrap your passwordless journey with the use of a Temporary Access Pass. Stay tuned for some more passwordless blogs in the future, this is for sure not the last one :-).

Other related password-less blogs:

• Introduction to a password-less era
• Password-less 1 of 5: Going password-less with phone sign-in
• Password-less 2 of 5: Going password-less with Windows Hello for Business
• Password-less 3 of 5: Going password-less with Windows Hello for Business Hybrid
• Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 1
• Password-less 4 of 5: Going password-less with FIDO2 Security Keys Part 2
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 1
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 2
• Password-less 5 of 5: Expanding password-less to Azure AD Applications Part 3
• Password-less continued: Upgrading your password-less experience with Windows Hello for Business Hybrid cloud-trust
• Password-less continued: Using the Passwordless Phone Sign-in experience for multiple accounts on iOS!
• Password-less continued: Using a Temporary Access Pass for Bootstrapping your Passwordless Journey