AADSTS50076: restore protected sign-in

Draft for review

Source review: September 15, 2026. Tenant validation pending.

Page tools and document details

Start here

A request for MFA is not a compromise verdict

AADSTS50076 means the resource requires multifactor authentication. It can follow a policy change, per-user enforcement or a different sign-in context. The code alone does not identify the cause.

Confirm the attempt was yoursIf you did not initiate it, do not approve the prompt. Follow Suspicious Sign-ins and report the exact time.
Keep the error detailsRecord the app, intended resource, account, error code, timestamp and correlation/request IDs. Keep secrets and tokens out of the ticket.
Start one fresh interactive sign-inOpen the known application directly, choose the correct work account and complete its approved MFA method. Check whether the original action now works.

Do not disable MFA or exclude a user from every policy to make the error disappear. A blocked prompt may be the expected protection.

Know which part you can change

User: You can retry your own expected sign-in. Use your helpdesk if you cannot use an approved authentication method.
Administrator: Use an authorized reader role such as Reports Reader for sign-in investigation. Policy changes need the relevant administrator role and a scoped change plan.
Licensing: Security defaults and per-user MFA can also produce MFA requirements. Standard Conditional Access needs Entra ID P1; risk conditions need P2. Seeing this code does not establish a need to buy a license.

This guide covers an expected work or school user sign-in. An unattended integration that relies on a user's password needs application-owner review; repeatedly retrying a password flow cannot satisfy an interactive MFA challenge.

Find the event and the requirement

In the Microsoft Entra admin center, open Entra ID → Monitoring & health → Sign-in logs. Confirm the tenant and filter to the user and captured time.
Open the matching event. Compare its application and resource with the user's action; a downstream resource can require a different control.
Read Basic info, Authentication Details and Conditional Access. Note the error, MFA result and which policies actually applied. A report-only policy records an evaluation without enforcing it.
If the event is missing, check the other user sign-in tab, UTC/time-zone conversion and available retention. Record a coverage gap instead of declaring the account safe.

Choose the next step
Observed result	Next action
The fresh sign-in and original action work	Record an expected MFA challenge and perform the verification below.
The user cannot complete a recognized MFA challenge	Verify their identity through the helpdesk's approved process, then repair the specific method or registration. Do not ask for their current OTP.
Browser access works, but one client or integration fails	Check that client's interactive authentication and claims-challenge handling with its owner.
A configured device, location or authentication-strength requirement is unsatisfied	Use the approved device or method. Have the policy owner review an incorrect assignment or configuration.
The user denies the activity or the evidence conflicts	Use the suspicious-sign-in workflow; keep unresolved evidence explicit.

Repair the specific sign-in path

For an expected user session, authenticate again in the affected app and repeat the failed operation. An application developer must handle an interaction-required response and send the user through a supported interactive flow for the required resource. Repeating silent token requests is not a resolution.

For a broken Power Automate connection, confirm the connector resource and its Conditional Access requirements before repairing or recreating the connection under an approved account and device. Preserve the connection references and affected flows first, then test a representative flow run.

Only change a policy after the owner identifies an incorrect configuration. Save its prior settings, scope the correction and arrange a rollback. A broad MFA exclusion creates a separate security change and is outside this troubleshooting fix.

Verify the resource, not just the login screen

Repeat the original actionThe same user can use the intended resource from the approved client and device.
Check the new eventMatch the time, app and resource. Confirm the required authentication was satisfied and the intended controls still apply.
Record the outcomeCapture the cause, exact fix and test time. If it fails again, stop repeated resets and hand the evidence to the identity or application owner.

If a scoped policy change causes a regression, its authorized owner restores the saved configuration and investigates. Do not undo MFA protection as an informal rollback.

Prepare a useful support handoff

Keep the full evidence in your organization's approved system. Start an external enquiry with a redacted summary; agree a secure channel before sharing logs.

Problem: AADSTS50076
Affected app and resource:
User recognizes the attempt: yes / no / unresolved
Time and UTC offset:
Result of fresh interactive sign-in:
Requirement or policy identified:
Change made and original-action test result:
Missing evidence / next owner:

Request help with this sign-in

Microsoft sources

Authentication error codes Sign-in event details Application handling of Conditional Access challenges Power Automate connections and MFA Conditional Access and licensing Security defaults