TODO: Move from per-user MFA to Conditional Access

Azure Multi-factor Authentication

One of the remnants of the PhoneFactor infrastructure is an old page that is linked in the Azure Portal. It allows for enforcing multi-factor authentication on a per-user basis. It should not be used for several reasons. Here’s why.


Ways to require multi-factor authentication in Azure AD

In Azure Active Directory, there are three ways to require multi-factor authentication:

  1. Through a Conditional Access Policy;
  2. Through Security Defaults, when the Azure AD account has a privileged role or is an Azure service owner. or;
  3. Through enabling an Azure AD user object with multi-factor authentication.

Conditional Access

Conditional Access policies are the preferred way to require multi-factor authentication and/or other apply other access restrictions, like requiring a compliant device or require a certain location (based on egress IP address).

It is a flexible and straightforward means to break free from the old actor-action-resource model in Active Directory, but requires Azure AD Premium licenses.

People who are in scope of a Conditional Access policy will be prompted for one-time multi-factor authentication registration when they first sign in. However, requiring people to perform registration is prohibited to people with Azure AD Premium P2 licenses assigned.

Security defaults

For organizations that run Azure AD tenants without Azure AD Premium licenses, multi-factor authentication can be enforced through the Security Defaults feature.

The Security Defaults are non-configurable, but require multi-factor authentication registration at first sign-in and require multi-factor authentication for Azure AD user objects with privileged roles like the Global Administrator, SharePoint Administrator and Exchange administrator roles.

Security Defaults may prompt people in the organization for multi-factor authentication, when the user is a high risk user. As this can be perceived as erratic behavior from the platform, these people might call the service desk, which is exactly what you want.

Per user multi-factor authentication

The third way is the original way of enforcing multi-factor authentication in Azure AD. On a per-user basis, multi-factor authentication can be enabled and then enforced for specific users. No matter how the account is used to sign in, or what application, system or service is signed into, multi-factor authentication is required.


What’s wrong with per-user multi-factor authentication?

There are three big problems with per-user multi-factor authentication:

No delegation

The page to configure these settings has never been migrated to the Azure Portal.
This leads to a disparate admin experience and confusion. Also, because the page is not a part of the Azure Portal, (custom) roles can’t be used to delegate access. Its access requires Global Administrator privileges.

Conditional Access Inaccuracy

Second, when you enable per-user multi-factor authentication, a Conditional Access administrator will be seeking everywhere as to why a user always needs to perform multi-factor authentication. Conditional Access does not know of the requirement. The sign-in logs do not mention the per-user requirement. People with the Conditional Access administrator role do not have access to the page, as its access is limited to people with the Global Administrator role.

App Passwords

And then there are the app passwords. App Passwords are only available to users with per-user multi-factor authentication configured. Microsoft offers app passwords to people who need to meet multi-factor authentication on legacy platforms and in legacy applications. However, visibility of the usage of app passwords is next to none, making them hard to eradicate once deployed.

After the per-user multi-factor authentication requirement is lifted, people will not be able to create new App passwords or read the values of any existing App passwords. Eventually, they will have to use multi-factor authentication with their next hardware refresh, unless they’ve securely stored the value of their App password(s). It’s something.


Disabling per-user multi-factor authentication and switching to a Conditional Access policy

Disabling per-user multi-factor authentication is the way to go. The best way to disable per-user multi-factor authentication is to remove the enforcement on the user objects in the PhoneFactor portal and build a replacing Conditional Access policy targeting the group of users that was previously enforced.

Perform these steps:

  • Start a browser and navigate to the Azure AD Portal.
  • Sign in with an account with Global Administrator privileges.
    Perform multi-factor authentication when prompted.
  • In the left navigation menu, click Azure Active Directory.
  • In Azure AD’s navigation menu, click Security.
  • In the Security navigation menu, click on MFA under Manage.
  • Follow the Additional cloud-based MFA settings link in the main pane.
    A new tab or browser window opens.
  • Near the top of the page click on Users. This word represents a different ‘tab’ in the management experience of the cloud-based MFA service.
  • In the field to the left of the bulk update button, select Enforced from the drop-down list of MFA statuses for Azure AD user objects.
  • Write down the accounts.
  • Now, in the field to the left of the bulk update button, select Enabled from the drop-down list of MFA statuses for Azure AD user objects.
  • Write down these accounts, too.
  • Select the option box to the left of DISPLAY NAME at the top of the list of user objects to select of filtered objects with the Enabled status.
  • In the quick steps area to the right of the list, follow the link Disable.
  • In the Disable multi-factor authentication modal screen, click the yes button.
  • Now, in the field to the left of the bulk update button, select Enforced from the drop-down list of MFA statuses for Azure AD user objects.
  • Follow steps 9 through 11 to disable the per-user multi-factor authentication requirement for these user objects, too.
  • Close the browser tab or browser window and return back to the Azure AD Portal.
  • In the Azure Portal tab or window, click Azure Active Directory in the left navigation menu and then click Groups in Azure AD’s navigation menu.
  • In the Groups | All groups main pane, click the + New group link to create a new group in Azure AD.
  • Leave the Group type as Security.
  • Enter a name for the group in the Group name field, following your organization’s naming policy for groups. Something like People with MFA Required might cover it. Optionally, enter a Group description.
  • Leave the Membership type to Assigned and click the No members selected link.
    The Add members blade appears.
  • Search for the user objects on the list you created in steps 9 and 11. Add them to the newly created group by selecting them.
  • When you’ve selected all user objects, click the Select button at the bottom of the Add members blade.
  • In the New Group pane, click the Create button at the bottom of the pane.
  • Now, in the left navigation menu, click on Azure Active Directory.
  • In Azure AD’s navigation menu, click on Security.
  • Click on Conditional Access in the Security Menu.
  • In the Conditional Access | Policies main pane, click the + New policy link in the top action bar.
    The New pane appears.
  • In the Name field, enter a name for the Conditional Access policy following your organization’s naming policy for policies.
  • Under assignments, click on the 0 users and groups selected status for Users and groups.
  • Select the Select users and groups option, then select the Users and groups option. In the Select blade, search for the group you’ve created in steps 19 through 25. Select it. Then, click the Select button to save your group selection.
  • Under assignments, click on the No cloud apps or actions selected link.
  • Select the All cloud apps option.
  • Then, under Access Controls, under Grant, click the 0 controls selected link.
    The Grant blade opens
  • On the Grant blade, select the Require multi-factor authentication option.
  • Click Select at the bottom of the blade to save the control.
  • At the bottom of the New pane, under Enable policy, select On.
  • Click the Create button.
    You will be linked back to the Conditional Access | Policies pane
  • In the right top corner of the Azure AD Portal, click on the accounts name or profile picture and click on Sign out from the context menu.
  • Close the browser.



Please switch from per-user multi-factor authentication to Conditional Access to allow straightforward management of MFA settings, allow delegation and, eventually, get rid of App passwords.

13 Responses to TODO: Move from per-user MFA to Conditional Access


    Hi, would it make maybe more sense to put in the CA Rule the RBAC (Admin)Roles instead of selected users or groups?

    • Yes, it would, if the persons whom you want to require multi-factor authentication from have roles assigned.
      Especially, since Conditional Access for Directory roles is now out of preview.

      However, you might want to require multi-factor authentication from other people to access other functionality in the organization, too.


    Hello Sander, ty for the fast response. Yes we consider a combined CA Policy what get all admin roles and some special Users in a group.


    • That'll work.

      The added benefit to including role members is that changes to the roles are automatically reflected into Conditional Access policies applying.


    Hello Sander,
    After this migration, does the user have to re-register MFA ? phone app settings etc?
    What's the impact here?



    Hi Sander, Thanks for your response and help! I'm going to migrate asap!


    Thank you for this detailed write up. Excellent information.

    One thing I don't understand is that you are positioning getting rid of app passwords, but the lates version of Outlook is 2019 and that still requires an app password.

    Am I missing something?

    Anyway thank you for this information. A God send.

    • Hi Joseph,

      Outlook 2013 and newer version of Outlook support modern authentication.

    • Actually, the link you mention offers a method to streamline the registration of multi-factor authentication.
      The registration process is the one-time action performed by people to define the method(s) they want to use.

      The blogpost is about requiring multi-factor authentication.
      It describes how to configure the settings to require people to perform multi-factor authentication every time they access resources.


    Excellent write up, very helpful.

    Do you know if per-user multi-factor authentication, is due to be retired at any point?

    • Everything is due to be retired, some time. 😉

      More consise, I think that the days of the legacy PhoneFactor portal are numbered. Looking at the Authentication Methods blade in Azure AD, I feel this will be the new home for the one feature that is not yet in the Azure Portal: the ability to enable/disable MFA methods.
      Another factor to consider is that management through the legacy portal works when there are no Azure AD Premium licenses in the tenant and Conditional Access does not. I feel Microsoft needs to formulate an answer for organizations in this situation that is better than Security Defaults, currently.


leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.