Device code sign-in in Entra External ID: sign-in logs show only “Previously satisfied”, no password/Email OTP steps

The current record does not prove that password and Email OTP were completed; wait up to two hours for sign-in aggregation, then treat a still-unchanged “Previously satisfied / MFA requirement satisfied by claim in the token” entry as evidence that the logged token request reused an MFA claim, not as evidence of newly completed factors.^1^

Where the authentication steps should appear

For this browser-delegated device-code flow, authentication occurs in the browser at the verification URI; the public client only polls the token endpoint.^2^ The relevant per-step report is therefore the user’s sign-in log, primarily:

Entra admin center → Entra ID → Monitoring & health → Sign-in logs → event → Authentication Details

That tab is intended to show:

• the sequence of authentication methods;
• whether each attempt succeeded;
• why it succeeded or failed;
• whether MFA was completed or satisfied by an existing token claim.^3^

Check both Interactive user sign-ins and Non-interactive user sign-ins, grouping records by correlationId. Also retain requestId, sessionId, and the unique token identifier: correlation IDs group related requests but depend on client-supplied values, while request IDs correspond to issued tokens.^3^

Audit logs are not the normal per-step MFA report. They are useful for determining whether a nearby email-code operation belonged to password reset, method registration, or another directory workflow.

Why “Previously satisfied” is not proof of two newly completed factors

External tenants support exactly the described combination: Email with password as the first factor and Email OTP as the second factor. In that flow, the user signs in with the primary method, requests the emailed code, and enters it within ten minutes.^4^

If those operations are represented completely, Authentication Details should contain the method sequence rather than only a token-claim row. However, sign-in details are asynchronously aggregated. Microsoft documents two relevant temporary inaccuracies:

• “Satisfied by claim in the token” can initially be displayed incorrectly.
• The Primary authentication row can initially be absent.^1^

MFA records can take up to two hours to aggregate, although that is uncommon.^5^ Therefore, the JSON export at 50 minutes was not yet definitive.

After two hours:

• Password and Email OTP rows with successful results support fresh completion.
• A remaining sole Previously satisfied / satisfied by claim in the token row supports claim reuse for that logged request.
• authenticationRequirement = multiFactorAuthentication and Conditional Access success establish that the access requirement was met, but not how it was met. Microsoft explicitly warns not to rely on authenticationRequirement alone when an earlier MFA claim may have been accepted.^1^

A new sessionId, session revocation, the reported UI experience, or receipt of an email does not substitute for successful per-step records. Revoking sessions invalidates refresh tokens, but already-issued access or session tokens remain effective until their applicable expiration.^6^

Distinguishing MFA Email OTP from reset or registration

Correlate the sign-in event with the audit logs by user and timestamp:

1. Open Entra ID → Users → Audit logs.
2. Filter Service = Self-service Password Management.
3. Look for activities such as password-reset flow progress or self-service password reset.
4. For method registration, inspect Security → Authentication Methods events.^7^

SSPR has a distinct journey: the user selects Forgot password?, verifies using Email OTP or SMS, and is then prompted to create a new password.^8^ Registration likewise has dedicated audit activities such as User started security info registration and User registered security info.^9^

Thus:

• Email OTP in Authentication Details for the correlated sign-in, without reset/registration audit activity, supports MFA use.
• Reset-flow audit activity supports SSPR use.
• Authentication Methods registration activity supports method verification or registration.
• mfaDetail.authMethod = "Email verification code" alone does not establish which business flow generated the code; correlate it with these records.

The earlier AADSTS50072 means that the user needed to enroll for second-factor authentication; it does not prove successful enrollment or successful MFA in the later event.^10^

Obtaining more detail without new permissions

There is no documented field, separate MFA activity report, or Graph endpoint that reconstructs authentication steps absent from the finalized sign-in record. The supported actions are:

1. Wait until two hours after the event and export the complete JSON again.
2. Review every interactive and non-interactive record for the user, time range, application, and correlation ID.
3. Review the corresponding SSPR and Authentication Methods audit events.
4. If diagnostic settings were already sending logs to Log Analytics, query all records by correlation ID. Log Analytics can retain intermediate requests that the portal merges into one final event.^11^

SigninLogs
| where CorrelationId == "<correlation-id>"
| order by CreatedDateTime asc
| project CreatedDateTime, Id, IsInteractive,
          ResultType, ResultDescription,
          AuthenticationRequirement, AuthenticationDetails

This helps only if Azure Monitor export was configured when the sign-in occurred. It cannot recover earlier intermediate records retroactively.

Microsoft Graph returns the sign-in record rather than a richer hidden authentication trace and requires AuditLog.Read.All plus a supported directory role for administrative access.^12^ If those permissions are not already available, there is no documented permission-free API alternative. If the record remains incomplete after aggregation and Log Analytics was not enabled, open a Microsoft support case with the UTC timestamp, tenant type, user object ID, application ID, correlation ID, request IDs, and sanitized JSON exports.

References

1. Use the sign-in logs to review Microsoft Entra multifactor authentication events
2. Microsoft identity platform and the OAuth 2.0 device authorization grant flow
3. Learn about the sign-in log activity details
4. Multifactor authentication in external tenants
5. Frequently asked questions around Microsoft Entra monitoring and health
6. Revoke user access in Microsoft Entra ID
7. Reporting options for Microsoft Entra password management
8. Enable self-service password reset
9. Microsoft Entra audit log categories and activities
10. Microsoft Entra authentication and authorization error codes
11. Analyze Microsoft Entra activity logs with Log Analytics
12. Get signIn