“If only multifactor authentication was enforced for that user account.” This is the phrase that is all too familiar to security responders investigating incidents. Attacks such as Brute Force, Password Spraying, and Phishing continue to be effective tools that grant attackers unauthorized access into systems. To help combat these techniques, we are taking the next step in our journey to zero trust to protect the full customer and partner ecosystem by turning on Microsoft Azure Active Directory security defaults for customers. This blog’s focus is to help our partners who are managing their customer’s tenants understand this change so they can be proactive and enable the defaults for their customers today.

About Azure Active Directory security defaults

In a recent blog post, we announced that we are rolling out security defaults to existing Azure Active Directory tenants. Multifactor authentication, or MFA, is an important part of security defaults, and continues to prove effective against 99.9% of identity-related attacks. This rollout will include customer tenants that are managed by Microsoft partners. Customer tenants that meet one or more of the following criteria are not currently eligible for the security defaults rollout and in these cases, we’re asking partners to work with their customers to ensure MFA is turned on for all accounts in the customer’s Azure AD tenant:

  • The tenant is currently using Conditional Access policies. You can view existing Conditional Access policies as well as gain insight for ways to improve existing policies and coverage by using the new Conditional Access Overview page.    
  • The tenant has turned off security defaults in the past. 
  • The tenant currently has apps using legacy authentication. You can determine if your customer is using apps that use legacy authentication by following this article.

Customers depend on you, our partners, to secure their Azure Active Directory environment against attackers. To step up to this challenge, if your customer is not already using Conditional Access policies to enforce MFA, we encourage you to turn on security defaults now in your customer’s Azure AD tenants versus waiting for us to deploy it to your customer. Below, we have provided the step-by-step instructions for how partners can roll this out today.

Turning on security defaults

Turning on Azure AD security defaults is incredibly simple and can be achieved by following these 5 steps:

  1. Sign in to the Azure portal as a Security administrator, Conditional Access administrator, or Global administrator.
  2. Browse to Azure Active Directory > Properties.
  3. Select Manage security defaults.
  4. Set the Enable security defaults toggle to Yes.
  5. Select Save.

Register for multifactor authentication experience

After you enable security defaults in your customer’s Azure Active Directory tenant, users in the tenant will be required to register for MFA via the Microsoft Authenticator mobile app and will be allowed to pause this registration for 14 days. Users with the Global Administrator role are also required to provide a phone number. Below are examples of what your users and Global Administrators will see upon login once security defaults are enabled.

Important: You can track MFA registration progress using the report shown below. Please be sure to follow up with users who do not register for MFA. This is also a great opportunity to catch accounts that should have been disabled. Note: Dormant user accounts with no MFA are prime targets for attackers.

Login behavior changes

Once registered for MFA, users will be prompted for MFA as needed based on factors such as location, device, role, and task.  Due to the power and elevated rights administrators have, users with certain Azure AD administrator roles will be prompted for MFA every time they log in. These Azure AD administrator roles can be found here.

Helping customers adopt MFA

We understand that some of your customers may not be ready or are opposed to adopting MFA due to the perceived friction it causes during the login process. Here are some talking points to help guide you when discussing security defaults with customers:

  • If you are a user who does not have an Azure AD administrator role, you will only be prompted for MFA if Azure AD suspects there is suspicious activity with your account and/or the login. Security defaults will not cause MFA prompts for every login for users who do not have an Azure AD administrator role assigned.
  • If you are a user who is assigned a privileged Azure AD administrator role, then the more frequent MFA prompts are due to the increased exposure of that role. You can use Privileged Identity Management (PIM) to convert your account to be eligible for that role, so that with just-in-time access, your account is only in a privileged role when you need to perform a privileged task. PIM ensures user accounts do not have standing administrator access.  See the following link for more information on best practices for embracing least privilege and no standing access, which are key pillars of Zero Trust: Best practices for Azure AD roles
  • Use the following statistics to prove why MFA should be enabled:
    • MFA can stop 99.9% of identity-related attacks. 
    • Organizations with security defaults enabled experience 79% less compromise than all Azure AD tenants.
  • Consider contract language to not allow customers to have any administrative roles or have contributor rights on any Azure subscription unless their accounts are protected with MFA. This will limit the impact that occurs when the customer’s user account without MFA is compromised.

Opting out of security defaults

If the customer is still adamant about opting out of security defaults even after you’ve explained the protections that security defaults provide, you can turn off security defaults through the Azure Active Directory properties page or through the Microsoft 365 admin center. Please be sure to provide the reason the customer wanted to opt out in the dialog that displays when the Enable security defaults option is switched to No, as shown below. This helps us make improvements to the feature in upcoming releases. 

Wrapping up

I hope this blog was useful to help you prepare for enabling security defaults in your customer’s Azure Active Directory tenants. Please follow the important steps outlined in this blog to help secure your customers and the entire partner ecosystem. Thank you for your partnership.


Related blogs

Share article