Mandatory MFA for Azure and admin portals: fix scripts, service accounts and break-glass accounts

Microsoft now requires multifactor authentication for every user account that signs in to the Azure portal, Microsoft Entra admin center, Intune admin center and Microsoft 365 admin center, and for any user account that creates, updates or deletes Azure resources through Azure CLI, Azure PowerShell, REST or infrastructure-as-code tools. Tenants could postpone the second phase only until 1 July 2026, so by now enforcement is on everywhere in the public cloud. In this post I'll go through the failures this produces, why they happen, how to move automation to workload identities, how to make break-glass accounts MFA-capable, and how to verify you're ready.

Symptoms#

• A scheduled script that signs in to Azure with a username and password (or a stored user credential) starts failing: Azure PowerShell and Azure CLI return an error saying MFA is required, sometimes with a claims challenge, when the script tries to create, update or delete something. Reads keep working.
• Admins who never registered an MFA method are prompted to set one up when opening the Azure portal, Entra admin center, Intune admin center or Microsoft 365 admin center, even though you excluded them from your Conditional Access policies.
• Apps using the ROPC flow (AcquireTokenByUsernamePassword in MSAL, or UsernamePasswordCredential and DefaultAzureCredential with AZURE_USERNAME and AZURE_PASSWORD in the Azure Identity libraries) throw exceptions.
• Your break-glass account, deliberately kept outside MFA, can't complete a sign-in to the portals.
• Sign-in logs show the application itself (for example the Azure portal) as the source of the MFA requirement rather than one of your policies.

Why it happens#

Microsoft enforces MFA on the application and resource side, independently of your Conditional Access configuration, in two phases:

A few consequences follow. It applies to every user account, including students, guests, break-glass accounts and accounts with active or eligible roles, and your Conditional Access exclusions don't exempt anyone; stronger policies you already have (such as phishing-resistant MFA for admins) stay in force. Workload identities, meaning managed identities and service principals, aren't affected, nor is the Microsoft Entra Connect or Cloud Sync service account, and Microsoft Graph calls are generally out of scope because only management.azure.com is enforced. Phase 2 apps let a user sign in without MFA and only error on the first write, and some clients merely surface the error rather than prompting, which is why Microsoft recommends a Conditional Access policy or security defaults so users satisfy MFA up front. ROPC is incompatible with MFA by design, which is why the username and password APIs fail. There is no opt-out: the postponement windows (Phase 1 to 30 September 2025, Phase 2 to 1 July 2026) have closed, and after enforcement only a Global Administrator can ask Microsoft Support to lift it temporarily.

How to fix it#

1. Find user accounts acting as service accounts#

Filter the sign-in logs by the application IDs above and look for accounts with scheduled, repetitive patterns or sign-ins from servers. Microsoft's verification guidance also suggests exporting users and their authentication methods with PowerShell, and using the Conditional Access insights and reporting workbook against a report-only policy (step 3) to count who would be prompted.

2. Move automation to workload identities#

Prefer a managed identity wherever the script runs on Azure (Automation, Functions, a VM, or a pipeline using workload identity federation); use a service principal with a certificate when it runs elsewhere, and avoid client secrets. Grant least-privilege Azure RBAC or Graph application permissions, then change the sign-in lines:

# Azure PowerShell on an Azure resource with a system-assigned managed identity
Connect-AzAccount -Identity

# Azure PowerShell from a server: service principal with a certificate
Connect-AzAccount -ServicePrincipal -ApplicationId $appId -TenantId $tenantId -CertificateThumbprint $thumbprint

# Microsoft Graph PowerShell SDK, app-only
Connect-MgGraph -ClientId $appId -TenantId $tenantId -CertificateThumbprint $thumbprint
Connect-MgGraph -Identity   # when running under a managed identity

az login --identity

If a Conditional Access policy targeted the old user-based service account, reclaim its licence and consider a workload identities licence to apply Conditional Access to the service principal instead. Update Azure CLI to 2.76 or later and Azure PowerShell to 14.3 or later on admin workstations; older versions produce confusing errors instead of a clean step-up.

3. Give every admin an MFA method#

With Microsoft Entra ID P1 or P2, create a Conditional Access policy that includes the users who use these tools, targets Microsoft Admin Portals and Windows Azure Service Management API, and grants access with the Multifactor authentication authentication strength. Create it in report-only mode first, read the impact, then turn it on. Without P1, enable security defaults, or per-user MFA as a fallback. If MFA comes from a federated identity provider, the IdP must send the multipleauthn claim; third-party MFA must be integrated as an external authentication method, because the legacy custom controls preview doesn't satisfy the requirement.

4. Make break-glass accounts MFA-capable#

Microsoft's recommendation is passkeys (FIDO2) or certificate-based authentication, both of which satisfy the requirement without depending on a phone or the Authenticator app. For passkeys: enable the Passkey (FIDO2) method in the Authentication methods policy for the emergency accounts' group, register two hardware keys per account, store them in separate secure locations and document the PINs with the same care as the password. For certificate-based authentication: configure the certificate authorities and set the authentication binding so the certificate counts as multifactor. Keep the accounts excluded from your own Conditional Access policies as before; the exclusion doesn't bypass Microsoft's enforcement, it just protects you from your own policy mistakes.

Verify the fix#

• Run the migrated script and check Get-AzContext: the account type should be a service principal or managed identity, not a user. In the sign-in logs, the activity appears under Service principal sign-ins or Managed identity sign-ins, not user sign-ins.
• Sign in to the Azure portal as a Global Administrator and browse to https://aka.ms/managemfaforazure and https://aka.ms/postponePhase2MFA: each page shows a banner confirming that enforcement began for your tenant.
• Sign in with each break-glass account using the passkey or certificate on a quarterly schedule and confirm the sign-in log shows the MFA requirement satisfied.
• If you can't use Conditional Access, assign Microsoft's built-in Azure Policy definitions for MFA self-enforcement in Audit mode to see non-compliant requests before switching to Deny.

Key takeaways#

• User identities are not for automation. Every scheduled task should run as a managed identity or a certificate-based service principal.
• Exclusions in your Conditional Access policies don't exempt anyone from Microsoft's enforcement; what they still do is protect against lockouts caused by your own policies.
• Break-glass accounts must be able to do MFA: FIDO2 passkeys or certificate-based authentication, tested regularly.
• Enforcement is public-cloud only today, applies to test tenants too, and can't be opted out of; only a temporary lift through support is possible.

References#

• Plan for mandatory Microsoft Entra multifactor authentication
• Verify that users are set up for mandatory MFA