A user at Proseware calls the helpdesk reporting they cannot sign in to Microsoft 365. The error message displayed is 'Your account has been locked.' The admin needs to quickly determine whether the lockout is caused by Microsoft Entra Smart Lockout triggering due to too many failed attempts, or whether an administrator has explicitly disabled the user's account. Where should the admin look first to get this information?
Select an answer to reveal the explanation.
![Portrait infographic (2048x1536) titled 'Diagnosing Account Lockouts with Entra Sign-in Logs'. Top section shows a support scenario: stick figure user at a laptop with a red lock icon and speech bubble 'Your account has been locked.' Below, a decision diagram showing the question 'Smart Lockout OR Admin Disabled?' with two branches. Center panel shows a screenshot mock-up of the Microsoft Entra Sign-in logs interface: table with columns UPN, Status (red Failed badge), Error Code, Failure Reason. Two rows highlighted: one showing 'Error 50053 — Account locked by Smart Lockout' and another showing 'Error 50057 — Account administratively disabled'. Left branch from 50053: remediation steps 'Wait for lockout to clear OR reset via Entra portal'. Right branch from 50057: remediation steps 'Re-enable account under Users > [User] > Account status'. Bottom shows a tip box: 'Sign-in Logs retention: 7 days (Free) / 30 days (P1/P2)'. Color scheme: Microsoft blue, red for error states, green for resolved states, yellow for tips. Include magnifying glass search icon over log entries.](/media/microsoft/ab-650/AB-650-e2-q020.webp)
Short Explanation
Sign-in logs are your flight recorder for authentication attempts. Filter by the user's UPN and check the failure reason: 50053 means Smart Lockout, while 50057 means an admin disabled the account. That gives you the exact cause without guessing.
Full Explanation
The Microsoft Entra Sign-in logs (Monitoring > Sign-in logs) record every authentication attempt with rich details including the UPN, timestamp, application, IP address, and critically — the failure reason and error code. For locked accounts, error code 50053 indicates Smart Lockout triggered due to too many failed sign-in attempts from locked IP addresses or too many failed passwords. Error code 50057 indicates the user account has been administratively disabled. These two root causes produce the same user-facing error message but require completely different remediation, so inspecting the sign-in logs is the definitive starting point. Admins can filter by User UPN and Status = Failure to narrow results quickly.
The Microsoft 365 admin center account properties page shows whether users' accounts are blocked for sign-in (administratively disabled), but it does not show Smart Lockout state or the specific error that triggered failed authentication. It also doesn't provide the granular failure reason codes needed to distinguish between the two scenarios. It's a reasonable later step once you know the cause, but not the richest initial source.
The Audit log records administrative actions taken on objects (user creation, license changes, group membership changes, policy updates), not user authentication events. Smart Lockout events or failed sign-in attempts do not generate Audit log entries — that information lives exclusively in Sign-in logs.
Get-MgUserAuthenticationMethod returns the list of registered authentication methods for users (phone, Authenticator app, FIDO2 key, etc.). This is useful for diagnosing MFA registration issues, but tells you nothing about why sign-in attempts failed or whether accounts are locked. It's the wrong tool for this symptom.
Exam tip: Know the distinction between Sign-in logs (authentication events, error codes, risk signals) and Audit logs (admin actions on directory objects). Questions about investigating sign-in failures, error codes, or lockouts always point to Sign-in logs. Sign-in logs are retained for 30 days with Microsoft Entra ID P1/P2, or 7 days with free tier.