Find the Conditional Access policy blocking a user sign-in

TL;DR — When a user is blocked by Conditional Access, the fastest path is: pull the user's latest sign-in log entry, inspect the Conditional Access evaluation on that event, and read the policy result from the sign-in details instead of guessing from policy names or group membership. The most common root cause is a broad policy targeting the user via nested/dynamic group membership or a location/device/app condition you did not realize matched. Reading time: ~6 min

The scenario

You get a Tuesday-afternoon Slack from a PM: one user cannot sign in to the app that uses your tenant for SSO, but everyone else can. The user swears nothing changed; your app logs only show an upstream auth failure, and the identity admin says, "I can see Conditional Access blocked it, but I can't tell which policy." The sign-in happened minutes ago, the user is remote, and leadership wants to know whether this is a one-off or a broken rollout. You need the exact blocking policy, not a theory.

Symptoms

• User sees one of these during sign-in:
  • "You can't get there from here"
  • "Your sign-in was blocked"
  • "You do not have access to this resource"
  • "Additional authentication required" followed by failure or loop
• App side shows upstream auth failure, often as a generic OIDC/SAML error:

AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

• Sometimes you also see:

AADSTS50105: Your administrator has configured the application to block users unless they are specifically granted access.

AADSTS53000: Device is not in required device state.

AADSTS53001: Device is not domain joined.

AADSTS53004: Proof up required due to sign-in risk or device/location policy.

• In identity provider sign-in logs, the event shows:

Status: Failure
Failure reason: Access has been blocked due to Conditional Access policies.
Conditional Access: Failure

• The "Conditional Access" section on the sign-in may show multiple policies with mixed results such as not applied, report-only: failure, success, and one failure.
• Helpdesk/admin confusion usually looks like this:
  • User is in the expected allow group, but still blocked.
  • Policy names are similar and several target the same cloud app.
  • A report-only policy is blamed even though it did not enforce.

Likely causes

Step-by-step diagnosis

1. Find the exact failed sign-in event for the user.
   • In your identity provider admin portal, open the user's recent sign-ins and filter to Status = Failure around the incident timestamp.
   • If you have Graph access, query recent sign-ins for the user:

USER_UPN='user@example.com'
TOKEN='eyJ...'
curl -sS -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=userPrincipalName eq '$USER_UPN'&$top=10" | jq '.value[] | {createdDateTime, appDisplayName, status, conditionalAccessStatus, ipAddress, correlationId}'

• This is your problem if you see conditionalAccessStatus as failure on the event matching the user's timestamp/app.
• Jump to step 2.

1. Open Conditional Access evaluation on that exact event.
   • In the sign-in event details, open the Conditional Access tab/section.
   • You are looking for one policy with enforced failure. Typical shape:

{
  "displayName": "CA - Require compliant device for All cloud apps",
  "result": "failure",
  "enforcedGrantControls": ["Require compliant device"],
  "conditionsSatisfied": ["Users", "Cloud apps", "Client apps"],
  "conditionsNotSatisfied": ["Locations"]
}

• If all you see is reportOnlyFailure, this is not the blocker. Keep looking for an enforced failure.
• If you found the failing policy, jump to the matching fix section.

1. Confirm whether the user was actually in scope for that policy.

   • Open the policy assignments and compare Users, Workload identities if relevant, Target resources / cloud apps, and exclusions.
   • Then inspect the user object's effective group membership in the admin portal. If your environment uses dynamic groups, also inspect the group's membership rule.
   • This is your problem if the user appears in an included group you did not expect, or is missing from an exclusion group you expected.
   • Jump to ### Unexpected group membership or missing exclusion.

2. Check the source IP and named location match.

   • In the sign-in event, note IP address. Compare it to your named locations / trusted locations configuration.
   • If you have shell access to your corp egress/VPN docs, verify whether the user was behind VPN or a new NAT range.
   • This is your problem if the sign-in IP is outside the trusted range you thought covered the user, or inside a blocked geography/range.
   • Jump to ### Named location or IP mismatch.

3. Check device state and compliance on the sign-in event.

   • In the sign-in details, inspect Device info: join type, compliance state, device ID, platform.
   • This is your problem if the failing policy's grant controls require a compliant or hybrid-joined device and the event shows non-compliant, unregistered, or unknown device state.
   • Jump to ### Device compliance or join requirement failed.

4. Verify the targeted app/resource is the one you think it is.

   • In the sign-in event, compare Application, Resource, and Client app to the policy target.
   • This is your problem if the policy targets All cloud apps or a different enterprise app/resource than the one your team expected.
   • Jump to ### Wrong cloud app or target resource in policy.

5. Check for report-only confusion.

   • In the Conditional Access evaluation, separate enforced results from report-only results.
   • This is your problem if the team is pointing at a policy whose result is only report-only: failure while another policy has enforced failure.
   • Jump to ### Report-only policy was misread as the blocker.

Fixes

Broad enforced policy matched the sign-in

• Edit the identified policy and narrow one dimension at a time: users/groups, cloud apps, locations, device platforms, or client apps.
• Lowest-risk remediation is usually a temporary exclusion for the affected user or a break-fix group while you correct scope.
• In the policy editor:
  • Remove All users if that was unintended and replace with a specific include group.
  • Add an exclusion group such as CA-Temporary-Exclusions and put only the affected user in it.
• Verify it worked: retry sign-in and confirm the new sign-in event shows the policy as not applied or success, with no enforced failure.

Unexpected group membership or missing exclusion

• Open the user object and remove the user from the included group, or add them to the intended exclusion group.
• If the group is dynamic, fix the membership rule rather than hand-editing membership.
• Typical dynamic rule issue: a broad department or country attribute catches contractors/test users.
• After changing membership, wait for directory propagation, then retry.
• Verify it worked: in the user object, effective memberships no longer include the policy's include group, or now include the exclusion group; the next sign-in no longer shows that policy as failure.

Named location or IP mismatch

• Add the correct corporate egress/VPN CIDR to your trusted/named location list, or remove the stale range that no longer belongs there.
• If the policy blocks by country, confirm the user's public IP geolocates where you expect before changing geography rules.
• Trade-off: widening trusted IP ranges reduces friction but weakens location-based controls; prefer exact NAT/VPN CIDRs over broad office ISP ranges.
• Verify it worked: the next sign-in from the same network shows the location condition as satisfied in the intended way and the policy no longer fails.

Device compliance or join requirement failed

• On the endpoint, have the user re-register or re-enroll the device in your device management platform, then sync policy.
• If the device should be hybrid-joined, verify directory join state on the endpoint before changing CA policy.
• On Windows, a quick local check is:

cmd /c dsregcmd /status

• Problem indicators look like:

AzureAdJoined : NO
DomainJoined  : YES
DeviceAuthStatus : FAILED

or compliance state is absent in the sign-in event.

• If this is a BYOD/user-owned device and the policy was intended only for managed devices, split the policy by app sensitivity instead of forcing all apps through compliant-device grant controls.
• Verify it worked: dsregcmd /status shows the expected join state and the next sign-in event shows device compliance/join requirements satisfied.

Wrong cloud app or target resource in policy

• Edit the policy target from All cloud apps to the exact enterprise app/resource set you intended, or exclude the affected app.
• Watch for resource mismatch in OIDC/OAuth flows: the user may be signing into your app, but the blocked resource in logs can be a downstream API or Microsoft service.
• Trade-off: narrowing app scope reduces blast radius but can create gaps if you forget dependent resources.
• Verify it worked: the sign-in event for the affected app/resource no longer lists the policy as applied with failure.

Report-only policy was misread as the blocker

• Do not change a report-only policy to fix the incident; it did not enforce the block.
• Document the actual enforced failing policy from the sign-in event and update the incident notes so the team stops chasing the wrong object.
• If useful, export a screenshot or JSON of the sign-in event's CA evaluation for the ticket.
• Verify it worked: the incident record names the enforced failing policy, and any remediation is applied to that policy only.

Break-glass exclusion missing

⚠️ Changing exclusions on broad access policies can create a real bypass. Restrict this to designated emergency accounts and record the change in your incident ticket.

• Create or use a dedicated emergency-access group and exclude it from all high-impact Conditional Access policies.
• Add only your designated break-glass accounts; do not add normal user accounts for convenience.
• Then test one emergency account sign-in from a controlled workstation.
• Verify it worked: the emergency account sign-in succeeds and the sign-in event shows the relevant policies as excluded/not applied.

Prevention

• Add a standard incident query for recent CA failures by user and correlation ID. Store the Graph call in your team docs or scripts:

curl -sS -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=conditionalAccessStatus eq 'failure'&$top=50" | jq '.value[] | {createdDateTime,userPrincipalName,appDisplayName,ipAddress,correlationId}'

• Enforce policy naming that encodes scope and control, for example:

CA - Users:Employees - Apps:All - Grant:RequireCompliantDevice - Excl:BreakGlass

This makes the sign-in event immediately readable during incidents.

• Keep a dedicated exclusion group for break-fix and a separate one for emergency access. Review membership daily or via scheduled automation so temporary exclusions do not become permanent.
• Before enabling a new policy, run it in report-only mode and review actual sign-ins for a week. Promote only after checking who would have failed by user, app, IP, and device state.
• Version-control dynamic group rules and named location CIDRs in IaC or at least in a repo-backed change log. A one-line CIDR typo or broad membership rule is a common source of surprise scope.
• Add a post-change validation checklist to CI/change review for identity changes:

[ ] Policy has at least one explicit exclusion path for emergency accounts
[ ] Target apps listed explicitly unless "All cloud apps" is intentional and approved
[ ] Named locations updated with current VPN/NAT CIDRs
[ ] Report-only results reviewed against real sign-ins before enforcement

This article was written by an AI system and published pending human review. Verify anything you intend to act on.