Microsoft 365 / Users cannot sign in: troubleshooting and password reset

When a user cannot log in to Microsoft 365, instead of immediately resetting the password, first check error messages, account status, authentication steps, and the Microsoft Entra login logs. The solutions differ for password errors, Conditional Access blocks, multifactor authentication (MFA) failures, and license shortages.

Information to check with the user first

• The exact address and app used to attempt login, and the time and time zone of occurrence
• The error code and correlation ID on the screen, if any
• At which step the failure occurs, before or after entering the password
• Whether it is the same on other browsers or devices, and whether it is the same outside the company network
• Recent password changes, replacement of authentication app, or loss of mobile phone

Do not ask the user to send their password or authentication code. When capturing error screens, make sure to hide account names and organization information before sharing.

Match the investigation to the failed step

Check whether only a specific device of one person fails, or if the same department or entire organization fails simultaneously. If multiple people experience the same service error, check service status (Korean) as well. If successful in a private window, it can narrow down issues with remaining account sessions or client cache in the browser, but this alone does not determine the root cause.

Administrator troubleshooting steps

1. In the Microsoft 365 admin center, verify that the target account exists and is not blocked from login under [Users] → [Active users]. If only a specific service is not working, also check the licenses.
2. Filter users and time in [Entra ID] → [Monitoring & health] → [Sign-in logs] in the Microsoft Entra admin center. The actual menu translation may vary depending on your screen version.

3. Check the status of failed items, the reason for the error, authentication details, and Conditional Access results. Interpret based on Microsoft’s Sign-in activity details.
4. Select actions according to the cause of the error. If it’s a wrong password, reset it; if the authentication method is lost, recover the authentication method; if it’s blocked by policy, review the scope of that policy.
5. After taking action, sign in again under the same app, device, and network conditions, and check that a new successful sign-in event appears.

Microsoft’s Sign-in diagnostic feature also helps analyze failed sign-ins. If there is no attempt in the log, re-check whether the account and tenant used for sign-in are correct and whether the authentication request actually reached Microsoft Entra.

Items to read in the sign-in log

Use an appropriate log-reading role, such as Reports Reader. First limit users and the time range in which the events occurred, then narrow down the scope to the relevant app or resource. The screen time may be displayed in the time zone of the person viewing the admin center, so align the time and time zone as stated by the user. Since a request may be divided into multiple events, do not select the first row by just looking at one timestamp.

• Basic Information: Read the user, app, target resource, status, and reason for error together. Even for the same account, if the failed resources are different, they may be separate requests.
• Authentication Details: Check which authentication method failed, and whether the MFA requirement was satisfied with actual authentication or information from an existing token.
• Conditional Access: Check the name and controls of the failed policies. “Not applied” may mean the conditions of that policy were not met, and does not mean that there is no security protection.
• Report-only: Distinguish between policies that actually blocked access and the results of simulation evaluations. Do not conclude that a report-only failure is the current cause of the issue.

"If the web login works but only the file app fails on a company laptop," you should group the user, app, and device conditions as the same incident and compare them. If the cause is failing to meet compliant-device requirements, you need to correct the device registration and compliance status, and changing the password will not resolve it. Location estimates based on Internet Protocol (IP) addresses can be affected by virtual private networks (VPNs) or carrier routes, so a single location alone does not determine compromise or user location.

If there are no logs, slightly widen the filter and check the interactive and non-interactive login types. If there are still no logs, check whether a different tenant or personal account was used, or if the request did not reach the authentication stage. If you can start a login diagnosis in the event details, compare the recommendations with the actual logs.

When you need to reset a password

1. First, perform a user verification procedure. Do not reset the password solely because the request came via phone or chat.
2. Select the target in [Active users] and execute [Reset password]. Confirm the temporary password displayed and the requirement to change it at the next login.

3. Review the password creation method and the requirement to change it at the next login before finalizing the reset. Do not leave the displayed temporary password in public captures or work records.
4. Deliver the temporary password through an approved separate secure channel and ensure that the user has completed login and password change. If stored as a file for secure sharing, restrict access and handle it according to the organization's retention policy.

Do not base these instructions on an option to email passwords from the Microsoft 365 admin center. Microsoft has removed this feature, and the official procedure for password reset provides instructions for secure delivery. Check the Password Administrator permissions and target-account restrictions before delegating a reset. A role that can reset an ordinary user may not be allowed to reset a privileged account or a member of a role-assignable group.

Accounts synchronized with an on-premises directory may have different procedures depending on the source of the password change or password writeback configuration. If there are signs of suspicious logins or account compromise, do not stop at a simple reset; review sessions, authentication methods, administrator roles, and audit logs.

Criteria for deciding completion after the action

Have the user retry in the originally failed app, device, or network, and check the timestamps and success results in the new logs. Also verify whether email or files have actually been opened and work has resumed. Leave only the symptoms, events checked, items changed, and test results in the request record, and do not include passwords or authentication codes.

If a user has lost an authentication method, verify their identity and follow the organization’s approved authentication-method recovery process. If you find a suspicious new authentication method or a successful sign-in that the user denies, switch to the security incident response procedure. If you created a security exception to resolve an error, record its scope, expiration, and the person responsible for removing it, then restore normal protection after resolving the issue.