Sign-in error codes and diagnosis

Which codes mean Conditional Access, which only look like it, and how to tell them apart.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Sign-in failure codes and Conditional Access diagnosis

Accuracy rule. Error-code text and semantics change. Every code below must be treated

as a hypothesis generator, not a verdict. The authoritative lookup is

https://login.microsoftonline.com/error?code=<number>, and the agent should point users

there when precision matters. Never invent a code or restate one with more confidence

than this file carries.

Provenance

Canonical CA set — the six codes Microsoft publishes on

Troubleshooting sign-in problems with Conditional Access

(retrieved 2026-07-28). State these confidently:

Everything else in this file is adjacent — drawn from the general

Entra authentication and authorization error codes

reference and from field experience. Hedge those, and point to the lookup URL.

Diagnostic method — apply before reaching for any code

The code narrows the search. It rarely completes the diagnosis. Work in this order:

1. Was Conditional Access involved at all? Sign-in log → the sign-in → **Conditional

Access** tab. Each policy shows Success / Failure / Not applied / Report-only. If every

policy shows Not applied or Success, the cause is elsewhere — licensing, role

assignment, app configuration, or the account itself.

1. Which policy shows Failure? That is the policy to reason about. There may be more

than one.

1. Which condition matched? Compare the sign-in's client app, device state, location,

platform, risk level and user type against that policy's conditions.

1. Which grant control failed? MFA not satisfied, device not compliant, strength not

met, app not approved.

1. Could the user have satisfied it? Check registered methods, device enrolment,

compliance state. A user who cannot comply needs a different fix from one who

did not.

1. Smallest safe change. Fix the user or the device before you change the policy.

Changing a policy to unblock one person is how estates decay.

Codes that indicate Conditional Access

Two causes that are invisible from the error code alone

Both come from Microsoft's troubleshooting guidance and both produce blocks that look

unrelated to the policy causing them. Check these before concluding a policy is misbehaving.

Service dependency. The app the user opened is not the resource being called. Microsoft's

example: the application is Azure portal, the resource is Azure Resource Manager. A policy

targeting one but not the other blocks in a way that appears unconnected.

→ In the sign-in log, read the Resource field, not just the Application field. When a user

says "that policy doesn't even target this app", this is usually why.

Audience. Signing in to Teams requests access to multiple resources — Teams chat, Outlook

calendar, Excel documents. A SharePoint restriction fires during what the user experiences as

a Teams sign-in. Audience appears under the Resource section after selecting a policy on

the Conditional Access tab, and lists every resource requested.

→ This is the answer to "why is a SharePoint policy blocking Teams?"

Why a policy did or did not apply

Select the ellipsis beside a policy in the sign-in event. Left side = the values collected

at sign-in; right side = whether they satisfied the policy.

Conditional Access policies only apply when **all conditions are satisfied or not

configured**.

If the event is still not enough: Basic info → Troubleshoot Event runs the sign-in

diagnostic. The What If tool simulates a hypothetical sign-in.

Codes that look like Conditional Access but are not

Getting this differential right is a large part of the agent's value — these regularly get

misdiagnosed as CA problems and lead people to weaken policies that were never at fault.

If the CA tab shows no policy failure, stop treating it as a Conditional Access problem

and say so plainly.

Symptom-first table

Users usually describe a symptom, not a code.

Microsoft's information-collection list

For a user reporting a Conditional Access problem, Microsoft asks for:

user principal name · user display name · operating system name · timestamp (approximate is

fine) · target application · client application type (browser or client) · correlation ID

If the user sees a More details link on the error page, they can collect most of it

themselves. Correlation ID is the single most useful field — it identifies the exact sign-in.

Evidence request template

The agent should ask for exactly this, and nothing more:

From the Entra admin center → Entra ID → Monitoring & health → Sign-in logs, open the

failed sign-in and give me:

- Error code and failure reason

- The Conditional Access tab: which policies show Success, Failure, Not applied

- Client app, target resource

- Device ID, join type, compliance status

- Authentication requirement and authentication details

- User type, location

Do not send screenshots containing tokens, and do not send a full log export.

[VERIFY] portal navigation labels before asserting them as exact.

Output shape for troubleshooting

1. Symptom — restated, so the user can correct a misreading before the analysis
2. Most likely causes — ranked, with the reasoning for the ranking
3. Evidence to collect — only the fields that would discriminate between those causes
4. Analysis — which policy, which condition matched, which grant failed
5. Safe remediation — smallest change first; fix the user or device before the policy
6. Verification — how to prove it is fixed
7. What needs tenant inspection — stated explicitly, never implied