Identity ✓ fields verified against sample logs

Entra ID (Azure AD) Sign-In Log Fields: Reference With Examples

Published

One record per sign-in attempt to Microsoft Entra ID: who signed in, from where, with which client, what Conditional Access decided and how it ended. The primary evidence for identity attacks against Microsoft 365.

Official documentation: signIn resource type (Microsoft Graph) · Sign-in logs in Microsoft Entra ID

Sample record

    {
      "id": "corp0001-0000-0000-0000-000000000001",
      "createdDateTime": "2026-06-07T08:30:00Z",
      "userDisplayName": "Alice Johnson",
      "userPrincipalName": "[email protected]",
      "userId": "user-alice",
      "appDisplayName": "Microsoft Teams",
      "resourceDisplayName": "Microsoft Teams",
      "clientAppUsed": "Browser",
      "ipAddress": "203.0.113.10",
      "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
      "isInteractive": true,
      "conditionalAccessStatus": "success",

From the LogTriage parser test corpus — synthetic data, no real hosts or users.

Field reference

Field Type Meaning Why it matters for security
createdDateTimee.g. 2026-06-07T08:30:00Z datetime (UTC) When the sign-in attempt happened. Sequence failures and successes per user and IP; attacks cluster outside working hours.
userPrincipalNamee.g. [email protected] string The account the sign-in was for, as typed or resolved. Counting distinct values per IP is how password spraying is found.
ipAddresse.g. 203.0.113.10 string Public IP the request came from (the egress of NAT, proxy or VPN). The pivot for spraying, impossible travel and threat-intel lookups.
status.errorCodee.g. 50126 integer 0 for success; otherwise the AADSTS code. 50126 wrong password, 50053 lockout, 50074/50076 password accepted but MFA required, 53003 blocked by Conditional Access.
status.failureReason string Human-readable text for the error code. Distinguishes the two causes of 50053 (lockout vs. malicious IP).
clientAppUsede.g. Mobile Apps and Desktop clients string Client type: Browser, Mobile Apps and Desktop clients, Exchange ActiveSync, IMAP4, POP3, Authenticated SMTP, Other clients. Legacy protocols cannot do MFA and are the favourite path for credential testing.
userAgente.g. python-requests/2.28.0 string User-Agent header of the client. Scripted agents such as python-requests or BAV2ROPC on user sign-ins point to automation.
isInteractive boolean Whether the user was present (true) or a client acted on the user's behalf. Non-interactive sign-ins are logged separately in Log Analytics; search both.
conditionalAccessStatuse.g. notApplied string Overall Conditional Access result: success, failure or notApplied. notApplied on a failed sign-in means it failed at the password, before any policy ran.
appliedConditionalAccessPolicies array Each policy evaluated, with displayName and result. Shows which policy blocked or required MFA for a request.
deviceDetail.trustTypee.g. None string How the device is joined: Azure AD joined, Hybrid Azure AD joined, registered, or none. An unmanaged, unjoined device signing in as an admin is worth a look.
deviceDetail.isCompliant boolean Whether Intune considered the device compliant. Compliance-based policies key on this.
location.countryOrRegione.g. NL string Country derived from the IP address. Two countries for one user within hours is the basis of impossible-travel detection.
riskLevelDuringSignIne.g. high string Entra ID Protection's real-time risk for this sign-in (none, low, medium, high). High risk on a success deserves immediate review; full risk detail requires Microsoft Entra ID P2.
mfaDetail.authMethode.g. Phone app notification string The MFA method used when MFA was performed. Unexpected methods (SMS, a newly added phone) after a password reset can indicate account takeover.

What it records

Each record is one sign-in attempt to Microsoft Entra ID (formerly Azure AD), successful or not. It captures the identity (userPrincipalName), the application and resource being accessed, the client and user agent, the source IP and derived location, the device, every Conditional Access policy that was evaluated, the MFA method used, Entra ID Protection’s risk assessment and the outcome in status.errorCode.

Successful sign-ins have errorCode 0. Failures carry an AADSTS code; the investigator-focused pages for the most important ones are in the AADSTS reference — for example AADSTS50126 for a wrong password and AADSTS50074 for a correct password that stopped at MFA.

Where to get it

  • Entra admin center → Monitoring & health → Sign-in logs → Download, as CSV or JSON. Convenient, but the download is capped and the CSV flattens nested fields.
  • Microsoft Graph GET /auditLogs/signIns, which returns the JSON documented here, wrapped as {"value": [...]}.
  • Diagnostic settings streaming to a Log Analytics workspace (the SigninLogs and AADNonInteractiveUserSignInLogs tables), a storage account or an event hub for a SIEM. This is the only practical way to keep months of history.

Parsing pitfalls

  • Two shapes of JSON. Graph returns {"value": [...]}; some exports are a bare array. A parser that expects one silently reads zero records from the other.
  • Nested fields. status, deviceDetail, location and mfaDetail are objects. In the portal CSV they become flat columns with different names, so field names do not carry over between formats.
  • Interactive and non-interactive in different places. Exports from the portal and Log Analytics separate them; an investigation that reads only one misses scripted and token-based activity.
  • Error code as number or string. Graph returns an integer; Log Analytics stores ResultType as a string. Compare "50126", not 50126, in KQL.
  • Location is derived. Country and city come from IP geolocation, so VPNs, mobile carriers and cloud egress points produce plausible-looking but wrong locations.

Detection ideas

  • Password spraying: one ipAddress with errorCode 50126 across five or more userPrincipalName values in an hour.
  • Password confirmed, MFA stopped: 50074 or 50076 from an unfamiliar IP with no success following.
  • Legacy-protocol credential testing: clientAppUsed of IMAP4, POP3, Authenticated SMTP, Exchange ActiveSync or Other clients, especially with scripted user agents — the subject of the legacy-auth MFA bypass rule.
  • Impossible travel: two successful sign-ins for one user from countries too far apart for the time between them.
  • Risky success: riskLevelDuringSignIn high with errorCode 0.

The free browser analyzer runs these checks on a Graph JSON or portal CSV export without uploading it.

Detections and guides for Azure AD Sign-In Logs

Frequently Asked Questions

What is the difference between SigninLogs and AADNonInteractiveUserSignInLogs?
In Log Analytics and Microsoft Sentinel, interactive sign-ins (a user typing a password or approving MFA) go to SigninLogs, while sign-ins a client performs on the user's behalf, such as token refreshes, go to AADNonInteractiveUserSignInLogs. Scripted attacks and legacy clients often appear in the non-interactive table, so hunting queries should union both.
Where is the error code in the portal CSV download?
In the Sign-in error code column, with the text in Failure reason. The CSV flattens the record, so nested objects such as device details and location become separate columns, and the column names differ from the Graph JSON field names documented on this page.
How long are Entra ID sign-in logs kept?
The Entra admin center keeps them for a limited period that depends on the license tier, which is short for investigations that start weeks after an incident. Route them to a Log Analytics workspace, storage account or SIEM through diagnostic settings to keep them as long as your retention policy requires.
Which fields matter most for detecting identity attacks?
status.errorCode, userPrincipalName, ipAddress, clientAppUsed and userAgent cover most detections: spraying is one IP with many accounts and error 50126, legacy-protocol abuse is a non-browser clientAppUsed, and MFA-stage codes such as 50074 and 50076 mean the password was already correct.

Analyze a Azure AD Sign-In Logs file in your browser

The free analyzer detects this format, parses every field above and flags attack patterns — the file never leaves your machine. For threat-intel enrichment and an AI-written incident report, run it through LogTriage.

Open the free analyzer → Analyze Your Own Logs