Azure CLI: "Resource was disallowed by policy. Reasons: MFA is required"

The message “Resource was disallowed by policy. Reasons: MFA is required” means Azure Resource Manager refused a create, update or delete because the user account behind the call did not sign in with multifactor authentication. Fix it by signing in again with MFA (on Azure CLI 2.76 or later and Azure PowerShell 14.3 or later, the error text contains the exact command), and move any scripts that run as a user account to a service principal or managed identity.

What does “Resource was disallowed by policy. Reasons: MFA is required” mean?

Microsoft’s Azure CLI troubleshooting page lists these messages (Azure CLI 2.75.0 or earlier):

• “Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication. Interactive authentication is needed.”
• “Resource was disallowed by policy. Reasons: MFA is required. See error details for policy resource IDs. RequestDisallowedByPolicy Message: Resource policy resource IDs was disallowed by policy. Reasons: MFA is required.”
• “Unauthorized. RequestDisallowedByPolicy. Resource was disallowed by policy. Reasons: MFA is required. See error details for policy resource IDs. MFA is required. Users must authenticate with multi-factor authentication to create or update resources.”

For Azure CLI 2.76.0 or later, the same page shows a longer message that begins with “Run the command below to authenticate interactively” and includes “(RequestDisallowedByPolicy) Resource was disallowed by policy.” and a line telling the user to authenticate with multifactor authentication to create or update resources

Azure PowerShell (Az 14.3.0 and Az.Accounts 5.2.0 or later) prints a message that includes “Resource was disallowed by policy. Users must use MFA for Create operation. Users must authenticate with multi-factor authentication to create or update resources.” and then the cmdlet to run (shown below)

Microsoft describes what happens behind it: users who sign in without MFA can use the tool, but when they try to create, update or delete a resource, “the app returns an error that says they need to sign in with MFA and a claims challenge.” Some clients use the claims challenge to prompt for MFA, and others return only the error.

Interpretation (not stated by Microsoft in these words): the sign-in itself worked. The refusal comes when Azure Resource Manager sees a token without an MFA claim on a write request.

Which tools and operations are affected, and since when?

Microsoft’s mandatory MFA page splits the rollout into two phases.

Phase 1: since October 2024, MFA is required to sign in to the Azure portal, Microsoft Entra admin center and Microsoft Intune admin center for any create, read, update or delete operation. Microsoft states that Phase 1 “won’t impact other Azure clients such as Azure CLI, Azure PowerShell, Azure mobile app, or IaC tools.”

Phase 2: “Starting October 1, 2025, MFA enforcement will gradually begin for accounts that sign in to Azure CLI, Azure PowerShell, Azure mobile app, IaC tools, and REST API endpoints to perform any Create, Update, or Delete operation. Read operations won’t require MFA.” The page lists Azure CLI (04b07795-8ddb-461a-bbee-02f9e1bf7b46) and Azure PowerShell (1950a258-227b-4e31-a9cf-717495945fc2) by app ID. IaC tools use the Azure CLI or Azure PowerShell IDs.

The FAQ adds that enforcement is on the Azure Resource Manager server side: “any requests that target https://management.azure.com are under scope of enforcement.” Microsoft Graph is generally not in scope.

Who is covered, per Microsoft:

• All user accounts, including break-glass accounts, administrators with activated or eligible roles, and accounts with Conditional Access exclusions.
• Guests, who must satisfy MFA in the resource tenant or through MFA claims from the home tenant (cross-tenant access).
• Test tenants. Only the public Azure cloud is enforced. Microsoft says it does not currently enforce MFA for US Government or other sovereign clouds.
• Not covered: “Workload identities, such as managed identities and service principals.”

Postponement: Microsoft allowed customers with complex environments or technical barriers to postpone Phase 2 until July 1, 2026, using https://aka.ms/postponePhase2MFA. If you postponed Phase 1, Phase 2 moved to the same date unless you chose a later one. After enforcement begins, a Global Administrator can submit a request to Microsoft Help and Support to temporarily lift it. The page also says: “There’s no way to opt out.”

Interpretation: the latest postponement date Microsoft documents, July 1, 2026, has passed (checked on 25 October 2026). Check the banner on the Phase 2 page (see the checklist) for your tenant’s actual state.

How do I fix it for a person?

Microsoft’s documented resolution options for Azure CLI and Azure PowerShell are the same two:

1. Ask the Azure administrator to enforce MFA at sign-in, for example with a Conditional Access policy. Microsoft says this lets the session meet the requirement without extra steps.
2. If that isn’t possible, authenticate interactively with the claims challenge. The error message supplies the values. For Azure CLI:

az logout
az login --tenant "<tenant-id>" --scope "https://management.core.windows.net//.default" --claims-challenge "<claims-challenge-token>"

For Azure PowerShell:

Connect-AzAccount -Tenant (Get-AzContext).Tenant.Id -ClaimsChallenge "<claims-challenge-token>"

Notes from Microsoft’s pages:

• Microsoft recommends Azure CLI 2.76 or later and Azure PowerShell 14.3 or later, for more informative errors and policy details.
• Older Azure PowerShell versions (Az 14.2.0 or earlier) show “SharedTokenCacheCredential authentication unavailable” instead. Upgrading gives the clearer message.
• If PowerShell signs in to the wrong tenant first, specify -TenantId explicitly. Microsoft documents a cross-tenant warning that points to this.
• Microsoft recommends passkey (FIDO2) or certificate-based authentication for break-glass accounts. Both satisfy the MFA requirement.

If the person is prompted for MFA and the sign-in itself fails, those are different errors: see AADSTS50076 (MFA required) and AADSTS50079 (user must register for MFA). A Conditional Access block is a different problem: AADSTS53003.

How do I fix it for automation?

Microsoft states: “If user identities are used to sign in as a service account to run automation (including scripts or other automated tasks), those user identities need to sign in with MFA once enforcement begins. User identities aren’t recommended for automation. You should migrate those user identities to workload identities.” Automation accounts are “not in scope as long as they use a managed identity or service principal.”

What Microsoft documents as the replacement:

• Managed identity for code running in Azure. Microsoft’s passwordless overview calls managed identities with Azure RBAC the recommended option for secure, passwordless connections, and says you don’t provision or rotate secrets.
• Service principal for scripts elsewhere. Microsoft: “Authenticating with a service principal is the best way to write secure scripts or programs.” Azure CLI examples from that page:

az login --service-principal --username APP_ID --password CLIENT_SECRET --tenant TENANT_ID
az login --service-principal --username APP_ID --certificate /path/to/cert.pem --tenant TENANT_ID

• Workload identity federation for pipelines such as GitHub Actions. Microsoft: it lets you “configure a user-assigned managed identity or app registration in Microsoft Entra ID to trust tokens from an external identity provider” and removes “the risk of leaking secrets or having certificates expire.”

Whichever you pick, the identity needs an Azure role assignment on the scope you deploy to. That is general Azure RBAC and not specific to this change; this page does not cover it.

Username and password scripts will not work. Microsoft: “The OAuth 2.0 Resource Owner Password Credentials (ROPC) token grant flow is incompatible with MFA.” Affected examples listed by Microsoft:

• Connect-AzAccount -Credential $Credential, which fails with a UsernamePasswordCredential authentication failed … 400 (BadRequest) message.
• Azure.Identity UsernamePasswordCredential, or DefaultAzureCredential / EnvironmentCredential with AZURE_USERNAME and AZURE_PASSWORD set.
• MSAL.NET AcquireTokenByUsernamePassword, deprecated as of 4.74.0.

If you switch to a service principal secret and later see an invalid secret error, that is AADSTS7000215.

For a managed identity, Microsoft’s mandatory MFA page links to Sign in to Azure with a managed identity using the Azure CLI, which shows az login --identity for a system-assigned identity and az login --identity --client-id <client_id> (or --object-id / --resource-id) for a user-assigned one. A federated-token az login command is not documented on the pages read for this guide, so take it from Microsoft’s workload identity page for your platform.

How do I see it in my logs?

Microsoft says only that “Microsoft Entra ID sign-in logs show the application that enforced MFA as the source of the MFA requirement.” The MFA reporting page documents the Conditional Access and Authentication Details tabs of the sign-in event. It does not name a column that identifies the enforcing application, and it warns not to rely only on authenticationRequirement, because it ignores previously satisfied MFA claims.

I could not find documentation of a sign-in log row for the Resource Manager refusal itself. Interpretation: because the refusal appears to come from Azure Resource Manager on the write request, it may not appear as a failed sign-in at all. Check the Azure Activity Log for the failed operation. I have not verified how it is recorded.

What you can do with documented columns is find user sign-ins by the two Phase 2 clients that matter most for scripts (Azure CLI and Azure PowerShell; Phase 2 also covers the Azure mobile app and REST API clients, which this query does not). This query is untested, and the AuthenticationRequirement value should be checked against your own rows:

// UNTESTED: sign-ins by Azure CLI / Azure PowerShell that were single factor
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where AppId in ("04b07795-8ddb-461a-bbee-02f9e1bf7b46", "1950a258-227b-4e31-a9cf-717495945fc2")
| where ResultType == "0"
| summarize Rows = count(), LastSeen = max(TimeGenerated)
    by UserPrincipalName, AppDisplayName, AuthenticationRequirement
| sort by Rows desc

Users listed with a single-factor requirement are candidates only, not proof: Microsoft says some sign-ins can appear as single factor despite an MFA requirement and that the authenticationRequirement field doesn’t account for previously satisfied MFA claims, so a user showing multifactor can still hit the error if the token wasn’t refreshed. Scripts running as a user account usually appear as the same user every night (interpretation).

Checklist

1. Check your tenant: as Global Administrator open https://aka.ms/postponePhase2MFA and look for the banner that Phase 2 enforcement began.
2. Update Azure CLI to 2.76 or later and Azure PowerShell to 14.3 or later.
3. Create a Conditional Access policy that requires MFA for Azure management, or enable security defaults if you lack Entra ID P1. Microsoft says existing exclusions no longer apply for this enforcement, and stricter policies such as phishing-resistant MFA stay enforced.
4. List scripts, pipelines and IaC runs that sign in with a user name and password, and move each to a managed identity, service principal or workload identity federation.
5. Replace break-glass sign-in with passkey (FIDO2) or certificate-based authentication.
6. Run the sign-in query above and fix the accounts it lists.

What can’t this page tell me?

• Whether and how the refusal shows in your sign-in or activity logs. Microsoft’s pages don’t document it.
• Which of your tenants Microsoft has already enforced, or when. Use the banner on the Phase 2 page.
• Exact error wording for your tool version. It changes between versions, and the text above is copied from Microsoft’s pages at the time of writing.
• How third-party IaC tools obtain tokens. Microsoft says they use the Azure CLI or PowerShell app IDs, but not each tool’s behaviour.

The queries and the reading of the logs are based on Microsoft’s documentation and have not been reproduced in a lab tenant yet. Until they have, the page is marked as lab test pending.