Azure Mandatory MFA: Move admins, CLI and automation off password-only sign-in

Microsoft now requires multifactor authentication for every user who signs in to Azure management tools, and automation that still runs under a user account breaks when enforcement reaches its tenant. Phase 1 covered the Azure portal and admin centres; Phase 2 extends the requirement to Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure as code tools, REST and SDK calls to the Azure Resource Manager control plane. This guide gives the official timeline as Microsoft publishes it, what is and is not in scope, how to find user accounts acting as service accounts, and how to move them to managed identities, service principals and workload identity federation. It is written for cloud platform, identity and DevOps engineers. Dates were checked on Microsoft Learn on 8 November 2026 (page last updated 3 April 2026). For the multi-cloud picture see the Cloud Provider Mandatory MFA guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The final deferral date has passed. Microsoft allowed tenants to postpone Phase 2 only until 1 July 2026; after enforcement starts a Global Administrator can only ask Microsoft support to lift it temporarily.
• Users are in scope, workload identities are not. Managed identities and service principals are unaffected by both phases; user identities used as service accounts must complete MFA, and Microsoft recommends moving them to workload identities.
• Phase 2 bites on writes. Create, update and delete calls to https://management.azure.com/ fail with an MFA claims challenge for users without MFA; reads are not affected, so broken automation can look healthy until it changes something.
• Password-only flows are finished. The ROPC flow cannot satisfy MFA; MSAL deprecated AcquireTokenByUsernamePassword in 4.74.0 and Azure.Identity deprecated UsernamePasswordCredential in 1.14.0-beta.2.
• Use Azure Policy to rehearse. Two built-in definitions let you audit, then deny, non-MFA create, update and delete operations by scope and region before Microsoft's enforcement reaches you.

What is changing and why

Microsoft's requirement applies to user sign-ins to specific first-party management applications. It is enforced by Microsoft rather than by your Conditional Access policies, so exclusions in your own policies do not exempt anyone from it. Microsoft's Phase 2 announcement of 5 September 2025 cites its research that MFA blocks the large majority of account compromise attacks; the practical driver is that password spray against an unprotected admin account remains a common route into cloud tenants (ATT&CK T1110.003 Password Spraying, then T1078.004 Cloud Accounts).

The change matters to non-human identity owners because many organisations still run pipelines, scheduled scripts and runbooks under a named user or a shared "svc-" user account with a password. Those accounts were never meant to answer an MFA prompt. The fix Microsoft documents is not to give them MFA but to replace them with identities designed for workloads. See the Workload Identity Federation Guide.

Official timeline and current status

Status on 8 November 2026: as published on Microsoft Learn, both phases have started and the latest postponement date for Phase 2 has passed. Postponing Phase 1 also moved Phase 2 to the same date unless a later one was chosen. Changing these settings required a Global Administrator with elevated access. There is no opt-out. Microsoft notified Global Administrators by email and through Azure Service Health, so check Service Health history for the dates applied to your tenant. Microsoft states that the requirement is not enforced in Azure Government or other sovereign clouds. Rollout details can change: treat this table as "as announced" and recheck the Learn page before planning.

Who and what is affected

Accepted methods include Microsoft Entra MFA methods, third-party MFA integrated through the external authentication method provider, and federated MFA. The legacy Conditional Access custom controls preview does not satisfy the requirement. Selecting "Stay signed in" does not avoid it. See the Break-Glass Account Guide and the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.

Finding affected systems and identities

1. Sign-in logs by application ID: filter Entra sign-in logs (or the SigninLogs table in Log Analytics) on the app IDs Microsoft lists: Azure portal and admin centres c44b4083-3bb0-49c1-b47d-974e53cbdf3c, Azure CLI 04b07795-8ddb-461a-bbee-02f9e1bf7b46, Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2, Azure mobile app 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa. IaC tools appear under the CLI or PowerShell IDs. Look for successful sign-ins where the authentication requirement was single factor.
2. Spot service-account behaviour: among those users, flag sign-ins at fixed intervals, from build agents, automation account IPs or data centre ranges, with no interactive device, and accounts named or described as service, svc, automation or pipeline.
3. Authentication method export: Microsoft links a PowerShell export of users and their registered methods (aka.ms/AzMFA). Users with no registered method who appear in step 1 are your first queue.
4. Code and configuration search: search repositories, pipeline variables and runbooks for az login -u, Connect-AzAccount with PSCredential, AZURE_USERNAME and AZURE_PASSWORD environment variables, AcquireTokenByUsernamePassword and UsernamePasswordCredential. Any hit is an ROPC dependency.
5. Audit-mode Azure Policy: assign the built-in definitions "Users must authenticate with multi-factor authentication to create or update resources" (4e6c27d5-a6ee-49cf-b2b4-d8fe90fa2b8b) and "Users must authenticate with multi-factor authentication to delete resources" (db4a9d17-db75-4f46-9fcb-9f9526604417) in audit mode (Audit for the first, AuditAction for the delete definition). Hits appear in the Activity Log as Microsoft.Authorization/policies/audit/action; the compliance view always shows 0 resources because the policy evaluates requests.
6. Conditional Access insights and reporting workbook: with sign-in logs in a Log Analytics workspace, select your MFA policy to see how many users and sign-ins it affects.
7. Client versions: inventory build images; Microsoft recommends Azure CLI 2.76 or later and Azure PowerShell 14.3 or later for compatibility.

Metrics: track (1) user accounts signing in to the four app IDs without MFA, target zero; (2) user-based service accounts remaining, burning down weekly; (3) Azure Policy audit events per week, by caller; (4) ROPC code hits open in repositories; (5) percentage of pipelines using federated or managed identities. See the Entra ID Sign-In and Audit Log Detection Guide.

Migration options

Decision guidance: pick managed identity whenever the code runs on Azure compute that supports it. Pick federation for CI/CD and other clouds, because it removes the long-lived secret the user account had. Use certificate-based service principals only where neither is possible, and treat them as secrets to be inventoried and rotated. Small organisations with a handful of scripts can usually move each one to a managed identity in a day. Large estates should group service accounts by owner and platform, migrate pipelines first (they break most visibly), and use Conditional Access for workload identities, which Microsoft notes needs the user licence reclaimed and a workload identity licence assigned.

Replacing username and password code paths

• MSAL: AcquireTokenByUsernamePassword is deprecated from Microsoft.Identity.Client 4.74.0 for both public and confidential client applications. Replace it with a managed identity, a client credential (certificate or federated assertion) or, for humans, an interactive or device code flow.
• Azure.Identity: DefaultAzureCredential and EnvironmentCredential pick up AZURE_USERNAME and AZURE_PASSWORD if they are set, so remove those variables from build agents and containers; otherwise a migrated job can silently fall back to the old user. UsernamePasswordCredential is deprecated from 1.14.0-beta.2.
• Infrastructure as code: Terraform, Bicep and similar tools authenticate through the Azure CLI or PowerShell identity, which is why Microsoft lists them under those app IDs. Point the provider at a managed identity or an OIDC-federated service principal rather than a cached user login on the agent.
• Scheduled scripts on servers: stored PSCredential objects for a user account are the most common hidden dependency. Arc-enabled or Azure-hosted servers can use a managed identity instead.

Permissions during migration: do not copy the user's role assignments wholesale. Grant the new identity only the roles the job needs at the narrowest scope, then remove the user account's roles and disable it. See the Azure Managed Identities Security Guide, the GitHub Actions OIDC Federation Hardening Guide and the Azure Entra Client Secrets Security Guide.

Testing and rollback

1. Audit first: assign both policy definitions in Audit at a management group, starting with a few low-risk regions using a resourceLocation resource selector, then widen to all regions.
2. Review callers: query AzureActivity for the policy definition IDs to list who would be blocked, and match them to the inventory.
3. Migrate and verify: for each job, run it once with the new identity in a non-production subscription, confirm writes succeed, then switch production and keep the old account disabled, not deleted, for a short fallback window.
4. Enforce in rings: add a policy effect override of Deny or DenyAction for low-risk regions, then expand. Add a non-compliance message pointing users to MFA registration.
5. Rollback: your own Azure Policy can be returned to Audit or the assignment removed. Microsoft's platform enforcement cannot be rolled back by you; if production breaks after Microsoft enforces, re-enable the old job only by moving it to a workload identity, or ask Microsoft support through a Global Administrator to lift enforcement temporarily, as the Learn page describes.

Risks of doing nothing

• Silent failures: deployments and runbooks that only read keep running while every create, update or delete fails, so drift and failed patches accumulate.
• Emergency workarounds: teams under pressure register an authenticator for a shared service account on someone's phone, which creates an unowned, shared MFA factor.
• Locked-out break-glass: emergency accounts without a passkey or certificate cannot reach the portal when needed.
• Forgotten tenants: test and legacy tenants are in scope. Include non-production test tenants in your inventory and confirm every account in them signs in with MFA.
• Library dead ends: code on deprecated username and password APIs will need rewriting under time pressure.

Framework mapping

Practitioner checklist

• Check Azure Service Health history and the Learn page for the enforcement dates applied to your tenant.
• Query sign-in logs for the four app IDs and list every user signing in without MFA.
• Tag each as human or automation, with an owner.
• Search code and pipelines for ROPC patterns and deprecated username and password credentials.
• Move Azure-hosted jobs to managed identities and CI/CD to workload identity federation.
• Give break-glass accounts passkeys or certificate-based authentication and test them.
• Upgrade build images to Azure CLI 2.76+ and Azure PowerShell 14.3+.
• Assign the two built-in MFA policy definitions in Audit, then Deny in rings.
• Disable migrated user service accounts and remove their role assignments.
• Report the five metrics monthly until user-based automation reaches zero.

Standards and references

• Microsoft Learn: Planning for mandatory multifactor authentication for Azure and other admin portals
• Microsoft Azure Blog: Azure mandatory multifactor authentication Phase 2 starting in October 2025
• Microsoft Learn: Tutorial: Apply MFA self-enforcement through Azure Policy
• Microsoft Learn: How to verify users are set up for mandatory MFA
• Microsoft Learn: Securing cloud-based service accounts
• Microsoft Learn: Workload identity federation
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Workload Identity Federation Guide · Azure Managed Identities Security Guide · Conditional Access Guide · Phishing-Resistant MFA Guide