Microsoft's mandatory multifactor authentication programme for Azure has been running in phases since late 2024. Phase 1 covered the interactive portals: the Azure portal, the Microsoft Entra admin center, the Intune admin center, and from February 2025 the Microsoft 365 admin center. Most organizations absorbed that phase without incident, because administrators signing into a browser were already being challenged by Conditional Access in the majority of well-run tenants.
Phase 2 is a different problem. It extends MFA enforcement to Azure CLI, Azure PowerShell, the Azure mobile app, Infrastructure-as-Code tooling, the Azure SDK, and control-plane REST API endpoints. Read operations are exempt. Create, update, and delete operations are not. The enforcement began rolling out on October 1, 2025, and the ability for a Global Administrator to postpone it ends on July 1, 2026.
Why this breaks things that Phase 1 did not
The interactive portals prompt for MFA in a way a human understands. A pipeline does not. When a Phase 2 enforcement hits a non-interactive client, the request returns an error carrying a claims challenge, and some clients surface only the error without ever presenting an authentication prompt. A Terraform apply, an Azure DevOps release stage, a nightly PowerShell maintenance job, or a Bicep deployment running under a user account will simply fail, and the failure message will not obviously say "this account needs MFA."
The scope is deliberately broad. Every user account is in scope: regular users, administrators whether permanently assigned or eligible through Privileged Identity Management, break-glass accounts, student accounts, and B2B guests. Conditional Access exclusions do not exempt an account from the mandate. There is no opt-out mechanism, only postponement of the start date.
What is out of scope
Workload identities are excluded. Managed identities and service principals are not affected, and neither are Microsoft Entra Connect or Cloud Sync service accounts. Read-only operations remain unaffected in Phase 2, as do Microsoft Graph API calls and the sovereign and US Government clouds. This exclusion list is the entire remediation strategy in a single paragraph: the fix is not to make automation do MFA, it is to stop running automation as a person.
The work that actually needs doing
Every organization we assess has at least a handful of user-based service accounts driving deployments, and most have more than the platform team believes. The remediation sequence is consistent. First, inventory: identify every non-interactive sign-in from Azure CLI, Azure PowerShell, or IaC tooling that resolves to a user principal rather than a service principal. Entra sign-in logs filtered by those application IDs give you this in an afternoon. Second, migrate each one to a managed identity where the workload runs inside Azure, or to a service principal with certificate or federated credential authentication where it does not. Third, remove the interactive credentials so nothing silently falls back.
Break-glass accounts need separate treatment. They remain in scope and must be able to complete MFA, which in practice means FIDO2 passkeys or certificate-based authentication stored under the same physical controls as the credentials themselves. An emergency account that cannot authenticate during an emergency is not an emergency account.
Finally, tooling versions matter. Microsoft's guidance calls for Azure CLI 2.76 or later and Azure PowerShell 14.3 or later to handle the claims challenge correctly. Older versions in build agents and golden images are a common cause of failures that look like MFA problems but are actually client problems.
Postponement is a scheduling tool, not a solution
A Global Administrator can still set a later start date at the postponement portal, and postponing Phase 1 automatically postpones Phase 2 to the same date. That capability disappears on July 1. After enforcement begins, changing the date requires a support request submitted by a Global Administrator, which is a slower and less certain path than doing the inventory now.
Our recommendation is to use the remaining window to complete the migration rather than to buy more time. The work is bounded, it is a security improvement regardless of the mandate, and it removes an entire class of credential from your environment.
How Lorexus engages
We run the sign-in log analysis, produce the inventory of user-backed automation, and migrate each workload to a managed identity or federated service principal in priority order. Where a postponement is genuinely needed to protect a release cycle, we file it and work to the new date. Book a free 15-minute call and we will tell you within the call whether your tenant has exposure.