Azure now requires MFA to change resources from the CLI: what breaks in your automation

Since 1 July 2026 there is no way left to defer it: any user account that creates, updates or deletes Azure resources must have completed MFA, whether through the portal, the CLI, PowerShell, Terraform or the SDK. Microsoft started enforcing the second phase of mandatory MFA on 1 October 2025, gradually, and let tenants with complex environments postpone it until 1 July 2026. That date has passed.

For the person who opens the portal with a phone at hand, the change goes almost unnoticed. What breaks is automation running under a user account: the nightly script that scales a cluster, the pipeline that deploys as the company’s devops@ user, the scheduled task someone set up with their own password four years ago. And it breaks late, because reads keep working: the script that only queries passes, the one that changes something fails.

What exactly does phase 2 of Azure mandatory MFA require?

MFA for every create, update or delete operation that reaches Azure Resource Manager under a user identity. According to the Microsoft Entra documentation, the rule is enforced server-side: any request to https://management.azure.com is in scope, whatever the client. That includes:

• Azure CLI and Azure PowerShell, identified in sign-in logs by their application IDs: 04b07795-8ddb-461a-bbee-02f9e1bf7b46 and 1950a258-227b-4e31-a9cf-717495945fc2.
• Infrastructure as code tools, which inherit the CLI or PowerShell identity.
• The Azure SDK, the control plane REST API and the Azure mobile app.

Reads do not require MFA. Microsoft Graph is generally out of scope. The Microsoft Entra Connect sync account is not affected.

What has no exception: emergency access accounts, administrators, B2B guests and test tenants. For emergency accounts, Microsoft recommends FIDO2 passkeys or certificate-based authentication. One valve remains: once enforcement has started, a Global Administrator can ask Microsoft support to lift it temporarily, which fixes nothing.

What stops working in scripts and pipelines?

Anything that obtains a token with a username and password. The OAuth 2.0 Resource Owner Password Credentials (ROPC) flow is incompatible with MFA, and Microsoft documents the error az login --username --password returns when the user has to use MFA: AADSTS50076. The typical cases:

1. Scripts running az login -u -p stored on a server or in a scheduled task. If the tenant already requires MFA at sign-in, they fail at login with that error. If not, they sign in, read without trouble and fail on the first operation that changes something.
2. Code using DefaultAzureCredential with the AZURE_USERNAME and AZURE_PASSWORD environment variables set. This is the treacherous one: the code never mentions a password, the credential picks it up from the environment through EnvironmentCredential, and Microsoft lists it among the uses that require changes.
3. Calls to MSAL’s AcquireTokenByUsernamePassword, marked deprecated for public clients in the .NET, Java, Node.js, Python and Go libraries.
4. Service accounts synced from Active Directory. Living in the on-premises directory does not exempt them: they are subject to the same requirement as any other user.

For diagnosis: up to Azure CLI 2.75, the failure arrives as a generic “Resource was disallowed by policy. Reasons: MFA is required”. From 2.76 onwards, the CLI also returns the exact command to re-authenticate with the claims challenge. Microsoft recommends Azure CLI 2.76 and Azure PowerShell 14.3 or later.

How do I find the user accounts acting as service accounts?

With sign-in logs and a report-only policy, before the error finds them for you. Three sources, from cheapest to most complete:

• Microsoft Entra sign-in logs, filtered by the CLI and PowerShell application IDs, which is the filter Microsoft suggests. What we look for: a user who always signs in from a server IP, at the same hour, never completing a second factor. That is not a person.
• A report-only Conditional Access policy requiring MFA on the Windows Azure Service Management API and Microsoft Admin Portals applications. The Conditional Access workbook shows how many sign-ins would have failed; it needs Entra ID P1 or P2 and the logs in Log Analytics.
• Azure Policy in audit mode, with the two built-in definitions Microsoft publishes in preview: one for creating or updating resources and one for deleting them. Every audit event is a real operation performed without MFA.

The trap in the third option: events only show up in the activity log. The policy compliance list always shows zero resources, because the policy evaluates requests rather than resources, and it is easy to conclude nothing is pending by looking at that screen. To move from audit to deny, Microsoft recommends doing it region by region with resource selectors, starting with the lowest-risk ones.

Which identity should each automation move to?

To a workload identity: managed identities and service principals sit outside mandatory MFA in both phases. Which one depends on where the process runs:

• If it runs inside Azure (a VM, Functions, Automation): a managed identity. The credentials are visible to nobody; Azure handles secrets, certificates and keys.
• If it is a GitHub Actions pipeline: identity federation over OIDC. The job requests a token from GitHub and exchanges it for a Microsoft one, with no stored secret. Per Microsoft’s guide, all it takes is the id-token: write permission and the azure/login@v2 action with the client, tenant and subscription IDs. That permission belongs only in the deploying job, never at workflow level.
• If it is Azure Pipelines: a service connection with identity federation, which Microsoft recommends as the first option. An existing secret-based connection converts with one button if Azure DevOps created it and a single project uses it, and the conversion can be reverted for seven days. Note one more expiry: the Azure DevOps issuer, vstoken.dev.azure.com, retires on 1 July 2027 in favour of the Microsoft Entra issuer.
• If it runs outside Azure (your own Kubernetes, AWS, Google Cloud or SPIFFE workloads): the same workload identity federation. The token’s issuer, subject and audience must match what is configured in Entra exactly, case included. If federation rejects a token that looks right, that is the first thing to check.

A service principal with a secret also sidesteps MFA, but it trades one problem for another: a secret you have to store, rotate, and that one day expires in the middle of a deployment. We use it only when federation is not possible, and with a certificate instead of a secret.

What about traceability, if no person signs the change anymore?

It improves, if done well. It is the argument heard most often for keeping user accounts in automation, but behind devops@ there are usually four people sharing one password. Who made the change is answered by the pipeline: who approved the run, which commit was deployed and under which identity. A protected environment with mandatory approval records that chain without anyone sharing credentials.

What changes in Google Cloud from 20 October?

Two-step verification becomes mandatory to access the Google Cloud console and the Firebase console for organisations on Enterprise Cloud Identity without SSO. Google’s schedule, updated on 24 September, sets the dates that affect a company:

• Enterprise Cloud Identity without SSO, organisations created before 3 August 2026: from 20 October 2026, with a one-time 90-day extension enabled at organisation level.
• Organisations created from 3 August 2026: 30 days after creation.
• Accounts using federated authentication: to be announced.

The difference from Azure is fundamental. In Google, the gcloud CLI has no two-step verification requirement, and applications, workloads and the data plane are not affected; the second factor is required to manage through the console. In Google, the requirement falls on people; in Azure, it breaks automation. Google also lets these organisations opt out of the requirement. The option exists and we would not use it: the account that cannot have a second factor is usually exactly the one that should become a workload identity.

Where we would start this week

1. Confirm the tenant’s status. A Global Administrator can see at aka.ms/postponePhase2MFA whether phase 2 is already enforced.
2. List CLI and PowerShell sign-ins for the last 30 days and separate people from processes.
3. Search for AZURE_USERNAME and az login -u on servers, scheduled tasks and pipeline variables, not only in repositories.
4. Migrate by order of impact: first whatever deploys or scales in production; each process with its own identity and the minimum role.
5. Set up emergency accounts with a FIDO2 passkey and sign in with one of them. An emergency account nobody has tested is not a plan.
6. If you have Google Cloud organisations without SSO, turn on two-step verification before 20 October instead of spending the 90-day extension.

How we help at Athrun Data Intelligence

A 30-minute call to review which processes in your cloud still run under user accounts and which ones will break the next time they try to change something. If it fits, we build the inventory from sign-in logs, move each automation to managed or federated identities with the minimum role, and switch Azure Policy to deny region by region, without cutting production.