Turn on MFA! …but how?

9 min readSep 6, 2020

In the last years I was part of some Azure MFA rollouts of different sizes and made some experiences in this topic and want to share this.

Update 08–2021: Solution for Rollout Challenge “I need to ensure that at the rollout the users are only asked to register the Authenticator App and not the fallback option phone number.”

Rollout reasons

If you read this it seems like you already decided to use Azure MFA. But if someone asks here is your short answer why this is the best idea of the year:

Azure MFA is easy!

Can be connected to AAD as well as to ADFS
Supports well known scenarios like (SAML, RADIUS)
Is a SaaS-service with no effort of the tenant-owner needed

Azure MFA is secure!

Reduces the risks for stolen accounts by 99.9%

Azure MFA is comfortable!

Microsoft Authenticator App with Companion-App!
Can be used instead of a password
Offers a wide viarity of authentication methods

Rollout occassions

Although the reason (short: Massive increase in account protection) for the use of Azure MFA is relatively obvious, in my experience many need an occasion for the rollout. Therefore here is a list of events that can convince a project manager to approach the Azure MFA rollout very early and comprehensively.

Policy occasions:

Access to certain services
Administrative accesses
Integration of guest users
Conditions for access to published systems
Preparation / condition for the use of other services

Device occasions:

Handover of devices that are managed with Intune
Enabling of device registrations
Precondition for device authentication in Conditional Access
For many services as an alternative to company owned devices
Fallback for Conditional Access rules with device authentication

Feature occasions:

Self Service Password Reset
Rollout of Azure AD Identity Protection
Usage of Privileged Identity Management
Rollout of Windows Hello for Business
Rollout of Azure Information Protection

Classic MFA vs. Conditional Access

Before we start thinking about how to best organize our rollout, one thing needs to be clarified. Azure MFA has changed a bit over time and there are still some environments where Classic MFA has been used before.

Classic MFA means a user based MFA which is always and independent of the type of access.
Better: MFA as a grant action for Conditional Access

Rollout methods:

To start a MFA rollout we have some options that we can and should combine:

we could ask our users per mail
-> this is always a good first step
we could do a per user enforcement (for the next login at AAD) in the MFA portal
-> this is classic MFA and you shouldn’t use it!
we could setup Conditional Access policies to enforce MFA as a grant action.
-> often this would end in an uncontrolled gradual rollout. So in some cases it makes sense to implement a temporary ruleset including a lot of MFA ;-)
we could enable Combined Registration end setup Self-Service Password Reset
-> my favorite! Combining the useful with the pleasant.
we could setup an MFA Registration Policy in AAD IP (requires AAD P2)
-> this option allows the users to skip the registration for up to 14 days
-> and it enables using only Authenticator App for MFA and SSPR (see below)

MFA configuration

After the configuration of Azure MFA in some companies I made the following experiences:

Any configuration is better than no configuration
The used verification options are highly dependent on the environment
My ideal configuration is: use only the Authenticator App (push is preferred)
There is an awesome whitepaper on how to archive NISTs Authenticator Assurance Levels (AALs) -> aka.ms/Microsoft-NIST
The option Authenticator App is including OATH Token
Don’t enable app passwords, trusted IPs and caching (unless there is really good reason)
Turn on Fraud Alert and configure Notifications
Enable the combined registration preview. Just the fact that the Authenticator App is then the default greatly increases the rollout success in my experience…
Keep in mind: MFA and SSPR are different things with partly different options

Rollout challenges

In my experience, unfortunately, a lot of energy is often spent on the discussion of special and exceptional cases instead of planning a proper rollout. Maybe this “problem orientation” is a German topic… okay let’s discuss the most popular ones:

Not all users have a company smartphone and are not willing to install software (the Authenticator app) on their private one!

My best advice for this is to buy some OATH token and hand them over to the few affected people. The best would be to buy token also supporting FIDO2 to reach the level after MFA later.

Another possible solution is to use the (less secure) call to phone option if you want to save the money. But be careful: The verification options can only be set globally for all.

We have special stuff like Service Accounts, Surface Hubs or Teams equipment which are not able to perform MFA!

We need to find this accounts, create a group for them, exclude them from the rollout and define special Conditional Access policies for them. How to exclude them depends on your chosen rollout method but is possible with all methods.

We have this clever Conditional Access policy configured which is restricting the access to the security info page to the trusted locations!

Okay, this one is tricky. At first you need to choose a rollout method that is triggered also from trusted locations. This is given at all methods out-of-the-box except with Conditional Access. If you want to use Conditional Access as trigger for the rollout you need to ensure that the first match is from a trusted location.

Independent from the rollout there is another problem with this configuration. If you’re using Self-Service Password Reset (you should!) your user will have to review their Security Info regularly and if this flow is not triggered from a trusted location they will be locked out until they are next time at a trusted location. To avoid this effect you should extend this policy to trusted devices (hybrid joined, compliant).

I need to ensure that at the rollout the users are only asked to register the Authenticator App and not the fallback option phone number.

As I described above, there are several ways to trigger the setup for the user. The two most common are the setup via SSPR or the MFA Registration Policy in Identity Protection. By activating Combined Registration, the user directly sets up both services and it should lead to the same result. In practice, however, a clear difference has become apparent:

Only when I use the MFA Registration Policy is the setup dialogue completed after the Authenticator App is set up and MFA and SSPR can be used. When using the mechanism from SSPR, another factor must always be registered.

In concrete terms, we need the following configuration:

Disabling registration requirement on password reset

Preparation

The first phase of the rollout should be a good preparation. At this point the technology is up and running and at least the administrators are already using it. In my experience, it is mainly necessary to deal with the following two topics.

User Communication

In my experience, good user communication pays off strongly and helps with the rollout.

A good manual prevents calls to the help desk
If there is a corporate communications or marketing department, it should definitely be involved.
Microsoft has good material (emails, posters, etc.) for this topic for download. However, you should make sure to hit the right tone. I once had a case where a somewhat too lurid mail was suspected by the users as a phishing attempt.
It is always a good idea for the user to link to new features that are valuable to him. In my experience, this greatly increases the willingness of the user.

Help desk enabling

Depending on the size of the company, this is also a topic of varying size. Regardless of this, however, it is essential for a rollout to offer help to the users. Depending on the IT affinity of your users you have to expect a help desk contact of 5–10% of the users. In order to win the help desk colleagues over to the topic, I have had good experience in linking the topic with SSPR, as this feature often brings them considerable relief.

Often the Azure MFA rollout for help desk teams is the first contact with the Azure Active Directory and Microsoft 365. This means it is necessary

extend your administrative concept with these groups — or create the concept ;-)
to make instructional events including documentation and demonstration for the colleagues

For the administrative accesses I have used the following roles so far:

Global Reader or Directory Reader + Reports Reader
Authentication Administrator
in no case the Privileged Authentication Administrator!

You should cover the following typical tasks in your instructions for the help desk:

Setup support
MFA reset
Support at accessing apps protected with MFA
Handling of MyProfile / MySignins

In addition, it is a good idea to create categories for this topic in your ticket system — otherwise it will be difficult to measure how much effort your support needs for this topic. Especially if you have a big rollout in front of you it is good to know what is coming.

Rollout planning

After the preparation comes the rollout. A rollout should always have a goal, a plan and a status.

As a goal I would always define a quota and a date. Ideal would be something like: Until 31.12. either Azure MFA was successfully set up for all accounts or an exception was documented.

It is important to understand how an Azure MFA rollout works when planning and setting goals. Since user interaction is always required, it is very likely that there will be stragglers. It might even be necessary to support some users very intensively during the setup process, because they don’t even encounter the setup dialog in their everyday life.

Depending on the size of the company, it makes sense to proceed in several waves for the rollout. It is to be expected that these waves will overlap slightly as you can only define the start date due to the user interaction and the stragglers.

For the first wave, I always used IT and especially help desk staff to ensure that they were able to provide help. After that it can be useful to proceed according to organizational or geographical criteria. A selection based on dependent services such as a device rollout is also a reasonable approach.

What is my rollout status?

In addition to the above mentioned categories in the ticket system it is important to see the status of a rollout based on the registrations made. For this purpose, the Authentication methods activity report integrated in AAD can be used in small environments. For larger environments I am a big fan of using Azure Monitor.

As an example here is a dashboard I built for my last rollout:

In this dashboard there are also device registrations but for a MFA rollout the main indicators are

Registrations per Day
Used Methods
MFA-Errors (per Method)

If rollout groups are defined, it is also possible and useful to visualize this per group.

I am just a dwarf standing on the shoulders of giants. Read this to learn more about this topic.