Which Microsoft Entra Sign-In Log Fields Actually Matter?

When you open a Microsoft Entra sign-in event, the challenge is rarely finding information.

The challenge is knowing which information matters to the problem you are investigating.

A sign-in event can contain identity, authentication, client, device, location, application, resource, Conditional Access, risk, and correlation information. But you rarely need every field for every investigation.

The better approach is simple:

Start with the question. Then choose the fields that can answer it.

1. Start With the Investigation Question

Think of a sign-in investigation as:

Question → Relevant fields → Evidence → Next question

For example:

Did the sign-in fail? → Status + Error code

Or:

flowchart TD

    A["Why did Conditional Access block it?"]
    B["Conditional Access"]
    C["Applicable policies"]
    D["Policy result"]
    E["Unmet requirement"]

    A --> B
    B --> C
    C --> D
    D --> E

The goal is not to memorize the entire sign-in schema.

It is to know which fields are useful for the question in front of you.

2. Did the Sign-In Fail?

Start with

Status

Then inspect:

• Error code
• Failure reason
• Additional details

A useful investigation path is:

Status → Error code → Failure reason → Additional details

Status tells you the outcome, but the outcome alone does not explain the cause. A failure can involve Conditional Access, authentication, credentials, device conditions, sessions, applications, or user actions.

Treat Status as the starting point, not the diagnosis.

3. What Does the Error Code Tell Me?

Start with

Error code

Error codes can narrow the investigation.

These codes provide useful clues, but they should be interpreted with the rest of the event rather than treated as a complete diagnosis.

For example:

53003 → Conditional Access → Inspect applied policies

4. How Did the Request Arrive?

Two fields are particularly useful here.

Client app

Identifies the client category involved in the sign-in.

This can help distinguish modern client activity from legacy authentication paths such as Exchange ActiveSync, IMAP, MAPI, SMTP, and POP.

Authentication protocol

Provides more information about the authentication flow itself.

Depending on the scenario, this can include protocols and flows such as OAuth 2.0, SAML, WS-Federation, device code, client credentials, refresh token grant, Kerberos, PRT grant, seamless SSO, and on-behalf-of flows.

Use them together when the question is:

“What kind of request was this, and how did it authenticate?”

5. What Authentication Actually Happened?

Start with

Authentication requirement
Authentication details

Authentication requirement describes the requirement associated with the sign-in, while Authentication details provides evidence about the methods and steps that actually occurred.

For example:

flowchart TD

    A["Password"] --> B["Success"]

    C["MFA"] --> D["User declined"]
    D --> E["Sign-in fails"]

    B --> E

or:

flowchart TD

    A["Password"] --> B["Success"]

    C["MFA"] --> D["Satisfied by token"]

    B --> E["Conditional Access"]
    D --> E

    E --> F["Access granted"]

The important question is:

“What authentication method was actually used, and what happened at each step?”

6. What Device and Location Were Evaluated?

Start with

Device information
Location

Device information can include:

• Browser
• Operating system
• Device ID
• Device display name
• Compliance state
• Managed state
• Trust type

These fields are particularly important when a Conditional Access policy requires a device condition.

Location can provide:

• IP address
• City
• State
• Country or region
• Geographic information

But network information has limitations. VPNs and proxies can affect the network identity Microsoft Entra evaluates.

IP geolocation is a signal, not proof of physical location.

View larger

Image detail

−100%+Reset✕

7. What Was the User Trying to Access?

Start with

Application
Resource

These are related but are not necessarily the same thing.

Sign-in information can include the application, application ID, resource, resource ID, resource tenant, and resource service principal.

A useful model is:

Application → Authentication → Resource → Access decision

This distinction becomes valuable when an application appears to work normally but a particular service or resource does not.

8. Why Did Conditional Access Intervene?

Start with

Conditional Access

Then investigate:

• Which policies applied?
• Which policies did not apply?
• Which requirements were satisfied?
• Which requirements failed?
• Was the result enforced or Report-only?

The investigation path is:

Sign-in event → Conditional Access → Applicable policies → Policy result → Unmet requirement

One important point:

A policy showing Success does not necessarily mean the overall sign-in succeeded.

Another applicable policy can still introduce a requirement or block access.

9. Was the Sign-In Risky?

Start with

Risk

Useful risk information can include:

• Sign-in risk
• Aggregated risk
• Risk state
• Risk detail
• Risk event types

Signals can include password spray, anonymous IPs, unfamiliar sign-in properties, anomalous tokens, and impossible or atypical travel.

For administrators, risk can help explain why a risk-based Conditional Access policy introduced an additional requirement.

For security teams, it can help prioritize investigations.

10. How Do I Correlate the Event?

Start with

Correlation ID
Request ID

They serve different purposes.

Correlation ID helps connect related activity around the broader sign-in session.

Request ID is useful for correlating a more specific request or token context.

A simple model is:

Correlation ID → Broader sign-in session

Request ID → Specific request / token context

When escalating a difficult authentication issue, retain both when available.

11. Read the Fields Together

Individual fields rarely provide the complete answer.

Consider:

flowchart TD

    A["Status"] --> A1["Failure"]

    B["Error code"] --> B1["53003"]

    C["Conditional Access"] --> C1["Policy blocked"]

    D["Device"] --> D1["Non-compliant"]

    E["Authentication details"] --> E1["MFA succeeded"]

    F["Resource"] --> F1["SharePoint"]

    A1 --> G["Sign-in failure"]
    B1 --> G
    C1 --> G
    D1 --> G
    E1 --> G
    F1 --> G

The conclusion is much more useful than simply saying:

“Conditional Access blocked the user.”

The evidence shows that MFA succeeded, but the device requirement was not satisfied.

This is the real value of sign-in logs: connecting individual fields to reconstruct the access decision.

View larger

Image detail

−100%+Reset✕

12. The Quick Field-Selection Guide

When you are investigating an event, start here:

This gives administrators a practical starting point without requiring them to memorize the entire schema.

13. A Practical Investigation Sequence

When you do not know where to begin, use this sequence:

flowchart TD

    A["Sign-in event"]

    B["What happened?"]
    B1["Status + Error"]

    C["How did it happen?"]
    C1["Client + Protocol + Authentication"]

    D["What surrounded the request?"]
    D1["Device + Location"]

    E["What was being accessed?"]
    E1["Application + Resource"]

    F["Why was the decision made?"]
    F1["Conditional Access + Risk"]

    G["How do I connect related events?"]
    G1["Correlation ID + Request ID"]

    A --> B
    B --> B1

    A --> C
    C --> C1

    A --> D
    D --> D1

    A --> E
    E --> E1

    A --> F
    F --> F1

    A --> G
    G --> G1

This is a selection strategy, not a requirement to inspect every field.

Conclusion — Ask the Question First

A Microsoft Entra sign-in event can contain a large amount of information.

An effective investigation does not begin by reading everything.

It begins with a question.

What am I trying to determine?

Then select the fields that can provide the evidence.

Question → Field → Evidence → Next question

If you need to know whether the request failed, start with Status and Error code.

If you need to understand authentication, start with Authentication requirement and Authentication details.

If Conditional Access is involved, inspect applicable policies and their requirements.

If the question is about the surrounding context, look at Device and Location.

If you need to understand the target, inspect Application and Resource.

And when the investigation needs to extend beyond the individual event, retain the Correlation ID and Request ID.

Don’t ask, “Which fields are available?” Ask, “Which fields can answer my question?”

That is the difference between reading a sign-in log and investigating one.