When something goes wrong with access in Microsoft 365 — a locked-out user, a login that shouldn’t have worked, a Conditional Access policy that’s blocking the wrong people — the sign-in logs are where you find out what actually happened. They record every authentication attempt against your tenant, who tried, from where, on what device, and whether it succeeded or got stopped and why.
The problem most admins hit isn’t finding the logs, it’s reading them. There’s a lot of data, the same user generates dozens of entries an hour, and the difference between an interactive and a non-interactive sign-in trips people up. This guide shows where the logs live, how to filter them down to the event you care about, how to read a failure code, and how to keep the data longer than the default retention window when you need it for an investigation.
Where the sign-in logs live
Sign-in activity is part of Microsoft Entra ID (formerly Azure AD), not a separate Microsoft 365 feature. You reach the same data from a few places:
- Microsoft Entra admin center → Monitoring & health → Sign-in logs. This is the primary home.
- Azure portal → Microsoft Entra ID → Sign-in logs. Identical data.
- A per-user view: open a user under Users and look at their Sign-in logs to see only their activity.
You need an appropriate role to view them. Reports Reader, Security Reader, Security Administrator, or Global Administrator can all read the sign-in logs.
Interactive vs non-interactive: pick the right tab
This is the detail that confuses people most. The sign-in logs are split into tabs, and the two that matter day to day are:
- Interactive sign-ins — the user was present and entered something: a password, an MFA approval, a passwordless prompt. These are the ones you usually care about.
- Non-interactive sign-ins — performed on the user’s behalf by a client app or a token refresh, with no prompt. A single user can rack up hundreds of these because every background token refresh counts.
If you’re searching for “the time Maria logged in this morning,” you want the interactive tab. If interactive looks empty but you know there was activity, the events may be sitting under non-interactive because a cached token was being refreshed rather than a fresh credential entered. There are also separate tabs for service principal and managed identity sign-ins, which cover app-only authentication rather than people.
Filtering down to the event you need
Out of the box the view is a firehose. Filters are how you make it useful. The ones you’ll reach for constantly:
The filters that matter most
| User / username | Narrow to one person's activity |
|---|---|
| Status | Success, Failure, or Interrupted — the fastest way to find what broke |
| Date range | Bound the search to the incident window |
| Application | Which app was accessed: Exchange Online, SharePoint, the portal, etc. |
| Conditional Access | Filter by whether a CA policy was applied, succeeded, or failed |
| IP address / Location | Spot sign-ins from unexpected countries or addresses |
| Client app | Separate modern auth from legacy authentication clients |
A typical investigation is two filters stacked: the username plus Status: Failure. That collapses the noise to just the attempts that didn’t work, and each one carries the reason it failed.
To hunt for suspicious access instead, filter by Location or IP address and look for sign-ins from places your users aren’t, or filter Client app to legacy authentication clients to find protocols that can’t do MFA. Legacy auth showing up against an account is a classic precursor to a password-spray compromise, which is one reason protecting Microsoft 365 from phishing leans on blocking those older protocols.
Reading a single sign-in event
Click any row and a detail pane opens with tabs. This is where the real answers are.
- Basic info — the sign-in error code and failure reason in plain language. This is the first thing to read on a failure.
- Conditional Access — every policy that applied to this sign-in and the result of each: success, failure, or not applied. This is how you prove which policy blocked someone.
- Device info — operating system, browser, and whether the device is managed or compliant.
- Authentication details — each step of the authentication, including which MFA method was used and whether it succeeded.
The sign-in error code is the key field on any failure. It’s a number you can look up to get the exact meaning, and it tells you whether the password was wrong, MFA wasn’t completed, the account was disabled, or a policy blocked the attempt. A few you’ll see often:
Common sign-in error codes
| 50126 | Invalid username or password — the credential itself failed |
|---|---|
| 50053 | Account locked due to repeated failed attempts (or smart lockout) |
| 50074 | Strong authentication (MFA) required but not satisfied |
| 50076 / 50079 | MFA required by Conditional Access; user needs to complete or register MFA |
| 53003 | Access blocked by a Conditional Access policy |
| 50058 | Silent sign-in failed — session info missing, often a non-interactive event |
Using the logs to troubleshoot real problems
The logs earn their keep in a handful of recurring situations.
A user can’t sign in. Filter to their name, set Status to Failure, read the error code on the most recent attempt. Wrong password is one fix; a Conditional Access block is a completely different one. This is also the first step when MFA isn’t working in Microsoft 365 — the log tells you whether MFA was even reached.
A Conditional Access policy is too aggressive. Find a blocked sign-in, open the Conditional Access tab, and see which policy returned failure. If you built the policy in report-only mode, this same view shows what the policy would have done without enforcing it, which is exactly how you validate a policy before turning it on.
Suspected account compromise. Filter by the user and widen the date range, then look at IP addresses and locations. Sign-ins from two distant countries minutes apart, or success from an IP you don’t recognise, are the signals. Check the Client app column too — legacy auth on the account is a red flag.
Confirming an account is actually being used. Before you reclaim or delete an account, the last interactive sign-in tells you whether anyone still logs in with it.
Investigating a sign-in problem
- Confirm you're on the Interactive tab (or check Non-interactive if it looks empty)
- Filter by username and set Status to Failure
- Read the sign-in error code and failure reason on the latest attempt
- Open the event and check the Conditional Access tab for policy results
- Check IP address and Location for anything unexpected
- Look at Client app to spot legacy authentication
Retention: the logs don’t last forever
The default retention in the portal is short, and it’s tied to your licensing. This catches people out during investigations that start late.
Sign-in log retention by license
| Entra ID Free | Interactive sign-ins retained roughly 7 days in the portal |
|---|---|
| Entra ID P1 / P2 | Retained around 30 days in the portal |
| Any tier + diagnostic settings | Long-term retention by exporting to Log Analytics, Storage, or a SIEM |
If you need history beyond the portal window — and for security work you usually do — set up diagnostic settings to stream the logs out before you need them. You can’t go back and recover events that already aged out, so configure this in advance.
Exporting and long-term collection
For a one-off, the Download button on the sign-in logs view exports the current filtered results as CSV or JSON. That’s enough to attach to a ticket or hand to an auditor.
For continuous collection, configure diagnostic settings on the Entra logs to send sign-in (and audit) data to one of:
- a Log Analytics workspace, where you can query it with KQL and build alerts,
- an Azure Storage account for cheap long-term archival,
- or an event hub that feeds a SIEM like Microsoft Sentinel.
Entra admin center → Monitoring & health → Diagnostic settings → Add diagnostic setting
- Choose log categories: SignInLogs, NonInteractiveUserSignInLogs, AuditLogs
- Send to: Log Analytics workspace / Storage account / Event hubOnce the data is in Log Analytics, KQL queries let you do the analysis the portal filters can’t, like counting failed sign-ins per IP to surface a spray attack across the whole tenant at once.
Wrapping up
The sign-in logs answer the “what actually happened at login” questions that the rest of the admin center can’t. Get to them through the Entra admin center, make sure you’re on the right tab (interactive for human logins), and filter by user plus Status to find the event fast. On a failure, the sign-in error code and the Conditional Access tab tell you the cause. And because portal retention is days, not months, set up diagnostic settings to export the logs before an incident forces you to wish you had.
Once you can read the logs confidently, they become the feedback loop for the rest of your identity setup — validating Conditional Access policies in report-only mode and confirming MFA enrollment is actually taking effect across your users.
