When a user says “I can’t sign in” or an alert says “suspicious sign-in”, the answer is almost always in the Entra sign-in logs. The problem is that the logs are dense, full of codes and tabs, and easy to misread. This guide shows how to read them the way an investigator does: narrow the view, read the right fields, and separate a harmless failure from a real attack.
Where the sign-in logs live and how long they last
Open the Microsoft Entra admin center and go to Entra ID > Monitoring & health > Sign-in logs. The least privileged role that can read them is Reports Reader, so your help desk does not need an admin role to troubleshoot.
Retention depends on your license, and it is the first thing that catches people out during an investigation:
License
Sign-in log retention
Audit log retention
Microsoft Entra ID Free
7 days
7 days
Microsoft Entra ID P1 (Business Premium, E3)
30 days
30 days
Microsoft Entra ID P2 (E5)
30 days
30 days
Upgrading does not bring back expired data. If you need more history, send the logs to a Log Analytics workspace, Microsoft Sentinel or a storage account using diagnostic settings. Do it now, not on the day you need last quarter’s data.
The four sign-in log types
The sign-in logs are split into tabs, and looking at the wrong tab is the most common reason an investigation goes nowhere.
User sign-ins (interactive): a person entered a password, approved MFA or used a passkey.
User sign-ins (non-interactive): an app or the operating system signed in on the user’s behalf using a refresh token, with no prompt. Outlook and Teams generate a lot of these.
Service principal sign-ins: an application identity authenticated with its own credential.
Managed identity sign-ins: an Azure resource authenticated with a managed identity.
Token replay and session theft often show up in the non-interactive tab, because the attacker is using a stolen token rather than typing a password. If you only look at interactive sign-ins, you can miss it entirely.
Reading a single sign-in event
Select any row to open its details. These are the fields I read first, in order:
Status, sign-in error code and failure reason. The code tells you which stage failed. Copy it and look it up if it is unfamiliar.
Application and resource. What was the user trying to reach? A failed sign-in to an app nobody uses is a different story from a failed sign-in to Exchange Online.
IP address and location. Is it your office, a home ISP, a hosting provider or a country you do not operate in?
Device info and client app. Is the device registered or compliant? Is the client a modern browser, Outlook, or a legacy protocol?
Authentication details. Which method was used, and did MFA succeed? This tab can take some time to fully populate, so recheck it on fresh events.
Conditional Access tab. Which policies applied and what each one decided. This is where “why was I blocked” gets answered.
Correlation ID and request ID. Save these if you need to raise a case with Microsoft.
Error codes worth knowing by heart
You do not need to memorize hundreds of codes. A handful explain most of what a help desk sees.
Code
Meaning
What it usually tells you
50126
Invalid username or password
Typo, or password spraying if seen across many accounts from one source
50053
Account locked (smart lockout) or sign-in blocked from a malicious IP
Repeated bad passwords, often an attack
50057
User account is disabled
Leaver account still being used somewhere
50074 / 50076
Strong authentication required
Normal MFA interrupt, not a failure on its own
500121
Authentication failed during strong authentication request
MFA denied, timed out or not completed. Watch for repeats.
53003
Blocked by Conditional Access
Check the Conditional Access tab for the policy
50140
“Keep me signed in” interrupt
Normal, not a problem
Microsoft’s sign-in error lookup tool at login.microsoftonline.com/error explains any code you do not recognize.
Investigator patterns: what attacks look like
Password spraying
Filter on Status: Failure and error 50126, then group by IP address. One IP trying a few passwords against many users is spraying. Smart lockout (50053) appearing across several accounts at once confirms it.
MFA fatigue
A single user with a burst of 500121 failures in a short window means someone has their password and is hoping they will approve a prompt. Reset the password immediately, even if no prompt was approved.
Successful sign-in from an unexpected place
A success from a hosting provider IP or an unusual country, especially followed by non-interactive sign-ins from the same IP, suggests a stolen session or token. Revoke sessions, reset the password, and check the user’s mailbox rules and registered MFA methods in the audit logs.
Legacy protocol attempts
Filter Client app for legacy options such as IMAP, POP or SMTP authentication. If you have blocked legacy authentication, these should all be failures. Any success means a gap in your policies.
A quick triage routine
When a ticket or alert lands, I work through the same short routine. First, set the date range to cover a day either side of the reported problem. Second, filter to the user and look at both the interactive and non-interactive tabs. Third, compare IP addresses and devices against what is normal for that person. Finally, check the audit logs for changes made to the account in the same window, such as new MFA methods, password resets or role assignments. That sequence answers most questions in under ten minutes and tells you quickly whether you are dealing with a help desk issue or a security incident.
Making the logs work for you
Reading logs one row at a time is fine for help desk tickets. For security, you want the logs working while you sleep.
Export sign-in and audit logs to Log Analytics or Microsoft Sentinel so you can query months of data with KQL.
Use the built-in workbooks, such as Sign-ins and the Conditional Access insights and reporting workbook, to spot trends.
Enable Microsoft Entra ID Protection risk policies (Entra ID P2) so risky sign-ins trigger MFA or password change automatically.
Alert on high-value patterns: any emergency access account sign-in, admin sign-ins from new countries, and spikes in 50053.
Why does a user show hundreds of sign-ins per day?
Most of them are non-interactive sign-ins from Outlook, Teams and OneDrive refreshing tokens in the background. That is normal. Focus on interactive sign-ins and on any non-interactive activity from IP addresses the user does not normally use.
Can users see their own sign-in history?
Yes. Any user can review their own recent sign-ins at mysignins.microsoft.com. It is a useful step when you ask a user to confirm whether an unfamiliar sign-in was them.
Why can I only see seven days of logs?
Your tenant is on Microsoft Entra ID Free. P1 and P2 keep 30 days. For anything longer, export the logs to Log Analytics, Sentinel or a storage account.
Want a second pair of eyes on what your sign-in logs are telling you? Book a free Microsoft 365 security assessment and we will review recent failures, risky sign-ins and log retention in your tenant.
When a user says “I can’t sign in” or an alert says “suspicious sign-in”, the answer is almost always in the Entra sign-in logs. The problem is that the logs are dense, full of codes and tabs, and easy to misread. This guide shows how to read them the way an investigator does: narrow the view, read the right fields, and separate a harmless failure from a real attack.
Where the sign-in logs live and how long they last
Open the Microsoft Entra admin center and go to
Entra ID > Monitoring & health > Sign-in logs. The least privileged role that can read them is Reports Reader, so your help desk does not need an admin role to troubleshoot.Retention depends on your license, and it is the first thing that catches people out during an investigation:
Upgrading does not bring back expired data. If you need more history, send the logs to a Log Analytics workspace, Microsoft Sentinel or a storage account using diagnostic settings. Do it now, not on the day you need last quarter’s data.
The four sign-in log types
The sign-in logs are split into tabs, and looking at the wrong tab is the most common reason an investigation goes nowhere.
Token replay and session theft often show up in the non-interactive tab, because the attacker is using a stolen token rather than typing a password. If you only look at interactive sign-ins, you can miss it entirely.
Reading a single sign-in event
Select any row to open its details. These are the fields I read first, in order:
Error codes worth knowing by heart
You do not need to memorize hundreds of codes. A handful explain most of what a help desk sees.
Microsoft’s sign-in error lookup tool at
login.microsoftonline.com/errorexplains any code you do not recognize.Investigator patterns: what attacks look like
Password spraying
Filter on Status: Failure and error 50126, then group by IP address. One IP trying a few passwords against many users is spraying. Smart lockout (50053) appearing across several accounts at once confirms it.
MFA fatigue
A single user with a burst of 500121 failures in a short window means someone has their password and is hoping they will approve a prompt. Reset the password immediately, even if no prompt was approved.
Successful sign-in from an unexpected place
A success from a hosting provider IP or an unusual country, especially followed by non-interactive sign-ins from the same IP, suggests a stolen session or token. Revoke sessions, reset the password, and check the user’s mailbox rules and registered MFA methods in the audit logs.
Legacy protocol attempts
Filter Client app for legacy options such as IMAP, POP or SMTP authentication. If you have blocked legacy authentication, these should all be failures. Any success means a gap in your policies.
A quick triage routine
When a ticket or alert lands, I work through the same short routine. First, set the date range to cover a day either side of the reported problem. Second, filter to the user and look at both the interactive and non-interactive tabs. Third, compare IP addresses and devices against what is normal for that person. Finally, check the audit logs for changes made to the account in the same window, such as new MFA methods, password resets or role assignments. That sequence answers most questions in under ten minutes and tells you quickly whether you are dealing with a help desk issue or a security incident.
Making the logs work for you
Reading logs one row at a time is fine for help desk tickets. For security, you want the logs working while you sleep.
Microsoft’s guide to troubleshooting Microsoft Entra sign-in errors walks through the portal steps in more detail. If you would rather have someone watching these logs for you, our managed security service monitors identity signals around the clock, and our Defender for Office 365 work covers the email side of the same attacks.
Frequently asked questions
Why does a user show hundreds of sign-ins per day?
Most of them are non-interactive sign-ins from Outlook, Teams and OneDrive refreshing tokens in the background. That is normal. Focus on interactive sign-ins and on any non-interactive activity from IP addresses the user does not normally use.
Can users see their own sign-in history?
Yes. Any user can review their own recent sign-ins at
mysignins.microsoft.com. It is a useful step when you ask a user to confirm whether an unfamiliar sign-in was them.Why can I only see seven days of logs?
Your tenant is on Microsoft Entra ID Free. P1 and P2 keep 30 days. For anything longer, export the logs to Log Analytics, Sentinel or a storage account.
Want a second pair of eyes on what your sign-in logs are telling you? Book a free Microsoft 365 security assessment and we will review recent failures, risky sign-ins and log retention in your tenant.