⌚ About 2 min read
Identify the exact Conditional Access policy blocking a sign-in without creating a broad exclusion.
Before you start
Work on a copy or a controlled test when the change can affect production. Keep timestamps, screenshots and the previous configuration so the result can be compared.
Step by step
- Open the user Sign-in logs and select the matching failure.
- Read the Conditional Access tab and identify applied policies.
- Check location, device, risk level, client, and target application.
- Fix the compliance or condition causing the block.
- Use only a minimal, temporary, documented exclusion when justified.
Validation
Repeat the original test after the change and confirm that the expected service works without creating a new regression. Document the final state.
Intune / Conditional Access: read the exact decision before excluding
Technical checkpoints
- A non-compliant device can fail a compliance rule, device-state evaluation or sync delay; read the exact failing setting.
- AADSTS53003 generally means access was blocked by Conditional Access; Sign-in logs show applied policies and their result.
- The What If tool simulates user, app, platform, location and conditions without changing policy.
Read the sign-in
Open the exact sign-in and compare Grant Controls, Conditions and device state.
Entra ID > Sign-in logs > Conditional Access
Intune > Devices > Compliance > Per-setting statusTopic-specific pitfalls
- Adding a broad exclusion for testing can create a security gap and hide the actual non-compliant setting.
- A policy in Report-only does not have the same effect as Enabled; read the mode.
How to validate
- The compliance setting passes and the new sign-in shows intended policies as Success/Not applied.
- No unjustified temporary exclusion remains active.