How Conditional Access evaluates a sign-in
Step through a single sign-in to see where Conditional Access looks, what it decides and where the common errors come from.
The user opens an app
Jane opens SharePoint in her browser. She isn't signed in, so the app sends her to Entra ID to sign in, saying which app she wants and what it needs access to.
All the steps
Jane opens SharePoint in her browser. She isn't signed in, so the app sends her to Entra ID to sign in, saying which app she wants and what it needs access to.
The request names the app (its client ID) and the resource. Conditional Access policies target these, which is why the same user can get different prompts in different apps.
She signs in with her first factor. With a passkey this already counts as phishing-resistant MFA. A wrong password ends here with AADSTS50126, before Conditional Access is involved.
Who she is and which groups and roles she has, which app, her public IP and named location, the device and whether it's compliant, the client type, and with P2, the sign-in and user risk.
Each enabled policy whose assignments and conditions match is applied. There's no order or priority. Report-only policies are evaluated too, but only logged. Exclusions always beat inclusions.
If any applicable policy says block, the sign-in fails with AADSTS53003, whatever the other policies say. That's why break-glass accounts must be excluded from every policy.
Every applicable policy's grant controls must be met. If MFA or an authentication strength is required and not yet satisfied, Jane is prompted. Device controls can't be prompted for: a non-compliant device fails with AADSTS53000.
With every grant control satisfied, session controls such as sign-in frequency, persistent browser and app enforced restrictions are applied to the session.
SharePoint gets its tokens. The sign-in log records every policy that applied, whether it passed or failed and which controls were used. That's the first place to look when something is blocked.