How to Investigate Failed Microsoft 365 Sign-Ins

One of the most common tickets an administrator receives is deceptively simple:

“I can’t log in.”

That statement doesn’t tell us very much.

An authentication problem could involve:

  • Incorrect credentials
  • MFA
  • Conditional Access
  • Device compliance
  • Account status
  • Authentication methods
  • Application access
  • Risk-based controls

Instead of immediately resetting the user’s password, investigate what actually happened.

Start with the Sign-In Event

Microsoft Entra provides administrators with sign-in information that can be invaluable when investigating authentication problems.

Find the affected user’s relevant sign-in attempt.

Pay attention to the timestamp.

If the user says:

“I couldn’t log in this morning.”

don’t spend your time analyzing an unrelated failure from two weeks ago.

What Application Was the User Accessing?

Determine what the user was trying to access.

Authentication problems can appear application-specific.

Understanding the target application helps establish the context around the failure.

Check the Status and Failure Information

Review whether the sign-in succeeded or failed.

If it failed, investigate the error details available for that event.

Don’t stop after finding an error code.

Find out what the error means in this particular authentication flow.

Check Conditional Access

Conditional Access is another major area to investigate.

A user may enter the correct username and password and still be denied access because an access policy isn’t satisfied.

For example, a policy could require:

  • MFA
  • A compliant device
  • An approved client
  • A particular authentication strength
  • Another access control

Review which policies were evaluated and their reported results for the relevant sign-in.

Check Device Information

If access depends on the endpoint, investigate the device context associated with the authentication event.

For example, imagine your Conditional Access policy requires a compliant device.

The user says:

“My password works, but Microsoft 365 still won’t let me in.”

The underlying issue may not be the password at all.

The device may have become non-compliant.

Now your troubleshooting path changes from:

Identity problem

to:

Endpoint compliance problem

That’s an important distinction.

Avoid the Password Reset Reflex

Resetting a password won’t fix every authentication problem.

It won’t necessarily solve:

  • Conditional Access failures
  • Device compliance problems
  • Missing MFA registration
  • Application restrictions

Changing credentials without understanding the root cause can also make the user experience more confusing.

A Better Investigation Workflow

I like to approach sign-in incidents in this order:

User → Time → Application → Authentication → Conditional Access → Device → Security context → Root cause

This provides a structured investigation.

Example Scenario

Imagine that Sarah reports:

“I can log into Microsoft 365 from my office laptop but not my home computer.”

That’s already a useful clue.

If credentials work on one device, investigate what differs between the two authentication attempts.

Perhaps the organization requires compliant managed devices for a particular Microsoft 365 resource.

The correct solution isn’t necessarily to reset Sarah’s password.

It is to understand why one device satisfies the access requirements while the other doesn’t.

Final Thoughts

Authentication troubleshooting should be evidence-driven.

Instead of asking only:

“Does the password work?”

ask:

“What happened during this specific sign-in attempt?”

Microsoft Entra ID gives administrators valuable information for answering that question.

And once you combine identity information with Conditional Access and endpoint management, complex Microsoft 365 login problems become much easier to understand.