Password was correct, login still flatly refused - the cause was multi-factor auth that had never been registered

A user reported repeated failures logging into the Microsoft 365 portal, with the password double- and triple-checked as correct each time. This kind of “credentials are correct, but login still fails” situation, if investigated by focusing only on the account itself (resetting the password, unlocking the account), can easily waste time - because the problem may not be at the credential layer at all.

Using the built-in diagnostic tool instead of guessing

Rather than guessing possible causes one by one based on experience, the more efficient move was going straight to the admin center’s built-in Sign-in Diagnostic tool to see the detailed analysis of this specific failed login. The diagnostic result gave a direct error code and explanation: “Access has been blocked by one or more access control policies configured to block” - meaning this wasn’t a credential problem at all; an access control policy had actively stepped in and blocked the login.

Rather than guessing blindly at “login failed,” let the system tell you why

Following the diagnostic result to the specific policy

Opening the access control policy detail for this login event confirmed the block came from the tenant’s Security Defaults baseline policy, with the policy status “Enabled” and its verdict on this login set to “Block” outright, rather than something more lenient like requesting additional verification. Every condition listed in the diagnostic detail (device platform, sign-in location, client app, etc.) showed “Not configured” - meaning the block wasn’t triggered by any specific risk condition, but by the policy’s overall judgment of this account’s status.

One of Security Defaults’ core requirements is that every account must complete multi-factor authentication registration, within a given grace period. Combined with the fact that this account had never completed MFA device registration, the picture was clear: the login was blocked because the account had exceeded the MFA registration grace period, not because anything was wrong with its credentials.

The fix

The user was walked through the multi-factor authentication device registration process (linking an authenticator app or a phone verification method). Once registered, the account satisfied the Security Defaults policy’s requirements, and login worked normally again.

Lessons

1. “The password is correct” and “can the account log in” are not fully the same thing. Modern identity systems, after verifying credential correctness, often layer on an additional policy judgment (has MFA been completed, is the device trusted, etc.) - correct credentials are a necessary condition for a successful login, not a sufficient one;
2. When facing a login problem, use the system’s own built-in diagnostic tool first, rather than troubleshooting by intuition. The diagnostic tool here gave a direct error code and explanation, saving significant time that would otherwise go into elimination-by-guessing (“could it be the password,” “could the account be locked”);
3. A baseline security policy’s outright “Block” looks like a fault, but it’s actually the policy doing its job correctly. The fix for this class of problem isn’t “work around the policy” - it’s “bring the account into compliance with the policy” (completing MFA registration, in this case). Recognizing this early avoids wasted effort chasing a “fault” that was never actually there.