AADSTS50140: Keep me signed in interrupt

What does AADSTS50140 mean?

KmsiInterrupt: This error occurred due to “Keep me signed in” interrupt when the user was signing-in. This is an expected part of the sign in flow, where a user is asked if they want to remain signed into their current browser to make further logins easier.

Microsoft says it plainly: expected. The user saw the “Stay signed in?” question. Answering it, either way, completes the sign-in on the next request.

Is it an attack?

No, not by itself. It is one of the most common reasons sign-in reports show “failures” that aren’t failures.

It still matters in an investigation because of where it sits in the flow. The prompt asks whether to remain signed in, so it appears once authentication has been accepted. That is reasoning from Microsoft’s description, not a separate Microsoft statement, but it means a 50140 is close to a success row for timeline purposes.

Pattern	Likely meaning
50140, then 0 seconds later, same IP and device	Normal browser sign-in. Benign.
50140 counted as a failure on a dashboard or alert	Noise. Exclude it.
50140 from an IP tied to a spray, a phishing kit, or an unfamiliar country	The attacker got through password and MFA. Treat it like a successful sign-in.

Microsoft’s password spray playbook ranks “interrupted sign-ins by attacker IP” right after successful ones when prioritising. A 50140 is an interrupt that comes after authentication, so it belongs at the top of that list.

How do I find it in my logs (KQL)?

Every sign-in from a list of suspect IPs that got past authentication, counting 50140 as a success:

let suspectIPs = dynamic(["203.0.113.10", "198.51.100.25"]);
SigninLogs
| where TimeGenerated > ago(7d)
| where IPAddress in (suspectIPs)
| where ResultType in ("0", "50140")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType,
          AppDisplayName, ClientAppUsed, AuthenticationRequirement, UserAgent
| sort by TimeGenerated asc

Replace the example IPs with your own. A failure overview that leaves out expected interrupts:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != "0"
| where ResultType !in ("50140", "50076", "50158", "50125", "50079")
| summarize Events = count(), Users = dcount(UserPrincipalName)
          by ResultType, ResultDescription
| sort by Events desc

Excluding 50076 and 50079 hides them from a failure count. It doesn’t make them irrelevant. Hunt those codes separately.

How do Conditional Access and MFA affect it?

• 50140 is not a Conditional Access or MFA outcome. It is a prompt about keeping the browser signed in.
• Any MFA or Conditional Access requirement for the sign-in was handled before this prompt. To see which policies applied, look at the related success row for the same user, IP and time, not at the 50140 row.
• An attacker who answers “Yes” is asking for a longer-lived browser session. After a compromise, end it explicitly by revoking sessions.

How do I fix AADSTS50140?

For the user: nothing to fix. Choose Yes or No.

For admins:

1. Exclude 50140 from failure alerts and dashboards.
2. Include it as a success-equivalent in incident timelines for suspicious IPs.
3. If a 50140 came from an attacker IP, reset the password and revoke sessions (Revoke-MgUserSignInSession, or Revoke sessions on the user in the admin center).