When az login fails with AADSTS50076, your password was correct. Microsoft Entra ID accepted the first factor and then refused to issue a token because a multifactor authentication requirement was not satisfied.
AADSTS50076: Due to a configuration change made by your administrator, or because
you moved to a new location, you must use multi-factor authentication to access
'797f4846-ba00-4fd7-ba43-dac1f8f63013'.
The Microsoft Entra error reference documents the code as UserStrongAuthClientAuthNRequired:
Due to a configuration change made by the admin such as a Conditional Access policy, per-user enforcement, or because you moved to a new location, the user must use multifactor authentication to access the resource. Retry with a new authorize request for the resource.
The GUID in the message is the resource you were trying to reach — 797f4846-ba00-4fd7-ba43-dac1f8f63013 is the Azure management API, which is why this shows up during az login.
Why This Happens
Three configurations produce it, and the error text names all three:
- A Conditional Access policy requires MFA for this user, this application, this device state, or this network location.
- Per-user MFA enforcement is switched on for the account in the legacy per-user MFA settings.
- Security defaults are enabled on the tenant, which requires MFA for administrative operations.
The trigger is often environmental rather than a change to your account. Signing in from home instead of a trusted office network, from a new country, or through a VPN that egresses somewhere unexpected can all satisfy a location condition that normally never fires. That is what "because you moved to a new location" refers to.
This is a security control functioning correctly. The right fix is to satisfy it, not to remove it.
Fix 1: Use an Interactive Sign-In (Human Users)
An MFA challenge needs somewhere to appear. Let the CLI open a browser:
az login
On a headless machine — a server, a container, an SSH session — use the device code flow so you can complete the prompt on a phone or laptop:
az login --use-device-code
If your account exists in more than one tenant, name the one the policy applies to:
az login --tenant contoso.onmicrosoft.com
Then confirm:
az account show
Fix 2: Stop Using a User Account for Automation
If AADSTS50076 appears in a pipeline, a scheduled job, or a script, the real problem is that a human identity is being used for machine work. Non-interactive flows — including username and password authentication — cannot present an MFA challenge, so they fail at this point by design. No amount of retrying will change that.
Use an identity that is not a person:
Managed identity — the best option when the workload runs in Azure. There is no secret to store or rotate:
az login --identity
Service principal with a certificate — for workloads outside Azure:
az login --service-principal \
--username <app-id> \
--tenant <tenant-id> \
--password /path/to/cert.pem
Application identities using the client credentials flow are not subject to user MFA policies, so this resolves the error properly rather than working around it. Certificates are preferable to client secrets: they are harder to exfiltrate and they support longer, better-controlled lifecycles. Whichever you choose, pair it with a rotation routine — our service principal credential rotation guide covers doing it without downtime.
Grant the new identity only the roles it needs on only the scopes it needs. A service principal created to run one deployment does not need Owner on the subscription.
Fix 3: Register an MFA Method (If You Have None)
If you have never enrolled an authentication method, you may see the closely related AADSTS50079 instead, which Microsoft documents as UserStrongAuthEnrollmentRequired. Enrol at https://aka.ms/mfasetup, then retry the sign-in. Prefer an authenticator app or a FIDO2 security key over SMS, which is vulnerable to SIM-swap attacks.
What Not to Do
- Do not disable MFA for the account. It resolves one script and removes the strongest protection that account has, permanently.
- Do not create a standing Conditional Access exclusion for a user or service account to unblock a job. Exclusions are quiet, they outlive the problem that motivated them, and excluded accounts are exactly what attackers look for.
- Do not switch off security defaults to work around a single failure. If the tenant genuinely needs granular control, replace security defaults with properly scoped Conditional Access policies — not with nothing.
If a break-glass account genuinely needs an exclusion, that is a deliberate, documented, monitored decision with alerting on its use — not a troubleshooting step. Our global administrator best practices guide covers how to handle those accounts.
Find the Exact Policy Responsible
Stop guessing and read the log:
- Open the Microsoft Entra admin centre.
- Go to Monitoring → Sign-in logs.
- Find the failed sign-in — filter by user and time.
- Open it and select the Conditional Access tab.
That tab lists every policy evaluated for the attempt and which ones applied. It is the authoritative answer, and it usually takes less time than any amount of reasoning about policy names.
Verify the Fix
az account show
az account get-access-token --query expiresOn -o tsv
A subscription and a token expiry timestamp confirm authentication succeeded and the MFA claim was accepted. For a service principal, also confirm it can perform real work at its intended scope rather than only sign in — sign-in success and sufficient role assignment are separate things.
Prevent It From Recurring
- Separate human and machine identities. Every automated job should run as a managed identity or service principal from day one.
- Enrol phishing-resistant MFA methods for administrators — FIDO2 keys or Windows Hello for Business rather than SMS.
- Review Conditional Access with report-only mode before enforcing, so you see what a new policy would break before it breaks it.
- Audit exclusions on a schedule. Every exclusion should have an owner, a reason, and an expiry date.
- Alert on break-glass account sign-ins so their use is always noticed.