Entra ID 53003: How to identify primary authentication when Authentication Details are empty?

We are investigating repeated interactive Microsoft Entra ID sign-ins with the following pattern:

- ErrorCode: 53003 (BlockedByConditionalAccess)

- isInteractive: true

- AppDisplayName: OfficeHome

- Authentication requirement: Multifactor authentication

Conditional Access correctly blocks these requests because they originate outside our trusted locations.

We have already confirmed through controlled testing that the authentication flow can reach 53003 after the correct credentials are provided. Our current problem is different:

We need to determine what mechanism satisfied the primary/first authentication factor for the observed 53003 events.

For these events, Authentication Details are empty:

- Authentication method: empty

- Authentication method detail: empty

- Result detail: empty

Therefore, we cannot determine whether primary authentication was performed using a password, an existing token/session claim, PHS, PTA, federation, Seamless SSO, or another mechanism.

Our questions are:

1. Is there any tenant-visible telemetry that can identify the primary authentication mechanism when AuthenticationDetails is empty?

2. Can fields such as AuthenticationProcessingDetails, AuthenticationProtocol, IncomingTokenType, OriginalTransferMethod, or AuthenticationMethodsUsed reliably distinguish between password validation and reuse of an existing authentication/token?

3. If additional authentication infrastructure is used:

- can PTA Authentication Agent logs be correlated using RequestId or CorrelationId?

- should Seamless SSO generate a corresponding Kerberos 4769 event for AZUREADSSOACC$?

- should federated authentication be traceable in AD FS logs?

4. For Password Hash Synchronization, is there any tenant-visible telemetry confirming that Entra ID actually validated the password for a specific sign-in request?

5. If this information is not exposed to the tenant, can Microsoft Support retrieve backend authentication telemetry for a specific Sign-in ID / RequestId / CorrelationId and determine how primary authentication was satisfied?

Our goal is not to determine why Conditional Access generated 53003 — that part is already understood.

We specifically need to identify what satisfied primary authentication before the Conditional Access evaluation.