Azure mandatory MFA is enforced: fix the scripts, pipelines and service accounts it broke

Microsoft now requires multifactor authentication for any user account that manages Azure, from any tool. Phase 1 covered the portals from October 2024; Phase 2 covered the Azure CLI, Azure PowerShell, the mobile app, infrastructure-as-code tools, SDKs and the Resource Manager REST API from 1 October 2025, for create, update and delete operations. Tenants could postpone Phase 2 until 1 July 2026 at the latest, so by now it applies to everyone in the public cloud. People barely notice, because their sign-in already has MFA. What breaks is automation that signs in as a person: a scheduled script with a stored password, a pipeline with a user account's credentials, a "service account" that is really a user. This guide shows what the failures look like, how to find every such account, and how to move each one to an identity that can't be phished.

What is and isn't in scope

Your own Conditional Access policies still apply on top; stronger requirements such as phishing-resistant MFA stay in force.

What the failure looks like

• Azure CLI 2.76 and later, when the signed-in session lacks MFA and the command writes: (RequestDisallowedByPolicy) Resource was disallowed by policy … Users must use MFA for Create/Update operations, with a suggested az login --tenant … --scope "https://management.core.windows.net//.default" --claims-challenge "<token>" to step up interactively. Older CLI versions give a vaguer "Interactive authentication is needed" or "Resource was disallowed by policy. Reasons: MFA is required". Azure PowerShell 14.3 and later behave the same way.
• An interactive sign-in that suddenly asks for MFA, or AADSTS50076 in an app's logs: the account must complete MFA. Fine for a person; impossible for a scheduled job.
• A script using a username and password stops working. The Resource Owner Password Credentials flow (AcquireTokenByUsernamePassword in MSAL, UsernamePasswordCredential in the Azure Identity libraries, or DefaultAzureCredential with AZURE_USERNAME and AZURE_PASSWORD set) can't do MFA and now throws. The SDKs have deprecated those APIs.
• A pipeline service connection that signs in as a user fails the same way; Azure DevOps and GitHub connections that use a service principal or workload identity federation are unaffected.

A person can fix the first two for themselves by signing in again with MFA. Everything else needs the change below.

Find the accounts that will break

Microsoft's own advice: discover the user accounts used as service accounts before they fail. In the Entra admin centre, open Sign-in logs and filter on the Phase 2 applications:

With the logs in a Log Analytics workspace, this lists the user sign-ins that completed without MFA:

SigninLogs
| where TimeGenerated > ago(30d)
| where AppId in ("04b07795-8ddb-461a-bbee-02f9e1bf7b46", "1950a258-227b-4e31-a9cf-717495945fc2")
| where AuthenticationRequirement == "singleFactorAuthentication"
| summarize SignIns = count(), LastSeen = max(TimeGenerated) by UserPrincipalName, AppDisplayName, IPAddress
| order by SignIns desc

Accounts that sign in on a schedule, from a server's IP, with no MFA, are your automation. Microsoft also publishes a PowerShell script that exports every user with their registered authentication methods, and a built-in Azure Policy definition that audits or denies non-MFA management operations tenant-wide, so you can see the impact before relying on it.

Move each one to a workload identity

Replace the user account with an identity that isn't a person, choosing the first that fits:

1. A managed identity, when the automation runs on Azure: an Automation runbook, a Function, a Logic App, a VM, a container, a hosted pipeline agent on an Azure VM. Nothing to store or rotate. Connect-AzAccount -Identity and az login --identity sign in as the resource; add --client-id for a user-assigned identity. Our managed identities guide covers the set-up.
2. Workload identity federation, when the automation runs somewhere else that issues its own tokens: GitHub Actions, Azure DevOps, GitLab, Kubernetes. A federated credential on an app registration or a user-assigned managed identity trusts that platform's token for an exact issuer and subject; the pipeline's azure/login or ARM service connection exchanges it for an Azure token. No secret anywhere. Renaming the repository, environment, organisation, project or service connection breaks the match (AADSTS70021), so put the names in the runbook.
3. A service principal with a certificate, when neither is possible (an on-premises server, a third-party tool). az login --service-principal --username <appId> --tenant <tenant> --certificate <path> or Connect-AzAccount -ServicePrincipal -CertificateThumbprint …. Prefer a certificate to a client secret; both expire, so monitor the date.

Then move the Azure roles from the user to the new identity, at the same scope and no wider, and disable the user account once its last sign-in is old. If the user account had Conditional Access policies applied to it, you can reclaim its licence; Conditional Access for workload identities (a separate Workload Identities Premium licence) is how you constrain service principals by location or risk, since user policies don't apply to them.

Confirm the tenant, and keep people working

• Confirm enforcement. As a Global Administrator, https://aka.ms/postponePhase2MFA shows a banner once Phase 2 enforcement has begun for the tenant (https://aka.ms/managemfaforazure for Phase 1). The sign-in logs show which application enforced MFA as the source of the requirement.
• Keep tools current. Azure CLI 2.76 and Azure PowerShell 14.3 or later show the real reason and the step-up command; older versions fail with a generic message that sends people the wrong way.
• Give people MFA before the error does. With Entra ID P1 or P2, a Conditional Access policy requiring an authentication strength of MFA on Microsoft Admin Portals and Windows Azure Service Management API, created in report-only mode first; without P1, security defaults. Users who sign in without MFA can still read, but each write returns a claims challenge, and only some clients turn that into a prompt.
• Break-glass accounts are in scope too. Microsoft's answer is a passkey (FIDO2) or certificate-based authentication for them, which satisfies MFA without depending on a phone; our break-glass guide has the rest.
• Federated tenants. If sign-in goes through AD FS or another identity provider that does the MFA, it must send the multipleauthn claim to Entra; the old Conditional Access custom controls don't count. External MFA providers integrate directly as an external authentication method.
• After enforcement, a temporary lift is possible through Microsoft support, requested by a Global Administrator, for genuine emergencies only.

Sources

• Mandatory multifactor authentication for Azure and admin portals, Microsoft Learn (phases, dates, application IDs, scope, client libraries, postponement, confirmation, FAQ)
• Verify that users are set up for mandatory multifactor authentication, Microsoft Learn
• Troubleshooting Azure CLI: multifactor authentication, Microsoft Learn
• Sign in to Azure with a managed identity using Azure CLI, Microsoft Learn
• Conditional Access for workload identities, Microsoft Learn
• Manage emergency access accounts in Microsoft Entra ID, Microsoft Learn (passkeys for break-glass accounts)