Entra ID Sign-in Logs Using the Same Request ID (Interrupted → Success/Failure)

Question

Hi Team,

I am observing a recurring pattern in Azure AD / Entra ID Sign-in logs where two different entries are generated with the same Request ID for a single user authentication attempt.

The behavior is as follows:

• The first log entry is recorded as Interrupted

The second log entry appears as Success or Failure

Both entries use the same Request ID

This behavior occurs even during normal, non-risky sign-in attempts

I would like to understand the following:

Is it expected behavior for Entra ID to log an Interrupted event first and then log the final Success/Failure result using the same Request ID?

Is the second entry created due to additional backend checks such as MFA evaluation, Conditional Access policies, token validation, session establishment, or automatic retry attempts?

When this occurs, what is the typical or expected time interval between the Interrupted entry and the final Success/Failure entry?

Under which scenarios does Entra ID generate this Interrupted → Success/Failure pattern?

Should this two-log sequence be considered normal platform behavior, or does it indicate an issue we should investigate?

Additionally, I would like to clarify whether Entra ID is actually updating the original Interrupted log after completing internal checks, or if it is intentionally creating a separate second log entry with the same Request ID. Understanding this difference is important for accurately interpreting and consolidating sign-in logs in reporting and audit workflows.

Any guidance or clarification on how to properly understand and handle these log sequences would be greatly appreciated.

Thanks.

Answer 1

Hello Monalisha,

Thank you for the clarification.

I have one more question related to this behavior. For a single Request ID, Entra ID generates two sign-in log entries (Interrupted and Success/Failure). I need to retrieve only the latest entry. How can I query the sign-in logs so that only the final (second) entry is returned? Is there a supported Microsoft Graph API filter, orderBy parameter, or query method that allows me to retrieve only the most recent log event for a given Request ID? I have tried fetching the record using the Graph API as well, but it returns both entries.

Answer 2

Hello Louis,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I will try to clarify your doubts regarding this issue and help you out with some solutions.

So, yes, this Interrupted; Success/Failure pattern with the same Request ID is expected when Conditional Access, MFA, or other checks occur. Entra ID does not update the original log, it creates a second entry for audit integrity. Use Request ID to correlate both entries. No investigation is needed unless the second entry is missing or shows repeated failures.

The solution is to treat the two-log sequence as a single, correlated transaction for reporting and audit purposes, using the Request ID as the definitive linking identifier.

1. Behavior and Logging Clarification

Is it expected? Yes, this is normal platform behavior for any interactive sign-in protected by MFA, Conditional Access, or other policies requiring user input after the password check.

Logging Method: Entra ID intentionally creates a separate second log entry with the same Request ID. The original Interrupted log entry is not updated. This logging separation allows auditors to see both the required challenge and the final outcome of that challenge.

Time Interval: The time interval is dynamic. It is determined by the user interaction latency (how quickly the user responds to the MFA prompt, etc.) and can range from a few seconds to several minutes.

2. Scenarios Causing the Pattern

This pattern is generated in scenarios that require a secondary interactive security check:

Multi-Factor Authentication (MFA): The user successfully enters a password but is then prompted for a second factor (e.g., Authenticator app push).

Conditional Access (CA) Compliance Checks: A CA policy is applied that requires the user to accept Terms of Use, register their device, or complete a device health check before a token is issued.

Session Control Prompts: The system prompts the user with the "Keep me signed in?" (KMSI) option, which requires user interaction.

Password Reset/Change: The sign-in is interrupted to force a mandatory password change due to expiration or a policy requirement.

Do refer below docs foe better understanding:

https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins

https://learn.microsoft.com/en-us/entra/identity/conditional-access/troubleshoot-conditional-access

Hope this helps! If it answered your question, please consider clicking Accept Answer and Upvote. This will help us and others in the community as well.

If you need more info, feel free to ask in the comments. Happy to help!

Regards,

Monalisha