The account is enabled, the password is right, the licence is there, and the person still cannot get in. Checking the account again will not help, because the account is not the problem.

Ask Avvi for their failed sign-in attempts instead. Each one carries a reason, and where a policy blocked the attempt, the reason names the policy.

The failed sign-in request usually ends the investigation, and it is the one people reach for last.

Symptom

Sign-in fails for one person while everything about their account looks correct.

Colleagues on the same licences and the same groups sign in normally.

Cause

A conditional access policy is the commonest answer: a rule about location, device state, or how the person is authenticating.

The second is device compliance. A machine that has fallen out of compliance is refused by a policy that requires it, and nothing about the account changes.

The third is the client’s own policies applying to a situation the person is in today and was not in yesterday, such as travelling.

Fix

1. Ask Avvi for the person’s failed sign-ins. For example: show failed sign-ins for jane@example.com.
2. Read the reason on the most recent failures, and note any policy named.
3. If a policy is named, ask Avvi to list the client’s conditional access policies and find it.
4. Read what that policy requires against what the person is doing.
5. Resolve it on the client’s side, or have them meet the condition.

The failure reason is the evidence. Anything you conclude without it is a guess.

If something doesn’t look right

If there are no failed sign-ins at all, the attempt is not reaching Microsoft. Check whether they are using the right address, and whether they are being stopped somewhere earlier.

If the reason is generic, look at the device rather than the account. Compliance is the usual explanation for a block with little detail.

If the client has no Microsoft Entra ID P1 or P2, sign-in history is unavailable and this route is closed. Say so plainly rather than guessing at causes.

If policies changed recently on that client, that is worth asking about before investigating further.

To escalate, open a support conversation from the Help drawer with the client, the person, the failure reason and any policy named.

FAQ

Q: Where do I start?

A: The failed sign-ins. Not the account.

Q: The reason names a policy I did not create.

A: Policies are the client’s. Read what it requires before changing anything.

Q: Nothing is recorded at all.

A: The attempt may not be reaching Microsoft, or the client may lack the licensing for sign-in history.