October has turned things upside down for a lot of Azure admins. Azure MFA phase 2 is rolling out across tenants, and many are feeling it right away. In several environments I work with, pipelines and scripts that used to run without a hitch are now failing. Sometimes they fail silently, sometimes the build logs show a plain MFA prompt. The cause is simple. Any create, update or delete operation through Azure CLI, Azure PowerShell, the mobile app, the REST API or your infrastructure-as-code tool of choice (Bicep or Terraform, for example, when they use user credentials) now requires multi-factor authentication. Read-only operations still work without MFA, but anything that changes resources falls under the new rule. This comes after the admin portal enforcement in phase 1 (see Azure mandatory MFA enforcement: Phase 1 hits admin portals). Microsoft is enforcing phase 2 gradually, tenant by tenant, and there's a postponement option in the Azure portal if you have complex dependencies. Still, every tenant will get there eventually.
Phase 2 enforces MFA on every ARM create, update and delete call
This wave covers all create, update and delete calls against the Azure Resource Manager API. In practice that means Azure CLI, supported Azure PowerShell versions, the mobile app, direct REST API calls, and any automation or infrastructure-as-code tool that signs in as a user account. Scripts and pipelines running under user identities now fail unless someone is around to answer the interactive MFA prompt. For most scheduled jobs and CI/CD runs that depend on user tokens, that's the end of the road. If you need more time to migrate, the portal has a postponement button, but enforcement is where this is heading for everyone.
User accounts in automation are usually the culprit
In my experience, plenty of organizations still have automation, older deployments or maintenance scripts that authenticate as individual users or generic service accounts. Often there's no real reason behind it. The scripts have always worked that way, and nobody wanted to take on the migration. With Azure MFA phase 2, this goes from risky to simply broken. The nasty part is that many admins only notice when resources quietly stop deploying or updating, or when pipelines start throwing authentication errors. Every pipeline that runs Azure CLI or PowerShell with user credentials is affected.
Practical tip: Check your Entra sign-in logs (Microsoft Entra admin center → Monitoring → Sign-in logs) for automation that uses user tokens. Filter for "Application" = Azure PowerShell or Azure CLI, and "Client app" = Public client or User interactive. That shows you fairly quickly which accounts are running scripts or pipelines as users.
Managed identities and workload identity federation fix the problem
To get your automation working again, you have to move scripts and pipelines over to service principals, managed identities or, for cloud-native setups, workload identity federation. Managed identities let Azure VMs, functions and other services authenticate without any stored credentials (more in Workload identities in Entra ID: Managed identities, app registrations and securing your applications). If you automate with GitHub Actions or Azure DevOps, you'll want workload identity federation, which gives you secure, passwordless access over OIDC (Microsoft docs).
Here's a short example of switching a script from user login to managed identity (Azure PowerShell 9+ on a VM with a system-assigned identity):
# Old method: user account login (now triggers MFA)
Connect-AzAccount -UserName "[email protected]"
# New method: system-assigned managed identity
Connect-AzAccount -Identity
If you use Terraform or Bicep, your pipelines need to move to service principals or managed identities as well, and your tooling has to support the current authentication flows.
The sign-in logs reveal which automations will break
In large, grown environments, finding every affected automation takes real effort. Your best source is the Entra sign-in log, since it records every authentication attempt. These steps in the Microsoft Entra admin portal turn up user-based CLI and PowerShell logins:
- Go to Monitoring → Sign-in logs
- Filter "Application" to Azure PowerShell or Azure CLI
- Filter "Client app" to Public client or User interactive
- Set the date range to the last 30 days
Any script or pipeline that shows up here with a user token should go to the top of your list for migration to a service principal or managed identity. Also look at the authentication settings in your CI/CD systems (Azure DevOps, GitHub Actions). The fix there is often quick, and it matters a lot.
The migration hurts, but security comes out ahead
I'm glad Azure MFA phase 2 is here, even though it means some migration work in the short term. Far too many environments have used user accounts for automation just because it was easy. Moving to managed identities or workload identity federation will lift the security baseline across Azure. The pressure to migrate is real, I know. But a compromised account or missing MFA is a much bigger problem. For triage, the Entra sign-in log is the place to start. Once you've migrated, your deployments will run normally again, and this time they'll actually be covered by MFA.
The flowchart below shows the path from user-based automation to managed or federated identities, with the problem and the fix side by side:
flowchart TD
UserScript["Automation with user account"] --> MFAFail["MFA required: fails"]
UserScript -->|"Migration needed"| Mitigation["Service principal/Managed identity"]
Mitigation --> ARM["Authenticate without MFA"]
WorkloadFed["Workload identity federation (OIDC)"] --> ARM
Figure: Moving user-based scripts to managed or federated identities for ARM operations.
If you'd like more detail on why workload identity federation has become so important, read my post Replace client secrets in Entra ID: safer alternatives. For phase 1 and the background, see the earlier post on Azure mandatory MFA. I'll keep writing about what Azure admins need to know as enforcement gets stricter.
