## TL;DR
Open the user's sign-in log in Entra, expand the Conditional Access tab, and read exactly which policy applied and why it blocked. Use the What If tool to test the fix, then adjust the policy (location, device compliance, or exclusion) rather than disabling it.

## The error
```text
Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.
```

## Steps
1. Entra admin center > Monitoring > Sign-in logs > the failed sign-in > Conditional Access tab. Expected: the blocking policy is named with the specific condition (e.g. "require compliant device" failed).
2. Click "What If": enter the user, the app, and their conditions (location, device, client). Expected: the tool shows which policies would apply. This lets you test fixes safely.
3. Check the common culprits: unrecognized location (user traveling), non-compliant device (Intune issue), or legacy auth blocked by policy. Expected: one of these matches the log.
4. Fix the underlying condition: register the device, resolve compliance, or add the travel location. Expected: What If now shows access granted. Prefer fixing the condition over excluding the user.
5. If exclusion is truly needed, scope it narrowly: one user, one app, with an expiry date and a ticket reference. Expected: documented temporary exclusion. Never exclude "all users" to fix one ticket.

## When to use
- "Blocked by Conditional Access" message on sign-in
- Users blocked while traveling or on new devices

## When not to use
- Password or MFA failures (different error text)
- App-level access denied after successful sign-in

## Compatibility
- Microsoft Entra ID P1+ (Conditional Access requires P1)

## Variants
### Blocked on compliant device
The device compliance state may be stale. Check Intune compliance timestamp; re-sync the device.
### "You cannot access this right now" on legacy email clients
The policy blocks legacy authentication. Move the user to a modern auth client instead of excluding them.

## Why it happens
Conditional Access evaluates every sign-in against policy conditions. Legitimate users trip it when their context changes (travel, new device, non-compliant state) while the policy stays fixed.

## Edge cases
- Break-glass accounts must be excluded from ALL CA policies by design; verify this regularly.
- Policy changes replicate in minutes but sign-in logs lag slightly; wait before re-testing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7RCEKEUcBv3bvIVHWney-Q