How to Prepare Service Accounts and Automation for Azure Mandatory MFA

Retrospective: this article looks back at events from October 2024, written in 2026 with the benefit of hindsight.

Microsoft's mandatory MFA for Azure breaks automation that signs in as a user with a password. Here is how to find and migrate those service accounts.

Step 1: Find user accounts used for automation

Look for accounts that:

Sign in to Azure Resource Manager, Azure CLI or PowerShell non-interactively.
Have names like svc-, automation, deploy or backup.
Sign in from servers, build agents or fixed IPs.
Have Conditional Access exclusions.

In sign-in logs, filter by application (Azure Portal, Microsoft Azure CLI, Microsoft Azure PowerShell, Windows Azure Service Management API) and look for accounts without MFA.

Step 2: Choose the right workload identity

Running in Azure (VMs, Functions, App Service, Automation, AKS): use a managed identity.
Running in GitHub Actions, Azure DevOps or other CI/CD: use a service principal with workload identity federation (no secrets).
Running on-premises or in other clouds: use a service principal with a certificate, or Azure Arc–enabled servers with managed identity.

Step 3: Grant least-privilege RBAC

Assign only the Azure roles the automation needs, at the narrowest scope (resource group or resource, not subscription).

Step 4: Update scripts

Azure CLI: az login --identity (managed identity) or federated/certificate login for service principals.
Azure PowerShell: Connect-AzAccount -Identity or -ServicePrincipal with certificate.
Terraform and other IaC tools: configure provider authentication for managed identity or OIDC.

Step 5: Retire the user accounts

Disable the old service accounts after verifying automation works, then delete them.

Step 6: Protect break-glass accounts

Verify

Sign-in logs should show no user accounts used for unattended automation against Azure management endpoints.