Azure mandatory MFA now blocks CLI, PowerShell and Terraform changes: moving service accounts to workload identities

Azure is turning on a rule, tenant by tenant, that wants MFA before a user account can create, change or delete anything through the CLI, PowerShell, Terraform, the SDKs or the REST API. If any script or pipeline still signs in as a person with a password, it will fail the next time it tries to deploy. Move it to a managed identity or a federated workload identity. This guide shows how to find those accounts, which option fits each one, and what tends to go wrong during the move.

Microsoft rolled the rule out in two phases. Phase 1 covered the Azure portal and the admin centres. Phase 2 covers everything else that manages Azure: the Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, the SDKs and the REST API. Microsoft rolls it out tenant by tenant, and the latest date anyone could postpone to has already passed. There's no opt-out, and test tenants aren't exempt.

The business risk is mostly an outage you didn't plan. A nightly job that scales a cluster, a release pipeline, a cost script that deletes old snapshots: each one keeps working until the day it tries to write, and then it stops. Reading still works, so dashboards and inventory scripts look healthy while the deploys behind them fail. Often the first sign is a failed release.

There's a security side too. A user account with a stored password and no MFA is exactly the kind of credential attackers go looking for in old repos and build logs. Microsoft says its research shows MFA blocks more than 99.2% of account compromise attacks, and it says student, break-glass, admin and excluded accounts all carry the same risk if compromised, so it makes no exceptions for them. Moving them off passwords closes a gap you probably already had.

For engineers: Azure checks this on the ARM side. Upgrading the CLI gives you a clearer message and the same block. Microsoft enforces Phase 2 by deploying the same built-in Azure Policy definitions you can assign yourself, so you can run the block in your own test window first. Microsoft Graph calls are generally out of scope, because only requests to management.azure.com are checked.

The change that bites hardest is the password flow. Its proper name is the Resource Owner Password Credentials grant, ROPCdefinitionResource Owner Password Credentials: a sign-in where a script sends a username and password straight to Entra ID. It can never pass MFA, so its writes to Azure now fail, and the sign-in fails too where Entra demands MFA. for short, and it's what runs whenever a script hands Entra ID a username and password directly. ROPC can't do MFA at all. Under Phase 2 alone, the password sign-in still works and the first write fails at ARM. If the account is also under an Entra MFA requirement, such as Conditional Access, security defaults or per-user MFA, the sign-in itself fails. In PowerShell that shows up as "UsernamePasswordCredential authentication failed" with a 400 BadRequest.

Watch for the quiet version of the same thing in application code. DefaultAzureCredential and EnvironmentCredential will try a username and password if AZURE_USERNAME and AZURE_PASSWORD are set in the environment. Check your build agents for those variables. They're easy to forget after an old setup.

Each account that runs automation needs one decision. Most of them land on a managed identity or a federated identity, and a few stay as people who sign in properly. Pick by where the job runs, not by what's quickest to type.

One case comes up a lot. Some teams use a single user account that manages on-premises Active Directory and Azure from the same script, and they say a service principal can't reach AD. On Microsoft's Q&A forum, a Microsoft employee answered that the rule only bites when that account signs in to one of the listed Azure tools. It's usually simplest to split the script, so the AD half keeps its own account and the Azure half moves to a managed identity on the same server.

• Every user account that touched the Azure CLI or PowerShell in the past 30 days is on a list, with an owner who'll pick up the phone when it breaks.
• Next to each account you've written down what actually uses it. A person, a job on Azure, a pipeline or a script on a server elsewhere each get a different fix.
• Break-glass accounts have a passkey or certificate sign-in, and someone has actually tried it. Find out now, not during an outage.
• Your CLI is at 2.76 or later and Az PowerShell at 14.3 or later on build agents.
• No build agent has AZURE_USERNAME or AZURE_PASSWORD set. Those two make the SDK try a password sign-in.
• You've assigned the built-in MFA policies in Audit mode and read the Activity Log for a week.
• Someone can roll back a pipeline change in minutes if a new identity is missing a role.

Start with the sign-in logs. If you send them to Log Analytics, the query below lists user accounts that signed in to the Azure CLI or PowerShell without MFA. The AuthenticationProtocol column is the useful one: a value of ropc means a script is handing over a password directly, and that sign-in can never satisfy MFA.

// example: user sign-ins without MFA
union SigninLogs,
  AADNonInteractiveUserSignInLogs
| 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,
  AuthenticationProtocol
| order by SignIns desc
// example output
svc-deploy   Azure CLI    ropc   142
ops-backup   Azure PS     none    30

# example: azurerm with a federated token
provider "azurerm" {
  features {}
  use_oidc        = true
  client_id       = var.client_id
  tenant_id       = var.tenant_id
  subscription_id = var.subscription_id
}
# Azure DevOps pipelines also set:
ARM_USE_OIDC=true
ARM_ADO_PIPELINE_SERVICE_CONNECTION_ID=<id>

We start from your sign-in logs and go through the list with you, account by account. Each one ends up as a person with MFA, a managed identity, a federated identity or a certificate. We move the pipelines in an order that keeps releases going, and every new identity gets an owner and a review date. Our Microsoft Entra ID page covers the wider identity work, the Terraform page covers pipelines, and you can bring in engineers for the migration itself. If you want a second opinion first, ask for an assessment.