Get the facts from the sign-in log
Ask the user for the Correlation ID and timestamp from the error page. Then, in the Entra admin center, go to Monitoring → Sign-in logs and filter by user and time. The Conditional Access and Authentication details tabs explain most failures.
With logs in Log Analytics:
SigninLogs
| where TimeGenerated > ago(24h) and UserPrincipalName =~ "user@contoso.com"
| project TimeGenerated, AppDisplayName, ResultType, ResultDescription, ConditionalAccessStatus, IPAddress, ClientAppUsed, DeviceDetail
| order by TimeGenerated desc
ResultType is the AADSTS number without the prefix. 0 means success.
The codes you'll see most
| Code | Meaning | Fix |
|---|---|---|
| 50126 | Invalid username or password | Reset the password. Check whether they use the right UPN or an old alias. |
| 50053 | Account locked (smart lockout) or sign-in from a malicious IP | Wait for the lockout to expire, then check for password-spray attempts in the logs |
| 50057 | User account disabled | Enable the account, and check HR offboarding automation |
| 50055 / 50173 | Password expired / grant revoked after a password change | Have the user change the password and sign in again |
| 50076 / 50079 | MFA required / MFA registration required | The user completes MFA or registers a method |
| 50074 | Strong authentication required, but the client can't do it | Use a modern-auth client. Legacy protocols can't do MFA. |
| 53000 | Device not compliant or not registered (Conditional Access) | Enroll in Intune or bring the device into compliance |
| 53003 | Blocked by a Conditional Access policy | Check which policy failed in the CA tab |
| 50105 | User not assigned to the application | Assign the user or group under Enterprise app → Users and groups |
| 65001 | Consent not granted for the app | An admin grants consent, or the user consents if allowed |
| 700016 | Application not found in the tenant | Wrong tenant or client ID, or the app isn't provisioned there |
| 7000215 / 7000222 | Invalid or expired client secret | Rotate the secret in the app registration and update the app |
| 90072 | External user's account doesn't exist in this tenant | Invite them as a B2B guest, or redeem the invite |
| 50158 | External security challenge not satisfied | Third-party MFA or CA challenge failed |
| 500121 | Strong authentication failed (MFA denied or timed out) | Re-register MFA, check phone/app, and watch for MFA fatigue attacks |
Conditional Access "what if"
Before you change a policy, test the user's situation in Conditional Access → What If with their user, app, platform, location and client app. It shows which policies would apply and why.
Caution
Never fix a Conditional Access block by excluding the user permanently. Use a time-limited exclusion group with an owner and an expiry date, or fix the device or location issue instead.
Service principals and automation
For pipelines and apps (client credentials), look in Service principal sign-ins, not user sign-ins. Most failures there are expired secrets or certificates (7000222, 7000215) or the wrong tenant (900023 for an invalid tenant).
az ad app credential list --id <appId> --query "[].{name:displayName,end:endDateTime}" -o table
Prevent it next time
- Alert when app secrets and certificates are within 30 days of expiry.
- Turn on self-service password reset and combined MFA registration.
- Review the sign-in logs for repeated 50126 and 50053 failures from the same IPs. That pattern is password spraying.