Entra ID sign-in logs: the fields and error codes that settle an account question

Before anything else: retention

Entra ID keeps sign-in logs for 7 days on the free tier and 30 days with P1 or P2. Past that, they exist only if somebody exported them to a SIEM or a storage account. If the tenant you are investigating has never exported them, export now, before you read a single row.

Four logs, not one

Log	What it holds	Where people forget it
Interactive user sign-ins	A person entering credentials or completing MFA	This is the one everybody opens
Non-interactive user sign-ins	Token refreshes and sign-ins a client makes on the user's behalf	A stolen session replayed from elsewhere shows up here, not above
Service principal sign-ins	Applications signing in as themselves	An abused app registration or consent grant
Managed identity sign-ins	Azure resources signing in	Compromised workloads

In Sentinel they are separate tables: SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs.

The fields that decide it

Field	What it tells you	What to watch for
ipAddress	The address the sign-in came from	Enrich with the provider (ASN). Hosting and anonymising VPN providers are rare for real users
location	City and country, derived from the address	The least reliable field. Mobile carriers and VPNs place people far from where they are
appDisplayName, resourceDisplayName	What was signed in to, and what it asked for access to	A first sign-in from a new address going straight to Exchange Online or the Azure portal
clientAppUsed	Browser, mobile app, or a legacy protocol	Legacy protocols such as IMAP or SMTP cannot do MFA
deviceDetail	Browser, operating system, device ID, whether the device is compliant or joined	An unmanaged device for a user who only ever uses a managed one
authenticationRequirement	Whether the policy required single or multi-factor	A risky sign-in that satisfied only a single factor
authenticationDetails	Each method used and whether it succeeded	"MFA requirement satisfied by claim in the token" means no prompt was answered for this sign-in
conditionalAccessStatus	Whether policies applied, and passed or failed	notApplied on an account you expected to be covered
riskLevelDuringSignIn, riskState	Identity Protection's view, where licensed	High risk remediated by the user resetting their own password
correlationId	Ties together the records of one sign-in flow	Follow it to see the whole attempt
isInteractive	Interactive or not	Filter on it when one export holds both

Error codes worth knowing by number

status.errorCode is 0 for success. The ones that come up most in an investigation:

Code	Meaning	Reading it
0	Success
50126	Invalid username or password	Many accounts, one source, a short window: password spraying
50053	Account locked, or sign-in blocked from a suspicious address	Smart lockout doing its job, or a spray hitting its limit
50055	Password expired
50057	Account disabled	Attempts against a disabled account are worth a look
50074	Strong authentication required	An interrupt, not a failure: the user was sent to MFA
50076	MFA required because of location or conditions	Also an interrupt, common and usually benign
50079	The user must register for MFA	On an account that should already have MFA, check who registers what next
500121	Authentication failed during strong authentication	Denied or unanswered MFA prompts. Repeated, it is MFA fatigue
53003	Blocked by Conditional Access	A policy stopped it. Which one is in the Conditional Access tab

Codes change and new ones are added. Check an unfamiliar one against Microsoft's error code reference rather than guessing from the number.

Two patterns to recognise

The relayed login. A successful interactive sign-in with MFA from the user's own address, followed within minutes by non-interactive sign-ins for the same user from a hosting provider. That is a phishing kit that let the user complete MFA and kept the session. See the first-15-minutes checklist.

The spray. Failures with 50126 across many accounts from a handful of addresses, one or two attempts per account, then a single success. Look at what the successful account did next.