Why is the user asked to sign in again? AADSTS70043, 700082, 50173, 50133, 50076

When a user is asked to sign in again, the sign-in log row’s code usually tells you why: a Conditional Access sign-in frequency policy (70043), an idle refresh token (700082), a revoked token (50173), a session invalidated by a password change (50133), or an MFA requirement (50076). Most are benign; the ones worth a second look are 50173 and 50076, and only when the IP or device is not the user’s.

Which code means which reason?

Match the code in your own log first, then read the row. The messages below are short quotes from Microsoft’s descriptions; the attack signal is the rating on each code’s own page.

Code	Microsoft’s message (short)	What caused it	Attack signal	Log table	Look at first
70043	“The refresh token has expired or is invalid due to sign-in frequency checks by Conditional Access.”	A Conditional Access sign-in frequency session control refused the refresh token	Low	AADNonInteractiveUserSignInLogs	Whether an interactive success from the same IP and device followed; a sudden volume jump points at a policy change
700082	“The refresh token has expired due to inactivity.”	The token was unused until it expired; Microsoft calls it an expected part of the token lifecycle	Low	AADNonInteractiveUserSignInLogs	Whether the IP or device is one the user has used recently
50173	“The provided grant has expired due to it being revoked, a fresh auth token is needed.”	The token was issued before the user’s TokensValidFrom date: password change or reset, or an admin revocation	Medium	AADNonInteractiveUserSignInLogs, SigninLogs	The IP, country and device behind each row, especially after a revocation you ran
50133	“The session isn’t valid due to password expiration or recent password change.”	A session older than the password change or expiry was presented	Low	SigninLogs, AADNonInteractiveUserSignInLogs	Whether the user’s own IPs and devices are the source, and whether many users hit it at once
50076	“…the user must use multifactor authentication to access the resource.”	A configuration change such as a Conditional Access policy, per-user enforcement, or a new location	Medium	SigninLogs, AADNonInteractiveUserSignInLogs	Whether the same IP was failing passwords (50126) before, and whether a success (0) followed

How do I decide which one I am looking at?

This is my interpretation of the five pages, not a Microsoft flowchart.

• The message mentions sign-in frequency: it is 70043. A policy you configured did its job. Check whether someone created or tightened a policy if the volume jumped.
• The message mentions inactivity: it is 700082. Nothing revoked the token and no policy fired; it sat unused.
• The message mentions a revoked grant or TokensValidFrom: it is 50173. Ask whether you, or the user, just reset a password or revoked sessions. If yes, rows from the user’s own devices are the expected sign-out. Rows from an IP you cannot tie to the user are the useful ones.
• The message mentions a session and a password change or expiry: it is 50133, the session-side sibling of 50173. Many users at once suggests a password expiry wave or bulk reset, not an incident.
• The message says MFA is required: it is 50076. The first factor already passed, so the question is who reached that step. Compare with failed passwords from the same IP, and see the MFA fatigue guide if prompts repeat.
• The user says “I signed in just now” and still gets prompted: think of 70043 first. The 70043 page explains that device state and the Primary Refresh Token affect whether a sign-in counts toward the frequency window.

Two codes are easy to mix up. 70043 and 700082 are both refresh-token expiries, but one is policy and one is idleness. 50173 and 50133 are both password-change or revocation effects, but one is about refresh tokens and the other about sessions.

How do I count these codes side by side (KQL)?

Untested: this query has not been run against a lab tenant yet. Try it in your own workspace and check the columns against a row there. ResultType is a string column, so the values are quoted. Non-interactive rows are aggregated by Microsoft when application, user, IP address, status and resource match, so Rows is a count of log rows, not of requests.

union
    (SigninLogs
     | project TimeGenerated, UserPrincipalName, IPAddress, ResultType, Table = "SigninLogs"),
    (AADNonInteractiveUserSignInLogs
     | project TimeGenerated, UserPrincipalName, IPAddress, ResultType, Table = "AADNonInteractiveUserSignInLogs")
| where TimeGenerated > ago(7d)
| where ResultType in ("70043", "700082", "50173", "50133", "50076")
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            IPs = dcount(IPAddress)
          by ResultType, Table
| sort by ResultType asc, Table asc

How to read it (interpretation): a code that is mostly one table matches the table on its page, so a surprise there is worth a look. A steady 70043 or 700082 baseline is normal. A spike in 50173 or 50133 should line up with a password reset or revocation you can name. Then open the page for the code that spiked and run its per-IP query.

What can’t this page tell me?

• Codes without a page here. This hub covers only the five codes that have pages on this site. 50078 and other MFA or re-authentication codes are not compared; I have not written them up.
• Whether a given row is an attack. The ratings are per code, from each page. A low-rated code can still hide a stolen token, and a medium one is usually benign.
• What a revocation without a password change looks like. Whether an admin revocation alone shows up as 50133 is not stated by Microsoft. The revocation guide marks it as lab check pending.
• Access tokens already issued. Revocation stops new tokens, so there may be no 50173 for an attacker still using a valid access token. Check again after the token lifetime has passed.
• Anything proven in a lab. The decision flow and the query have not been tested against a lab tenant (lab test pending).

Where do I go next?

• AADSTS70043: sign-in frequency refused the refresh token
• AADSTS700082: refresh token expired from inactivity
• AADSTS50173: refresh token revoked
• AADSTS50133: session invalid after password change or expiry
• AADSTS50076: MFA required
• After a compromise: revoke sessions and prove it worked
• How to detect MFA fatigue