We would like to share an update on the announcement that Microsoft will require multi-factor authentication (MFA) for users signing into Azure. In this post, we share clarifications on the scope, timing and implementation details, along with guidance for preparation.
Timing
Enforcement for the MFA requirement at Azure sign-in will be rolled out in phases:
Phase 1: Starting in July 2024, enforcement for MFA at sign-in for Azure portal only will roll out gradually to all tenants. This phase will not impact any other Azure clients, such as Azure CLI, Azure PowerShell and IaC tools.
Phase 2: Starting in early 2025, enforcement for MFA at sign-in for Azure Command Line Interface (CLI), Azure PowerShell and Infrastructure as Code (IaC) tools will gradually roll out to all tenants.
For both phases, Microsoft will notify global admins about the expected enforcement date of your tenant(s) by email and through Azure Service Notifications, 60 days in advance. The countdown for enforcement for your tenant(s) does not begin until you have received this first notification from us. Additionally, we will send out periodic reminders to global admins at a regular cadence between the first notification and the beginning of enforcement for your tenant(s).
We will also allow a grace period for select customers with use cases where no workarounds are easily available and who need additional time (beyond the start date of enforcement for their tenants) to prepare for the MFA requirement at Azure sign-in. The first notification from us stating the enforcement date for your tenant(s) will also include a link to apply for the grace period. Additional details on customer types, use cases and scenarios that are eligible for grace period will be included in the notification.
Scope of enforcement
User accounts
We heard your feedback noting confusion about which users will be impacted by this requirement. We want to clarify that all users signing into the Azure portal, Azure CLI, Azure PowerShell and IaC tools, such as Azure Developer CLI, Bicep, Terraform and Ansible to perform any CRUD (Create, Read, Update, Delete) operation will require MFA when the enforcement begins. End users who are accessing apps, websites or services hosted on Azure, but not signing into the Azure portal, CLI or PowerShell, are not subject to this requirement from Microsoft. Authentication requirements for end users will still be controlled by the app, website or service owners.
We’d like to reenforce that Microsoft recommends adoption of MFA as one of the most fundamental security measures for all users given the growing intensity and sophistication of current Cyber-threats.
Automation accounts
Workload Identities, such as managed identities and service principals, will not be impacted by this enforcement. If you are leveraging user identities as a service account running automation (including scripts or other automated tasks), those will be required to use MFA once enforcement begins. Our guidance is that user identities are not recommended for automation and customers should migrate those to Workload Identities.
Implementation
This requirement for MFA at sign-in is implemented by Azure. Microsoft Entra ID sign-in logs will show it as the source of the MFA requirement.
This requirement will be implemented on top of any access policies you’ve 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 will see no change in behavior 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 will not see a change. Similarly, if you have existing more restrictive Conditional Access policies in place targeting Azure that require stronger authentication, such as phishing-resistant MFA, then those policies will continue to be enforced and your users will not see any changes.
Available MFA Methods
All supported MFA methods are available for you to use and there are no changes to the authentication method features as part of this requirement. Support for external MFA solutions is in public preview with external authentication methods, and can be used to meet the MFA requirement. The deprecated Conditional Access Custom Controls preview will not satisfy the MFA requirement, and you should migrate to the external authentication methods preview to use an external solution with Microsoft Entra ID.
If you are using a federated Identity Provider (IdP), such as Active Directory Federation Services, and your MFA provider is integrated directly with this federated identity provider, the Federated identity provider must send an MFA claim.
Identifying impacted Azure users in your tenant
You can use the resources below to help you identify which users are signing into Azure with and without MFA:
- Use this PowerShell command to export a list of users and their auth methods: https://aka.ms/AzMFA
- Use this Multifactor Authentication Gaps workbook: Multifactor Authentication Gaps workbook - Microsoft Entra ID | Microsoft Learn
- Use these App IDs in your queries:
- Azure portal: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
- Azure CLI: 04b07795-8ddb-461a-bbee-02f9e1bf7b46
- Azure PowerShell: 1950a258-227b-4e31-a9cf-717495945fc2
Break glass accounts and special scenarios
We have heard your questions about break glass or “emergency access” accounts. We recommend updating these accounts to use FIDO2 or certificate-based authentication (when configured as MFA) instead of relying only on a long password. Both methods will satisfy the MFA requirements.
In addition, below are a few scenarios for which we are still working on developing guidance, and we will address these in an upcoming blog post scheduled for mid-August:
- Organizations using privileged access management with delegation management, or other security approaches with additional security for accounts shared by multiple people.
- Hands-on Azure learning and labs that utilize user identities created and deleted within a short timeframe.
- Utilizing Azure APIs that require an Entra user identity or APIs that don’t support application permissions.
What you can do to get ready
We recommend setting up MFA now to secure your cloud resources. Keep users and data safe by setting up MFA with the MFA wizard for Microsoft Entraand learn more from the MFA deployment guide. If you’re using user identities for automation, start the process of migrating to managed identities or service principals.
We will continue to publish blog posts, articles and direct customer notifications regarding the requirement for MFA at Azure sign-in to help you effectively prepare and keep your cloud resources secure.
Thank you,
Naj Shahid and Greg Kinasewitz
