Microsoft Entra ID Sign-In Telemetry Reference
Microsoft Entra ID writes all sign-in activity to a family of Log Analytics tables that Sentinel ingests. Every record in every table carries OperationName = "Sign-in activity" regardless of the action involved. Because there is no per-operation discriminator, the tables cannot be modeled as discrete events the way Windows Security events are. Detections instead filter on field values within each table to distinguish success from failure, legacy from modern auth, and risky from compliant sessions.
Sign-In Log Tables#
| Table | Covers |
|---|---|
| SigninLogs | Interactive user sign-ins: browser-based flows, native clients, and ROPC (Resource Owner Password Credential) flows where a human enters credentials. The primary detection surface for credential attacks and impossible-travel scenarios. |
| AADNonInteractiveUserSignInLogs | Non-interactive user sign-ins: token refreshes, mail clients using cached tokens, and client-credential flows on behalf of a user. High volume, so filter to failures or anomalous patterns before alerting. |
| AADServicePrincipalSignInLogs | Application and service principal sign-ins using client secrets or certificates. Detections focus on new or unexpected service principals acquiring tokens, and credential stuffing against application registrations. |
| AADManagedIdentitySignInLogs | Sign-ins by Azure managed identities (system-assigned and user-assigned). Baseline traffic is benign. Anomalies (unexpected resource access, new managed identities) carry the detection signal. |
CombinedSignInLogs is a Sentinel workspace function that unions all four tables into a single queryable surface. Rules targeting CombinedSignInLogs attribute to all four underlying tables.
Why There Are No Per-Operation Event Pages#
Each record in the sign-in tables carries OperationName = "Sign-in activity" without exception. The Entra audit pipeline does not emit separate operation names for "password auth", "MFA challenge", "token refresh", and so on. The result type, authentication method, and policy state are instead distributed across numeric and enumerated fields within each record.
Detections in the Sigma and Sentinel corpora that target sign-in logs pivot on these fields rather than on an operation name. The Entra ID Coverage matrix lists contributing rules under the "SigninLogs" section of that page.
Key Detection Fields#
| Field | Type | Detection Use |
|---|---|---|
| ResultType | int (stored as string) | Sign-in outcome code. 0 is success. Every other value is a failure or interruption. |
| ResultDescription | string | Human-readable reason phrase paired with ResultType. Display it, but match on ResultType. |
| ClientAppUsed | string | Authentication client reported by the service. Legacy authentication clients report values such as Other clients, IMAP, POP3, SMTP, Mapi, AutoDiscover, and Exchange ActiveSync. Modern clients report Browser or Mobile Apps and Desktop Clients. Rules that hunt legacy auth filter on these string values because legacy protocols bypass MFA. |
| AuthenticationRequirement | string | multiFactorAuthentication or singleFactorAuthentication. Indicates what the policy required for the session, not whether MFA succeeded. Combine with ResultType to distinguish MFA-required failures from single-factor successes. |
| ConditionalAccessStatus | string | Whether a Conditional Access policy applied: success, failure, notApplied, or notEnabled. Failures correspond to ResultType 53003. |
| RiskState | string | Identity Protection risk assessment at sign-in time: atRisk, confirmedSafe, remediated, dismissed, confirmedCompromised, or none. Populated only when Identity Protection is licensed (Entra ID P2). |
| RiskLevelDuringSignIn | string | Identity Protection risk level at sign-in: none, low, medium, high, or hidden. hidden means the user or tenant is not scoped for Identity Protection. Rules may alert when this is high and ResultType is 0 (a risky sign-in that succeeded). |
| RiskDetail | string | Reason the risk level was assigned, e.g. userPassedMFADrivenByRiskBasedPolicy, adminConfirmedSigninCompromised. Useful for triage context. |
| IPAddress | string | Source IP of the sign-in request. Primary field for impossible-travel rules and TI enrichment. Anonymous proxy and Tor exit node detection pivots here. |
| Location | dynamic (JSON) | Nested object containing city, state, countryOrRegion, and geoCoordinates. In KQL: Location.countryOrRegion. Sentinel rules for impossible-travel expand geoCoordinates for distance calculations. |
| AppDisplayName | string | The application being signed into, as registered in the tenant. Examples: Microsoft Teams, Azure Portal, Office 365 Exchange Online. Rules hunt unexpected apps acquiring tokens for sensitive resources. |
| ResourceDisplayName | string | The OAuth resource (API) being accessed. Distinct from AppDisplayName when a first-party client accesses a resource. For example, a Teams client (AppDisplayName) accessing Office 365 Exchange Online (ResourceDisplayName). |
| UserPrincipalName | string | UPN of the signing-in user. Join key for correlating sign-in failures with Entra ID object changes (password resets, account enables/disables in AuditLogs). |
| DeviceDetail | dynamic (JSON) | Device compliance, join type, and browser. DeviceDetail.isCompliant and DeviceDetail.isManaged are common Conditional Access gate fields. Unmanaged devices signing in to sensitive apps are a detection signal. |
| AuthenticationDetails | dynamic (JSON array) | Per-factor breakdown of the authentication steps. Each element carries authenticationMethod, authenticationStepResultDetail, and succeeded. Use this to determine which factor failed when ResultType indicates an MFA failure. |
| MfaDetail | dynamic (JSON) | Method used for MFA: authMethod (e.g. Phone App Notification, OATH software token) and authDetail. Populated only for interactive sign-ins that invoked MFA. |
| HomeTenantId | string (GUID) | Tenant that owns the account. Differs from the resource tenant in B2B (cross-tenant) scenarios. Rules for external-user access filter on a mismatch between HomeTenantId and the workspace tenant. |
| CrossTenantAccessType | string | How the cross-tenant access was brokered: b2bCollaboration, b2bDirectConnect, microsoftSupport, serviceProvider, or none. Relevant for tenant-to-tenant lateral movement scenarios. |
ResultType Error Codes#
The most detection-relevant codes are listed here. The full list is maintained in the Microsoft Entra authentication and authorization error codes reference.Known values
0RiskLevelDuringSignIn = "high" or ConditionalAccessStatus = "failure" override to find risky successful sign-ins.50126UserPrincipalName, IPAddress, or AppDisplayName over short windows. Spray patterns show many distinct accounts failing from a single IP. Stuffing shows repeated failures against one account.50053500575007450076ClientAppUsed values for legacy protocols.50012153003ConditionalAccessStatus is failure. The specific policy and reason are available in ConditionalAccessPolicies (dynamic array). Repeated 53003 from the same user may indicate policy evasion attempts (switching apps, devices, or locations).5300470001690095
Detection Scenarios by Technique#
The ResultType codes and field values above recur across a handful of attack patterns. Each row links the ATT&CK technique page for that behavior.
| Scenario | Sign-in signal | ATT&CK technique |
|---|---|---|
| Password spraying and brute force | ResultType 50126 in volume, then 50053: many accounts failing from one IPAddress (spray), or repeated failures against one UserPrincipalName (stuffing) | T1110.003 Password Spraying, parent T1110 Brute Force |
| MFA fatigue (push bombing) | Repeated 50074 for one user, followed by a 0 success from the same session | T1621 Multi-Factor Authentication Request Generation |
| Legacy-auth MFA bypass | 50076 with a legacy ClientAppUsed value (IMAP, POP3, SMTP, Other clients) | T1556 Modify Authentication Process |
| Risky successful sign-in | ResultType 0 with RiskLevelDuringSignIn = high, or a Conditional Access override | T1078.004 Valid Accounts: Cloud Accounts |
| OAuth consent phishing | 90095 (admin consent required) for an unexpected application requesting broad scopes | T1528 Steal Application Access Token |
References#
- Microsoft: SigninLogs table schema
- Microsoft: AADNonInteractiveUserSignInLogs table schema
- Microsoft: AADServicePrincipalSignInLogs table schema
- Microsoft: AADManagedIdentitySignInLogs table schema
- Microsoft: Entra authentication and authorization error codes
- Microsoft: Sign-in log activity details
- Microsoft: Block legacy authentication with Conditional Access