Forum Discussion
PM321123
Sep 27, 2026Copper Contributor
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...
WinEndpointOps
Oct 24, 2026Brass Contributor
Empty authentication details on a 53003 are expected more often than not. That list is filled in as each step completes, and when Conditional Access blocks the request, the log often records the block before any method detail is written. So an empty field does not tell you the primary factor, but you can usually work it out from other evidence:
- Look at the other events with the same CorrelationId or SessionId. Earlier events in that session, such as a 50074 or 50076 (MFA required), only appear after primary authentication succeeded, and a prior successful event may show the method. Also check the non-interactive sign-ins and the service principal tabs for the same session, which are easy to miss.
- Compare these fields across events (Graph signIns, or the JSON view): tokenIssuerType (Microsoft Entra ID versus federated, which points at ADFS), incomingTokenType, authenticationProtocol, originalTransferMethod, and the user agent and client app. A federated sign-in shows ADFS as issuer, and a session or token reuse tends to show an existing token type instead of a fresh credential.
- Check the infrastructure on the other side. For Seamless SSO, the domain controller should log a Kerberos service ticket request (event 4769) for AZUREADSSOACC$ at the same time. For PTA, check the Authentication Agent event log on the agent servers around the timestamp, since agent logs do not carry the Entra CorrelationId so you have to match by time and user. For federation, check the ADFS Admin and Security logs the same way.
- Check Entra ID Protection risk detections for the same user and IP, such as password spray, unfamiliar sign-in properties or anomalous token.
One more point: if the credentials were valid and the request came from outside your trusted locations, I would treat it as a possible credential compromise even though Conditional Access stopped it. Reset the password, revoke sessions, and review that user's sign-ins for the following days.