Planning for mandatory multifactor authentication for Azure and other admin portals

At Microsoft, we're committed to providing our customers with the highest level of security. One of the most effective security measures available to them is multifactor authentication (MFA). Research by Microsoft shows that MFA can block more than 99.2% of account compromise attacks.

That's why, starting in 2024, we'll enforce mandatory multifactor authentication (MFA) for all Azure sign-in attempts. For more background about this requirement, check out our blog post. This topic covers which applications and accounts are affected, how enforcement gets rolled out to tenants, and other common questions and answers.

There's no change for users if your organization already enforces MFA for them, or if they sign in with stronger methods like passwordless or passkey (FIDO2). To verify that MFA is enabled, see How to verify that users are set up for mandatory MFA.

Scope of enforcement

The scope of enforcement includes which applications plan to enforce MFA, when enforcement is planned to occur, and which accounts have a mandatory MFA requirement.

Applications

Accounts

All users who sign into the applications listed earlier to perform any Create, Read, Update, or Delete (CRUD) operation must complete MFA when the enforcement begins. Users aren't required to use MFA if they access other applications, websites, or services hosted on Azure. Each application, website, or service owner listed earlier controls the authentication requirements for users.

Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins. We recommend that you update these accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both methods satisfy the MFA requirement.

Workload identities, such as managed identities and service principals, aren't impacted by either phase of this MFA enforcement. If user identities are used to sign in as a service account to run automation (including scripts or other automated tasks), those user identities need to sign in with MFA once enforcement begins. User identities aren't recommended for automation. You should migrate those user identities to workload identities.

Migrate user-based service accounts to workload identities

We recommend customers discover user accounts that are used as service accounts begin to migrate them to workload identities. Migration often requires updating scripts and automation processes to use workload identities.

Review How to verify that users are set up for mandatory MFA to identify all user accounts, including user accounts being used as service accounts, that sign in to the applications.

For more information about how to migrate from user-based service accounts to workload identities for authentication with these applications, see:

• Sign into Azure with a managed identity using the Azure CLI
• Sign into Azure with a service principal using the Azure CLI
• Sign in to Azure PowerShell non-interactively for automation scenarios includes guidance for both managed identity and service principal use cases

Some customers apply Conditional Access policies to user-based service accounts. You can reclaim the user-based license, and add a workload identities license to apply Conditional Access for workload identities.

Implementation

This requirement for MFA at sign-in is implemented for admin portals. Microsoft Entra ID sign-in logs shows it as the source of the MFA requirement.

Mandatory MFA for admin portals isn't configurable. It's implemented separately from any access policies that you configured in your tenant.

For example, if your organization chose to retain Microsoft’s security defaults, and you currently have security defaults enabled, your users don't see any changes as MFA is already required for Azure management. If your tenant is using Conditional Access policies in Microsoft Entra and you already have a Conditional Access policy through which users sign into Azure with MFA, then your users don't see a change. Similarly, any restrictive Conditional Access policies that target Azure and require stronger authentication, such as phishing-resistant MFA, continue to be enforced. Users don't see any changes.

Enforcement phases

The enforcement of MFA rolls out in two phases:

• Phase 1: Starting in the second half of 2024, MFA will be required to sign in to the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center. The enforcement will gradually roll out to all tenants worldwide. This phase won't impact other Azure clients such as Azure CLI, Azure PowerShell, Azure mobile app, or IaC tools. 

• Phase 2: Beginning in early 2025, MFA enforcement gradually begins for sign in to Azure CLI, Azure PowerShell, Azure mobile app, and IaC tools. Some customers may use a user account in Microsoft Entra ID as a service account. It's recommended to migrate these user-based service accounts to secure cloud based service accounts with workload identities.

Notification channels

Microsoft will notify all Microsoft Entra Global Administrators through the following channels:

• Email: Global Administrators who configured an email address will be informed by email of the upcoming MFA enforcement and the actions required to be prepared.

• Service health notification: Global Administrators receive a service health notification through the Azure portal, with the tracking ID of 4V20-VX0. This notification contains the same information as the email. Global Administrators can also subscribe to receive service health notifications through email.

• Portal notification: A notification appears in the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center when they sign in. The portal notification links to this topic for more information about the mandatory MFA enforcement.

• Microsoft 365 message center: A message appears in the Microsoft 365 message center with message ID: MC862873. This message has the same information as the email and service health notification.

After enforcement, a banner appears in Microsoft Entra multifactor authentication:

External authentication methods and identity providers

Support for external MFA solutions is in preview with external authentication methods, and can be used to meet the MFA requirement. The legacy Conditional Access custom controls preview doesn't satisfy the MFA requirement. You should migrate to the external authentication methods preview to use an external solution with Microsoft Entra ID. 

If you're using a federated Identity Provider (IdP), such as Active Directory Federation Services, and your MFA provider is integrated directly with this federated IdP, the federated IdP must be configured to send an MFA claim.

Request more time to prepare for enforcement

We understand that some customers may need more time to prepare for this MFA requirement. Microsoft is allowing customers with complex environments or technical barriers to postpone the enforcement for their tenants until March 15, 2025.

Between August 15, 2024 and October 15, 2024, Global Administrators can go to the Azure portal to postpone the start date of enforcement for their tenant to March 15, 2025. Global Administrators must have elevated access before postponing the start date of MFA enforcement on this page.

Global Administrators must perform this action for every tenant where they want to postpone the start date of enforcement.

By postponing the start date of enforcement, you take extra risk because accounts that access Microsoft services like the Azure portal are highly valuable targets for threat actors. We recommend all tenants set up MFA now to secure cloud resources. 

FAQs

Question: If the tenant is only used for testing, is MFA required?

Answer: Yes, every Azure tenant will require MFA, there are no exceptions.

Question: Is MFA mandatory for all users or only administrators?

Answer: All users who sign in to any of the applications listed previously are required to complete MFA, regardless of any adminstrator roles that are activated or eligible for them, or any user exclusions that are enabled for them.

Question: Will I need to complete MFA if I choose the option to Stay signed in?

Answer: Yes, even if you choose Stay signed in, you're required to complete MFA before you can sign in to these applications.

Question: Will the enforcement apply to B2B guest accounts?

Answer: Yes, MFA has to be adhered either from the partner resource tenant, or the user's home tenant if it's set up properly to send MFA claims to the resource tenant by using cross-tenant access.

Question: How can we comply if we enforce MFA by using another identity provider or MFA solution, and we don't enforce by using Microsoft Entra MFA?

Answer: The identity provider solution needs to be configured properly to send the multipleauthn claim to Microsoft Entra ID. For more information, see Microsoft Entra multifactor authentication external method provider reference.

Question: Will phase 1 or phase 2 of mandatory MFA impact my ability to sync with Microsoft Entra Connect or Microsoft Entra Cloud Sync?

Answer: No. The synchronization service account isn't affected by the mandatory MFA requirement. Only applications listed earlier require MFA for sign in.

Question: Will I be able to opt out?

There's no way to opt out. This security motion is critical to all safety and security of the Azure platform and is being repeated across cloud vendors. For example, see Secure by Design: AWS to enhance MFA requirements in 2024.

An option to postpone the enforcement start date is available for customers. Between August 15, 2024 and October 15, 2024, Global Administrators can go to the Azure portal to postpone the start date of enforcement for their tenant to March 15, 2025. Global Administrators must have elevated access before postponing the start date of MFA enforcement on this page and they must perform this action for every tenant for which they would like to postpone the start date of enforcement.

Question: Can I test MFA before Azure enforces the policy to ensure nothing breaks?

Answer: Yes, you can test their MFA through the manual setup process for MFA. We encourage you to set this up and test. If you use Conditional Access to enforce MFA, you can use Conditional Access templates to test your policy. For more information, see Require multifactor authentication for admins accessing Microsoft admin portals. If you run a free edition of Microsoft Entra ID, you can enable security defaults.

Question: What if I already have MFA enabled, what happens next?

Answer: Customers that already require MFA for their users who access the applications listed earlier don't see any change. If you only require MFA for a subset of users, then any users not already using MFA will now need to use MFA when they sign in to the applications.

Question: How can I review MFA activity in Microsoft Entra ID?

Answer: To review details about when a user is prompted to sign in with MFA, use the Microsoft Entra sign-ins report. For more information, see Sign-in event details for Microsoft Entra multifactor authentication.

Question: What if I have a "break glass" scenario?

Answer: We recommend updating these accounts to use passkey (FIDO2) or configure certificate-based authentication for MFA. Both methods satisfy the MFA requirement.

Question: What if I don’t receive an email about enabling MFA before it was enforced, and then I get locked-out. How should I resolve it? 

Answer: Users shouldn't be locked out, but they may get a message that prompts them to enable MFA once enforcement for their tenant has started. If the user is locked out, there may be other issues. For more information, see Account has been locked. 

Related content

Review the following topics to learn more about how to configure and deploy MFA:

• How to verify that users are set up for mandatory MFA
• Tutorial: Secure user sign-in events with Microsoft Entra multifactor authentication
• Secure sign-in events with Microsoft Entra multifactor
• Plan a Microsoft Entra multifactor authentication deployment
• Phishing-resistant MFA methods
• Microsoft Entra multifactor authentication
• Authentication methods