Using an improved and simplified MFA enrollment Experience!

There are a lot of possibilities today to start the enrollment of Multi-Factor Authentication, whereby the most common scenario is for your end users that they go to or and follow the steps for the enrollment. This process does require the user to logon via a browser (on their laptop or mobile) and from there start the enrollment process. This whereby most users unfortunately end up by not using the Authenticator App option as their Multi-Factor Authentication method but instead choosing for SMS or Voice call as their preferred method (if enabled within the tenant).

This not only results in a worse user experience and is less secure, but also does not offer the user with the ability to use a Passwordless experience. So, what are than the options to promote the Authenticator App or improve the end user experience from an enrollment perspective? Let us first start answering the question around the promotion topic. For that you can use the brand-new Nudge feature for which I already wrote another blog which can be found here! If promoting the Authenticator App is not what you are looking for but simply want to provide instructions for your end users how they can easily enroll from the authenticator app itself (without the need of a browser) this blog is exactly what you are looking for!

Microsoft is doing a lot of work around the Authenticator App lately and one of the functionalities which is introduced is the option to enroll the Authenticator App directly from the Authenticator app. This is great functionality as the steps can all be executed directly from the Authenticator App itself, but even better if the user is enabled for a Passwordless setup the user is prompted automatically after the enrollment to enable the Passwordless phone sign-in as well. So besides providing the user with a simple enrollment experience it brings direct added value as well when looking at Passwordless!

Now to use this functionality there are three important things to keep in mind which are described below:

  • The user must be multi-factor enabled (SMS / Voice Call), otherwise the enrollment within the Authenticator App will be blocked (as it is insecure).
  • If the user is not (yet) enrolled for multi-factor authentication the user can use a Temporary Access Pass to execute the enrollment from the Authenticator App (counts as multi-factor authentication).
  • If the above requirements can or are not met you are tied to open a browser to start the enrollment for the Authenticator App, for which Passwordless must be manually enabled.

The flow chart below shows you the exact options of the above-mentioned points and should help you into driving the right adoption.

NOTE: For users which are already enrolled in your environment for Multi-Factor Authentication and have not enrolled the Authenticator App you can also use the Nudge functionality to prompt users for the enrollment. You can find more details about the Nudge functionality in this blog. Be aware that when using Nudge users aren’t prompted with the improved enrollment experience and won’t be prompted to enable the Passwordless phone sign-in option.

Now that we know the above let us have a look at the steps which you need to take from a technical perspective and how that looks from an end user perspective so you can drive the right adoption as well!

Step 1: Make the necessary configuration steps in Azure Active Directory

To make sure your users can use this new feature to enroll from the authenticator app itself without the need to scan a QR code, let’s make sure your Azure Active Directory is configured correctly. The first thing we need to check are the ‘old’ Multi Factor Authentication settings page. On this page, make sure that under the ‘Verification options’ the checkboxes for ‘Notification through mobile app’ & ‘Verification code from mobile app or hardware token’ are selected.

Once this is done let’s configure the ‘MicrosoftAuthenticator’ setting in Azure Active Directory. This can be found when going to the Azure-portal page, go to ‘Azure Active Directory’, click on ‘Security’ and hit ‘Authentication Methods’. Within this blade click on ‘Policies’ and select the ‘MicrosoftAuthenticator’ option.

In here make sure the setting Enable is set to ‘Yes’ and a test group is included, in my case ‘IdentityMan-Users’ (but preferably select ‘All Users’). When the group is selected (or you’ve put the setting to ‘All Users’). Hit the ‘three dots’ and click ‘Configure’.

In here make sure the ‘Authentication Mode’ setting is set to ‘Push’ (meaning Push notifications or TOTP) or ‘Any’ (meaning Push notifications, TOTP or Passwordless). This setting determines the option(s) which are available to your end users by using the authenticator App, whereby ‘Any‘ or ‘Push‘ are mandatory to have to use this functionality (in this example we add the ‘Passwordless‘ option a few steps later).

Click on ‘Done’ when the authentication mode has been configured.

If you in the previous setting you have chosen for the ‘Push’ setting, let’s add a separate group as well as that will improve the Passwordless experience enrollment as well (if you have chosen for ‘any’ you can ignore the next 4 steps). Therefore, again include a test group, in my case ‘Password-less Phone Sign-in Users’. When the group is selected, hit the ‘three dots’ and click ‘Configure’.

In here select ‘Passwordless’ as the ‘Authentication Mode’.

Click on ‘Done’ when the authentication mode has been configured.

Verify the settings and hit ‘Save’ when done.

Once we have configured the Authenticator App policy, we will configure the Temporary Access Pass policy in this example as well. A Temporary Access Pass is a time-limited passcode issued by an admin that satisfies strong authentication requirements and can be used to onboard other authentication methods, including Passwordless. A Temporary Access Pass also makes recovery easier when a user has lost or forgotten their strong authentication factor like a FIDO2 security key or Microsoft Authenticator app but needs to sign in to register new strong authentication methods.

The reasoning why we are using the Temporary Access Pass in this example is for users who didn’t registered (yet) for multi-factor authentication (i.e. SMS/Voice Call) can enroll directly as well within the Authenticator App. Therefore, within the ‘Policies’ settings in the Authentication Methods blade, select ‘Temporary Access Pass’.

In here set the Enable value to ‘Yes’, select ‘All users’ or include a specific group and hit ‘Edit’ to edit the settings.

Within the Temporary Access Pass settings, configure the:

  • Minimum lifetime – The minimum lifetime for which a Temporary Access Pass can be used after generation.
  • Maximum lifetime – The maximum lifetime for which a Temporary Access Pass can be used after generation.
  • Default lifetime – The default lifetime set when create a Temporary Access Pass for a user.
  • Length (characters) – The 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 for a one-time use concept as that fits my current need.

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

Verify the settings and hit ‘Save’ when done.

Now we have configured both the Authenticator App and Temporary Access Pass, add your user to the group(s) you have added to the Authenticator App Authentication Policy above. With this last step the configuration in Azure Active Directory has been finished and your users can now enroll the Authenticator App and (if configured) are eligible as well for phone sign-in! Therefore, proceed to Step 2 if you have not enrolled within Azure MFA yet and because of that need to use a Temporary Access Pass. If you already have enrolled for Azure MFA (i.e SMS/Voice Call) you can directly proceed to Step 3.

Step 2: Generate a Temporary Access Pass (if required)

As we have enabled the Temporary Access Pass feature earlier, 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).

Once ready hit ‘Add’.

Once added the ‘Temporary Access Pass password’ is shown.

Copy this value and proceed to Step 3 to test this new enrollment experience from the Authenticator App.

Step 3: Test the end user experience in the Authenticator App

Open the Authenticator App on your mobile device and hit the ‘+’ sign.

In the next step choose for ‘Work or school account’.

When the prompt opens hit ‘Sign in

Now enter your username and hit ‘Next’.

Enter your password or enter the Temporary Access Pass and now hit ‘Sign in’.

When you’ve used a password (single-factor) and didn’t used a Temporary Access Pass (TAP counts as multi-factor) you will be prompted for a multi-factor authentication challenge (like SMS in the example below). Now hit ‘Verify’ to continue.

NOTE: If this is your first multi-factor enrollment, one of these methods (multi-factor or TAP) must be used, otherwise the account will be added to the Authenticator App but still requires you to scan the QR code, which is described on the docs as well.

I have now enrolled for Multi-Factor Authentication from my phone with the Authenticator App! However, as I have enabled this user for a Passwordless experience as well, it is prompting the end user immediately to complete their enrollment for Passwordless phone sign-in as well! A superb functionality if you would ask me personally, therefore hit ‘Continue’.

NOTE: If you have already registered your device in another tenant the first check called ‘device registration’ will not get a green checkbox. Currently this functionality is only supported for one account within the Authenticator App, if this is the case just skip the following steps.

Once you have hit ‘Continue’ the user is prompted to register their device in Azure Active Directory. This does not mean we are going to manage the device is purely a device registration. Therefore hit ‘Register’.

Once done the user is enabled for Push Notification, TOTP and Passwordless Phone Sign-in functionality! Now hit ‘Finish’ to complete the last step.

Looking at the details of the account within the Authenticator App we can see that we do have enabled Passwordless, we do have a TOTP and push enabled as well.

When this is done and the users goes to, where the user is now prompted with a Passwordless experience (with number matching).

This is great, but what if my user did not enroll for passwordless? In that case the user needs to go to My Sign-Ins and change the ‘Default sign-in method’ by hitting ‘Change’.

In here select the option ‘Microsoft Authenticator – Notification’ and hit ‘Confirm’.

Step 4: Monitor as an administrator the user activity of enrollments

Now to monitor the active enrollments of end users from an administrator point of view, go to the ‘Activity’ within the ‘Authentication Methods’ blade in Azure Active Directory.

Within the ‘Activity monitoring’ we can see on the left side what your users have registered as an authentication method within the Azure Active Directory.

On the right side within the ‘Activity monitoring’ we can see what users have used the lately as a registration option within you Azure Active Directory.

You can even drill down into the logs, for a specific authentication method, which users have registered as new methods, an example for the Microsoft Passwordless phone sign-in is therefore shown below.

By using the enrollment feature directly from the Microsoft Authenticator App you can drive adoption in a simple and secure experience for your end users as you have seen. Besides, it can provide the user with a seamless enrollment within the Passwordless phone-sign feature as well, meaning that no extra adoption is required for the latter. It can all be included into one simple improved experience for your end users, so do not wait any longer and start updating / improving your instructions.

I hope you again enjoyed reading my blog about this feature! Stay tuned for some more new great features of the authenticator app soon. This whereby I will explain more bits and bytes about how you can use the GPS Coordinates provided via the Authenticator App to either restrict or provide access for the end user.

Blogs in this series:

2 thoughts on “Using an improved and simplified MFA enrollment Experience!

  1. Tom says:

    Great write up and thanks, it’s a very eloquent solution you’ve provided.

    Just out of curiosity have you encountered this?
    We have a CA policy that blocks “User actions > Register Security Information” from untrusted locations (it’s unticked for “Register or Join Devices”).

    If I attempt to register the device (iOS) for an MFA enabled user through the Authenticator app (as part of the passwordless enablement process) I’m blocked if I’m not on a trusted location. From what I can see we have no other CA policies blocking this it’s purely the “Register Security Information block policy” from above.

    Does the register device through the Authenticator app access the combined registration portal prior to redirecting to register the device?


    1. Pim Jacobs says:

      Hi Tom,

      Interesting point you bring up here. Since TAP has been released there has also been an update on the docs. What I would recommend you to try is to change that policy not to block but to grant access and say require MFA. That will allow you to put in your TAP as TAP counts as strong factor authentication.

      I’ve not seen this behavior you’re mentioning above, but happy to dig in further if the above solution doesn’t work! So let me know the outcome :-).


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s