Azure MFA Broke Your Scripts? Fix Them With Managed Identities

Your nightly cleanup job worked for two years. Then it started failing on az vm deallocate with an error about signing in with MFA, while az vm list still ran fine. Nothing in your script changed. Microsoft's enforcement did.

This guide shows you how to confirm that mandatory MFA caused the failure, find every user account your automation hides behind, and replace each one with the right workload identity. Every command and date below comes from Microsoft Learn, current as of October 2026.

What Microsoft enforces, and when it started

Microsoft rolled mandatory MFA out in two phases. Phase 1 covered the admin portals. Phase 2 covers the tools your scripts use.

Global Administrators could postpone Phase 2, but only until July 1, 2026. That window has closed, so every tenant in the public Azure cloud now enforces it. Microsoft doesn't enforce it in Azure for US Government or other sovereign clouds.

The check happens on Azure Resource Manager, so any request to https://management.azure.com is in scope, whichever client sent it. That explains the pattern in the opening example: reads pass and writes fail.

Confirm that MFA enforcement broke your script

Users who sign in without MFA can still open a Phase 2 tool. The failure arrives at the first create, update, or delete, as an error that asks for MFA through a claims challenge. Interactive clients sometimes turn that challenge into a prompt. A scheduled task has nobody to answer it.

Check three things:

1. Enforcement status. As a Global Administrator, open https://aka.ms/postponePhase2MFA in the Azure portal. A banner confirms when enforcement began for your tenant.
2. The sign-in log. In the Microsoft Entra admin center, open the sign-in logs and filter on the account your script uses. The log shows the application that enforced MFA.
3. Your tool versions. Microsoft recommends Azure CLI 2.76 or later and Azure PowerShell 14.3 or later. Older versions return less helpful errors.

Find every user account your automation uses

The failing script you know about is rarely the only one. Search the sign-in logs for user accounts that reach Azure through the Phase 2 tools with single-factor authentication. Microsoft publishes the app IDs:

• Azure CLI: 04b07795-8ddb-461a-bbee-02f9e1bf7b46
• Azure PowerShell: 1950a258-227b-4e31-a9cf-717495945fc2

If you send Entra sign-in logs to a Log Analytics workspace, this KQL query lists the accounts to migrate:

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
| order by SignIns desc

Accounts that sign in at the same time every night, from the same server IP, are your service accounts. No workspace yet? Our Azure Monitor and Log Analytics guide walks through the diagnostic settings.

Pick the right workload identity

Microsoft states that managed identities and service principals aren't affected by either phase. Your choice depends on where the code runs.

Avoid service principals with client secrets where a managed identity or federated credential works. Microsoft labels secret-based sign-in for GitHub Actions as not recommended, and a secret in a script file is one leak away from a compromised subscription.

Migrate a script in five steps

1. Create the identity and grant only what the job needs

Enable a system-assigned managed identity on the VM or Automation account that runs the job, then assign it an Azure RBAC role at the narrowest scope that works. A cleanup job that deallocates VMs in one resource group doesn't need Contributor on the subscription. If you're unsure which role system applies, read Azure RBAC vs Entra ID roles first. Resource access lives in Azure RBAC, not Entra roles.

2. Replace the sign-in line

This is usually the only line that changes. Azure CLI with a managed identity:

# System-assigned managed identity
az login --identity

# User-assigned managed identity (client ID, object ID, or resource ID)
az login --identity --client-id <client-id>

Azure PowerShell with a managed identity:

# System-assigned
Connect-AzAccount -Identity

# User-assigned
Connect-AzAccount -Identity -AccountId <client-id-or-resource-id>

A service principal with a certificate, for servers outside Azure:

# Azure CLI: the PEM file must contain the certificate appended to the private key
az login --service-principal --username <app-id> --certificate /path/to/cert.pem --tenant <tenant-id>

# Azure PowerShell: certificate loaded in the local certificate store
Connect-AzAccount -ServicePrincipal -ApplicationId <app-id> -Tenant <tenant-id> -CertificateThumbprint <thumbprint>

3. Remove password-based code paths

Custom code breaks for a different reason. The Resource Owner Password Credentials (ROPC) flow can't do MFA, so it throws exceptions once MFA applies. Search your repositories for:

• UsernamePasswordCredential in any Azure Identity library. Microsoft deprecated it for .NET, Go, Java, JavaScript, and Python.
• AZURE_USERNAME and AZURE_PASSWORD environment variables used with DefaultAzureCredential or EnvironmentCredential
• AcquireTokenByUsernamePassword or acquire_token_by_username_password in MSAL

Replace them with ManagedIdentityCredential, a certificate credential, or DefaultAzureCredential without the username and password variables.

4. Run the job and check the log

Run the script once by hand on its host. Then open the sign-in logs and filter to service principal sign-ins. You should see the managed identity or app, not a user. If az login --identity fails with no subscriptions found, the identity has no role assignment at a scope that includes a subscription or resource yet.

5. Retire the old account

Disable the user account, wait a full job cycle, then delete it and reclaim its license. To keep Conditional Access control over the new identity, Microsoft offers Conditional Access for workload identities, which needs a Workload Identities license.

Make sure the humans are covered too

Your admins also need MFA before they hit an error. Pick the option your license allows:

• Microsoft Entra ID P1 or P2: create a Conditional Access policy that targets the Microsoft Admin Portals and Windows Azure Service Management API cloud apps and requires the Multifactor authentication strength. Start in report-only mode so you don't lock yourself out. Our Conditional Access step-by-step guide covers policy design and exclusions.
• Microsoft Entra ID Free or Microsoft 365: turn on security defaults.
• Break-glass accounts: they have no exemption. Microsoft recommends passkeys (FIDO2) or certificate-based authentication for them.
• Guest admins: B2B guests must satisfy MFA in your tenant or send MFA claims from their home tenant through cross-tenant access settings. See Entra External ID vs B2B collaboration.

Without Conditional Access licensing, you can still measure the impact with Microsoft's built-in Azure Policy definitions for MFA enforcement. Run them in Audit mode first, then Deny.

What this change doesn't touch

• Read operations through CLI, PowerShell, and the API
• Microsoft Graph API calls, which generally fall outside this enforcement
• Microsoft Entra Connect Sync and Cloud Sync service accounts
• Apps and websites you host on Azure. Your app's owners control their own sign-in rules.

Why this matters for SC-300 and AZ-104

The SC-300 skills outline (updated October 28, 2026) asks you to "select appropriate identities for applications and Azure workloads, including managed identities, service principals, user accounts, and managed service accounts." Expect a scenario where a script fails after MFA rollout and you must choose its replacement identity. The right answer follows the table above: managed identity inside Azure, service principal outside. AZ-104 tests the RBAC half of the same story, which is why the free AZ-104 practice test includes role-scope questions.

Frequently Asked Questions

Can I still postpone Azure mandatory MFA?

No. Microsoft allowed Phase 2 postponement only until July 1, 2026, and there's no opt-out. After enforcement begins, a Global Administrator can ask Microsoft support to lift it temporarily. Treat that as breathing room for the migration, not a fix.

Do managed identities and service principals need MFA?

No. Microsoft states that workload identities, including managed identities and service principals, aren't affected by either phase. Only user identities must complete MFA.

Why does az vm list work but az vm create fails?

Phase 2 enforces MFA on create, update, and delete operations only. Reads pass without MFA, so a user-based script fails at its first write.

Does mandatory MFA apply to test tenants?

Yes. Microsoft requires MFA in every Azure tenant, with no exception for test or lab environments.

What should I use for GitHub Actions deployments?

Use OpenID Connect with a federated identity credential on an app registration or a user-assigned managed identity. GitHub's token is exchanged for a Microsoft Entra token, so you store no secret in the repository.

Sources: Mandatory MFA for Azure and admin portals, Verify users are set up for mandatory MFA, Azure CLI managed identity sign-in, Azure PowerShell non-interactive sign-in, GitHub Actions to Azure, and the SC-300 study guide on Microsoft Learn.