Investigate a User's Sign-In Failures and Remediate Access Issues

When a user reports they can't sign in to Microsoft 365, the fastest path to resolution is a structured investigation: locate the account, review recent sign-in telemetry, identify the failure signature, and apply a targeted fix. Jumping straight to a password reset without reading the logs often masks the real issue (MFA gap, Conditional Access block, legacy auth attempt, risky sign-in lockout, or a disabled account).

This recipe walks through the standard triage flow used by the Dex CoAdmin troubleshooting skill. The example scenario — a user blocked by error AADSTS53003 ("MFA required but not completed") because they have no MFA method registered — is one of the most common patterns, but the same investigation pattern applies to account lockouts, Conditional Access blocks, expired passwords, and risky sign-in quarantines.

Run this recipe when:

• A user submits a "can't log in" ticket
• A helpdesk escalation mentions MFA prompts failing
• You see a spike in failed sign-ins for a specific account in the Entra dashboard
• Security flags risky sign-in activity on an account

After completing this recipe you will have:

• Confirmed the target user's account state (accountEnabled, UPN, object ID)
• A summary of the last 25–50 sign-in attempts with error codes, failure reasons, apps, IPs, locations, and risk signals
• An identified root cause (MFA gap, bad password, Conditional Access block, risky sign-in, legacy auth, disabled account, etc.)
• An appropriate remediation applied — typically one or more of: password reset with forced change, MFA method reset, session revocation, or account re-enablement
• Verification that the fix worked (new successful sign-in or the user confirming access)
• An audit trail of every action taken (Graph API calls, approval records, before/after state)

Before you remediate:

• Verify identity. Never reset a password or revoke sessions based on an email request alone. Confirm the requester is the real user (callback to their known mobile, manager confirmation, or a verified ticket system).
• Read the logs first. Resetting a password won't fix a Conditional Access block, a disabled account, or a missing license. Misdiagnosis wastes time and can alarm the user unnecessarily.
• Check for compromise indicators. Sign-ins from unusual countries, impossible travel, or high risk levels may indicate a compromised account. Escalate to security rather than just resetting the password — a malicious actor may still hold the recovery channels.
• Communicate the temporary password out-of-band. Send via SMS, voice call, or an authenticated chat channel — never via the user's own mailbox (they can't read it) and never plaintext in a ticket.

Compliance considerations:

• Password resets and session revocations are logged in the Entra audit log and are discoverable. Include a business justification in ticket notes.
• Some regulated environments (PCI, HIPAA) require a second approver for privileged account password resets. Check your policy before running the recipe against an admin account.
• Do not disable MFA as a "fix" — reset the methods and have the user re-register. Disabling MFA creates a standing security gap.