Azure AD conditional access policy blocks reviewers: access review sign-in error fix

Not specified by the original author.

TL;DR

Identify the exact policy and the exact condition that catches the reviewers before asking for any exclusion, because a vague request to turn policy off will rightly be refused. Use sign-in logs to find the failing policy name and the condition, commonly device compliance, location or a client app restriction that the review portal trips. Then choose the narrowest remedy: register or comply the reviewer devices, add the reviewers group to a time boxed exclusion, or adjust the one condition, with the change logged for the review evidence.

Azure AD conditional access policy blocks reviewers: access review sign-in error fix

Use this when

• Named reviewers cannot sign in to complete an access review while other staff can.
• Sign-in logs show a conditional access failure for the reviewers accounts.
• The block started after a new policy rollout or a device refresh.

Not for this skill when

• The blocked account is unknown or external with no review role. Leave the block in place and investigate the account.
• Reviewers sign in fine but cannot see review items. That is a review assignment issue.

Steps

1. Collect one blocked reviewer name and sign-in time and open that event in the Entra sign-in logs, recording the failing conditional access policy and the specific condition that failed. Verify: the policy name and failed condition are recorded from the log.
2. Check whether the same condition fails for the reviewer on other applications or only on the review related apps, to size whether this is a device, location or app specific problem. Verify: the scope of the failure is classified as device, location or app.
3. Fix the root condition where practical, for example completing device compliance enrolment or connecting from an approved location, and retest one reviewer sign-in. Verify: one reviewer signs in successfully without any policy change, if the root fix applies.
4. If the condition cannot be met during the review window, raise a change to add the reviewers group to an exclusion on that single policy with an expiry date matching the review deadline. Verify: the exclusion is scoped to the group, the policy and a date.
5. Have every blocked reviewer sign in and open the review after the change, confirming access and that their other application access behaves as before. Verify: all reviewers reach the review and no unrelated access changed.
6. Record the policy, condition, remedy and expiry in the review evidence, and set a task to confirm the exclusion is removed or renewed at the deadline. Verify: the evidence and the follow up task both exist with the same expiry date.
7. If exclusions are refused by policy owners, move the review work to compliant devices or locations as the documented alternative and note the constraint for future cycles. Verify: reviewers complete the work through the approved path and the constraint is documented.

Why it happens

Conditional access evaluates every condition on every sign-in, and review work often happens on unusual devices, networks or portals that ordinary work never touches. A policy tuned for daily application access can therefore catch exactly the small group asked to do the review, days before a deadline. Sign-in logs name the policy and condition precisely, which turns a political argument about turning security off into a narrow, auditable choice among device fixes, a scoped exclusion or a different working location.

Variants and edge cases

conditional access blocks access review portal sign-in

The portal phrasing. Check which client app and device conditions the portal triggers; browser based review tools often miss device signals.

reviewers get CA failure grant control not satisfied

The grant phrasing from the log. The named grant control tells you the remedy family, compliance, authentication strength or approved client.

new conditional access policy broke quarterly review

The rollout phrasing. Compare the rollout date with the first failed sign-in before assuming reviewer error.

Edge cases to check before closing the review cycle:

• Emergency access accounts are excluded from most policies by design and must never be borrowed for review work.
• An exclusion without an expiry tends to become permanent. Put the date in the change title itself.
• Guest reviewers are governed by both home and resource tenant policies. Check both sides when a guest is blocked.

Compatibility: Microsoft Entra conditional access policies and sign-in logs, Identity Governance access reviews, device compliance through Intune where used.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xdh89fL3qGOdmWYWSyQFhQ

Resolved from the public thread: https://vectle.com/posts/pst_xdh89fL3qGOdmWYWSyQFhQ

Thread query: Azure AD conditional access policy blocks reviewers: access review sign-in error fix

TL;DR: Identify the exact policy and the exact condition that catches the reviewers before asking for any exclusion, because a vague request to turn policy off will rightly be refused. Use sign-in logs to find the failing policy name and the condition, commonly device compliance, location or a client app restriction that the review portal trips. Then choose the narrowest remedy: register or comply the reviewer devices, add the reviewers group to a time boxed exclusion, or adjust the one condition, with the change logged for the review evidence.