Published: March 26, 2026
Microsoft Entra sign-in logs contain much more investigative value than many security teams use in practice. Microsoft’s own sign-in model encourages defenders to read each event through three lenses: who initiated the sign-in, how the sign-in occurred, and what resource was being accessed. Too often, teams focus only on the first lens — username, IP address, and whether the sign-in succeeded or failed — while underusing the richer context that often reveals modern identity attacks. (Microsoft Learn)
That underused context matters because today’s identity attacks are often not obvious password-spray events. They increasingly involve token replay, non-interactive access, policy gaps, unusual client flows, or successful access that technically “looks normal” unless the analyst checks the right fields. Microsoft’s SigninLogs schema includes details such as authentication requirement, Conditional Access outcome, interactive versus non-interactive status, client type, resource targeted, and token-linked identifiers that can help defenders detect suspicious activity earlier and investigate more accurately. (Microsoft Learn)
The problem is not lack of data. The problem is that many SOC workflows still treat sign-in logs like basic login records instead of high-context identity telemetry.
In a cloud-first environment, a successful sign-in is not automatically benign. A login that uses weaker-than-expected authentication, reaches an unusual resource, arrives through a legacy client, or transitions into non-interactive token use can be far more important than a noisy failed-login sequence. Microsoft also supports using linkable identifiers such as Session ID and Unique Token Identifier (UTI) to trace activity across Entra and other Microsoft workloads, which means sign-in data can support both detection and deeper incident reconstruction. (Microsoft Learn)
For defenders, the practical lesson is simple: stop asking only whether a sign-in happened. Start asking how it happened, under what controls, through which client, to which resource, and whether the broader session makes sense.
| Field Category | High-signal authentication and session-context fields in Entra sign-in telemetry |
|---|---|
| Why Overlooked | Many analysts default to username, IP, and result code, while richer fields require more familiarity with the schema and better hunting habits |
| Detection Value | High |
| Best Use Cases | Token abuse, policy gaps, non-interactive access, unusual clients, high-value resource targeting |
| Operational Impact | Better alert tuning, faster triage, stronger identity investigations |
| Main Weakness | These fields are most powerful in combination, not isolation |
This field shows whether the sign-in required single-factor authentication or multi-factor authentication.
Why it matters: a successful sign-in to a sensitive application using only single-factor authentication can be much more important than a failed login. Analysts often check whether a login succeeded, but not whether it succeeded under the expected level of authentication control. Microsoft explicitly surfaces authentication requirement and method-level detail in sign-in activity details. (Microsoft Learn)
What to watch for:
This section of the sign-in record shows the sequence of authentication methods used, whether each step succeeded, and how the sign-in progressed.
Why it matters: this is often where the real story lives. A sign-in may be marked successful overall, but the underlying sequence can still reveal unusual retries, MFA behavior, or fallback patterns. Microsoft’s sign-in activity details page specifically highlights authentication details as a core investigation area. (Microsoft Learn)
What to watch for:
In the SigninLogs schema, ConditionalAccessStatus records whether Conditional Access evaluation ended in success, failure, or notApplied. (Microsoft Learn)
Why it matters: suspicious access marked notApplied can be more revealing than access marked failure, because it may point to a policy gap rather than a blocked attack. In practice, this is one of the fastest ways to identify sign-ins that slipped through expected controls. (Microsoft Learn)
What to watch for:
In the SigninLogs schema, ClientAppUsed records the client type involved in the sign-in activity, including categories such as Browser, modern clients, IMAP, POP, SMTP, or MAPI. (Microsoft Learn)
Why it matters: the client type often exposes how the sign-in happened. Attackers frequently appear through unusual or legacy client paths that the user rarely touches in normal work. A suspicious client type can be especially meaningful when paired with a sensitive target resource or weaker-than-expected authentication.
What to watch for:
The IsInteractive field distinguishes interactive sign-ins from non-interactive ones. Microsoft also documents non-interactive user sign-ins as a distinct log type and an important part of Entra monitoring. (Microsoft Learn)
Why it matters: many identity attacks do not stop at the initial login. Once a token is available, later activity may shift into non-interactive access. That does not automatically mean malicious behavior, but it does tell the analyst they may no longer be looking at a human actively authenticating.
What to watch for:
Device-related fields help describe the platform or device context associated with the sign-in.
Why it matters: device context helps answer whether access came from a familiar environment or from something that does not fit the user’s normal profile. On its own, device information is not enough. But when combined with client, resource, and policy outcome, it can become a strong signal.
What to watch for:
Microsoft Entra sign-in data feeds identity protection and risky sign-in analysis. Microsoft’s documentation treats risky sign-in information as a core downstream use of sign-in log data. (Microsoft Learn)
Why it matters: sign-in risk is not a verdict, but it is a valuable context field. When elevated risk aligns with unusual client type, weak authentication, policy gaps, or non-interactive access, the combined signal becomes much stronger.
What to watch for:
Microsoft’s sign-in investigation model emphasizes not just who signed in and how, but also what the sign-in was targeting. In practice, ResourceDisplayName helps answer that question. (Microsoft Learn)
Why it matters: defenders often stop at the account and IP address, but a normal-looking sign-in to an unusual or sensitive resource can be highly suspicious. The target matters just as much as the identity.
What to watch for:
Microsoft’s current guidance on linkable identifiers specifically highlights Session ID (SID) as one of the most useful fields for investigating identity activity across Microsoft services. (Microsoft Learn)
Why it matters: Session ID is more useful than many analysts realize because it helps tie sign-in activity to related downstream actions in other Microsoft logs. That makes it powerful for both incident investigation and cross-workload tracing.
What to watch for:
Microsoft documents Unique Token Identifier in both sign-in activity details and the SigninLogs schema. It is used to correlate a sign-in with the token request and token activity at downstream resource providers. (Microsoft Learn)
Why it matters: this is one of the most valuable escalation fields in Entra investigations. It becomes especially useful when the question shifts from “was this login suspicious?” to “which exact token was involved, and where else was it used?”
What to watch for:
The biggest mistake is treating sign-in logs as simple access records. Username, IP address, and result code matter, but they rarely tell the full story on their own. The strongest detection value usually comes from combinations such as:
This is where basic triage becomes real detection.
Single-factor success to high-value applications
SigninLogs
| where ResultType == 0
| where AuthenticationRequirement == "singleFactorAuthentication"
| where AppDisplayName in ("Microsoft Exchange Online", "Microsoft SharePoint Online", "Microsoft Azure Portal")
| project TimeGenerated, UserPrincipalName, AppDisplayName, ClientAppUsed, ConditionalAccessStatus, IsInteractive
Suspicious non-interactive activity with policy gaps or risk
SigninLogs
| where IsInteractive == false
| where ConditionalAccessStatus == "notApplied" or RiskLevelDuringSignIn !in ("none", "")
| project TimeGenerated, UserPrincipalName, ResourceDisplayName, ClientAppUsed, ConditionalAccessStatus, RiskLevelDuringSignIn, SessionId, UniqueTokenIdentifier
Microsoft Entra sign-in logs already contain much of the context defenders need to spot identity abuse earlier. The gap is usually not telemetry. The gap is attention. Microsoft’s documentation makes clear that sign-in data includes authentication context, client details, target resource information, risk insights, and linkable identifiers that support deeper investigation across workloads. (Microsoft Learn)
Security teams that keep focusing only on usernames, IP addresses, and raw success or failure are leaving valuable signal on the table. The teams that get more value from Entra are the ones that read sign-in logs as full identity events, not just login records.
If you find ByteVanguard useful, you can support the site and help keep the analysis independent.
Support the analysis