AADSTS50076 — "Due to a configuration change made by your administrator, you must use multi-factor authentication to access this resource" means your password was accepted and a second factor is required that the app could not collect. This guide covers the interactive fix, the PowerShell and script versions of the problem, and why an MFA exclusion is the wrong answer.
The Error
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 '<resource>'.
Microsoft's internal name for the code is UserStrongAuthClientAuthNRequired, and the documented cause reads: 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.
Your password is not wrong. This error arrives after the password succeeded. The sign-in is incomplete, not rejected.
Why This Happens
Entra ID checks credentials in stages. Password first, then any additional factors a policy requires. AADSTS50076 is the second stage failing — not because you got the code wrong, but usually because the app you are using had no way to ask you for it.
The three documented triggers:
- A Conditional Access policy now requires MFA for that user, app, or condition
- Per-user MFA enforcement was switched on for the account
- A new location — signing in from a network or country that a policy treats differently
The pattern that generates most of these tickets: something worked for years, an administrator enabled MFA, and every non-interactive sign-in broke at once.
Fix 1: Complete the MFA Prompt (Interactive Sign-In)
If you are in a browser or a modern app, this is the whole fix.
- Sign in as normal.
- When the verification prompt appears, approve the notification in Microsoft Authenticator or enter the code.
- If you are asked to trust the device or stay signed in, doing so reduces how often you are challenged.
If no prompt ever appears, the app cannot display one — go to the next section.
If you have never set up MFA, you will see AADSTS50079 instead, or hit a registration wall. Go to aka.ms/mfasetup and register a method first. Until an account has a second factor registered, no app can get past this.
Fix 2: PowerShell and Scripts
This is where AADSTS50076 gets confusing, because the error looks like an account problem and is actually a connection method problem.
The cause: any sign-in that passes a stored username and password has no channel for a verification challenge. Entra ID requires a second factor, the method cannot supply one, and you get AADSTS50076. The same account signs in fine in a browser thirty seconds later, which is what makes it look like a bug.
For interactive admin work, use a connection that opens a real sign-in window:
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com
A browser prompt appears, you complete MFA, and the session connects. What does not work is passing a credential object:
# Fails with AADSTS50076 once MFA is enforced
$cred = Get-Credential
Connect-ExchangeOnline -Credential $cred
The -Credential parameter is only viable for accounts without MFA. Full setup details are in how to install and connect to Exchange Online PowerShell.
On a machine with no browser, PowerShell 7 can authenticate via a second device:
Connect-ExchangeOnline -Device
It prints a code to enter at microsoft.com/devicelogin on your phone, and completes once you have.
Fix 3: Unattended Scripts — Use App-Only Authentication
For scheduled tasks, runbooks, and CI pipelines, there is no interactive prompt to complete, ever. Do not try to make MFA work unattended. Move to app-only authentication.
Certificate-based:
Connect-ExchangeOnline `
-CertificateThumbPrint "ABCD1234567890ABCD1234567890ABCD12345678" `
-AppId "12345678-1234-1234-1234-123456789012" `
-Organization "yourdomain.onmicrosoft.com"
Setup, in order:
- Register an application in Microsoft Entra ID
- Upload a certificate's public key to the app registration
- Install the private key on the machine that runs the script
- Grant the app the Exchange.ManageAsApp API permission and consent to it
- Assign the app an Exchange admin role
On Azure resources, a managed identity removes the certificate entirely:
Connect-ExchangeOnline -ManagedIdentity -Organization "yourdomain.onmicrosoft.com"
Both approaches are more secure than the stored password they replace, because there is no reusable secret sitting in a script for someone to find.
Fix 4: Retire Legacy Clients
An old mail client that only speaks basic authentication cannot carry an MFA challenge, and Microsoft has retired basic authentication across Microsoft 365. There is no setting that brings it back.
The fix is the client, not the configuration: move to Outlook, or to the mail app built into a current mobile OS. If a line-of-business application authenticates with a stored mailbox password, it needs to move to modern authentication or app-only access — that is a vendor conversation, and one worth starting before the tickets arrive.
Admin Side: Should You Change Anything?
Usually not. AADSTS50076 normally means MFA is working as designed and someone is using a method that predates it.
Investigate the policy only when the requirement itself looks wrong — MFA being demanded for a scenario it should not apply to, or every user in a location being challenged unexpectedly.
To see what applied: Microsoft Entra admin center → Monitoring → Sign-in logs, filter to the user and time, open the failed entry, and read the Conditional Access tab. It lists every policy evaluated and which one required MFA. That beats guessing from policy names.
On excluding the account: don't, in almost every case. An MFA exclusion leaves a password-only account, which is precisely the target credential-stuffing attacks look for, and exclusions are rarely reviewed once they exist. For automation, app-only authentication is both safer and more reliable. Reserve exclusions for documented break-glass accounts with stored, monitored credentials.
Requires: Conditional Access Administrator or Global Administrator to change Conditional Access; Authentication Policy Administrator or Global Administrator for per-user MFA settings; an administrator who can register applications and grant consent to set up app-only authentication.
Verify the Fix
- Interactive: sign out completely, sign back in from a private browser window, and confirm the MFA prompt appears and completes.
- PowerShell: after connecting, run
Get-ConnectionInformation— it returns the connection state and tenant, confirming a real session rather than a silent failure. - App-only: run the script under its scheduled task or service account, not just from your own console. A certificate installed in your user store is invisible to the service account that will actually run it — a classic reason "it works on my machine" and fails at 2am.
- Check the sign-in logs for a success entry against the account, which is the authoritative confirmation.
Prevent It Coming Back
- Inventory non-interactive sign-ins before enforcing MFA. Sign-in logs filtered to legacy authentication show you what is about to break, while you still have the option of scheduling it.
- Move automation to app-only authentication first, then enforce MFA on user accounts. Doing it the other way round means an outage.
- Track certificate expiry. App-only authentication fails silently and completely when the certificate lapses, and the resulting error will not mention certificates.
- Register a second MFA method per user. A single method on a lost phone becomes a helpdesk ticket and, briefly, a locked-out user.
- Announce enforcement changes. Most AADSTS50076 tickets are people meeting a new requirement with no warning.
Related Errors
| Code | Meaning | Different because |
|---|---|---|
AADSTS50079 | MFA required but the user has registered no security info | Nothing exists to challenge with — register at aka.ms/mfasetup first |
AADSTS50158 | An external security challenge was not satisfied | Terms of use or a third-party MFA provider, not Entra MFA itself |
AADSTS53003 | Access blocked by Conditional Access | Blocked outright rather than asked for another factor |
AADSTS50105 | The user isn't assigned to a role for the application | Authorization failure, not authentication |