Entra ID Conditional Access Troubleshooting: How to Diagnose Why MFA Loops, Compliant Device Failures, and Policy Conflicts Are Blocking or Bypassing Access

Every Conditional Access evaluation is recorded in the Entra ID sign-in log. Navigate to: Entra admin center > Identity > Monitoring and health > Sign-in logs.

For the affected user and time window, locate the specific failed sign-in and click through to the Conditional Access tab. This tab shows:

• Every policy that was evaluated for this sign-in
• The result for each policy: Success, Failure, Not Applied, or Report-only
• For failures, the specific grant control that was not satisfied

Key fields to read:

Policy name and result: A policy showing Failure was evaluated and the user did not satisfy its grant control. A policy showing Not Applied was evaluated but the user did not match its conditions (the policy did not apply to this sign-in context).

Failure reason code: The most useful field. Common codes:

• requiredAuthenticationContextClassReferenceNotSatisfied: MFA not completed
• deviceNotCompliant: Device is Intune-enrolled but compliance policy has flagged it non-compliant
• deviceNotDomainJoined: Hybrid Azure AD join not completed on the device
• namedLocationNotIncluded: The sign-in IP was not in the named location the policy requires
• blockAccess: A block policy matched this sign-in (look for which policy)

IP address and location: Visible in the Basic Info tab. Compare against your named locations to understand which location condition applied.

An MFA loop occurs when a user is repeatedly prompted for MFA without the authentication ever completing or persisting. The symptoms: the MFA challenge appears, the user completes it, and they are immediately prompted again.

Cause 1: Session persistence disabled by policy A Conditional Access policy with Sign-in frequency set to a very low value (e.g., 1 hour) combined with a short token lifetime will require MFA re-authentication more frequently than the user expects. Check the session controls on all applicable policies for the affected user.

Cause 2: MFA registration not completed for the required method If the policy requires a specific MFA method (e.g., FIDO2 key) and the user has not registered that method, they may be redirected to registration, complete standard MFA to get there, then be re-evaluated by the CA policy which still requires the unregistered method. Resolution: verify the user's registered authentication methods in Entra ID > Users > [user] > Authentication methods.

Cause 3: Persistent browser session blocked If the policy blocks persistent browser sessions (Persistent browser session: Never persistent), the token will not be cached and every new browser session will require MFA. This is by design for sensitive apps but creates a looping experience if the user interprets it as a failure.

Cause 4: Cross-tenant MFA claim not honored Users signing in from a B2B guest account whose home tenant MFA is not trusted by the resource tenant CA policy will be required to perform MFA in the resource tenant. If the resource tenant's MFA policy is misconfigured (redirect to a registration page that the guest cannot complete), a loop results. Resolution: configure cross-tenant access settings to trust MFA from the home tenant.

The most common complaint from users after a new device compliance policy is deployed: My device is compliant in Intune but Entra ID is still blocking me.

The issue is propagation delay. When Intune marks a device compliant, it must sync the compliance state to Entra ID. This sync happens on a schedule (typically every 8 hours for device check-ins) or can be triggered manually. Until Entra ID receives the updated compliance state, it still sees the device as non-compliant.

Diagnosis:

1. In Entra ID > Devices, find the affected device by name or device ID
2. Check the Compliant field and the Last activity timestamp
3. If the device shows Non-compliant, check the Intune device compliance status for the same device
4. If Intune shows Compliant but Entra ID shows Non-compliant, trigger a manual sync:

From the device (user-initiated):

• Settings > Accounts > Access work or school > [account] > Info > Sync

From Intune admin center (admin-initiated):

• Devices > All devices > [device] > Sync

For devices that repeatedly fall out of compliance: check the Intune device compliance policy assignments and confirm the device is in scope. Check the compliance policy settings for any policy that the device is failing. In Intune: Devices > [device] > Device compliance > [policy name] shows the per-setting compliance state.

For Hybrid Entra join issues specifically (deviceNotDomainJoined): verify the hybrid join state with dsregcmd /status on the device. If AzureAdJoined: YES and DomainJoined: YES but WorkplaceJoined: NO, the device is not hybrid-joined. Run the Azure AD Connect Health troubleshooter or check the Microsoft Entra ID event log on the device for error events.

Conditional Access named locations define IP ranges or countries that policies use as conditions. Common misconfiguration patterns:

VPN IP not in trusted location: When corporate VPN is deployed but the VPN egress IPs are not in the named location that defines Corporate Network, users on VPN are not treated as corporate network users. Policy conditions like compliant device OR corporate network will require device compliance from VPN users. Fix: add all VPN egress IPs to the named location. VPN CIDR ranges change when new exit nodes are added; build a process to update named locations when VPN infrastructure changes.

Home office IPs whitelisted in trusted location: Some organizations add specific static home IP addresses to named locations to avoid MFA for executives. This creates a security gap. A user at a coffee shop whose home IP was whitelisted will not be prompted for MFA on non-corporate networks. Audit named location IP contents annually.

Named location using IP ranges versus country: Country-based named locations use geolocation databases which can be inaccurate and are affected by VPN and proxy use. IP range-based named locations are more reliable for trusted network definitions.

Missing MFA mark as trusted location: If the policy exempts trusted locations from MFA (Grant: Require MFA, Exclude: Named Location: Corporate), verify the named location is marked as trusted in the CA named location configuration. The Trusted checkbox determines whether MFA completed from that location generates a trusted session token.

To identify which IP a user's sign-in was attributed to: in the sign-in log entry, check the IP address in Basic Info. Cross-reference against your named location IP ranges manually or use the What If tool with that IP to simulate the policy evaluation.

The Conditional Access What If tool simulates policy evaluation for a hypothetical sign-in without requiring an actual authentication attempt. Use it before deploying any new policy or before modifying an existing one.

Navigate to: Entra admin center > Protection > Conditional Access > Policies > What If

Inputs you can specify:

• User (or group, for group-scoped policies)
• Application
• IP address (to simulate trusted/untrusted location)
• Device platform
• Device state (compliant, domain joined, registered)
• Sign-in risk level (if you have Entra ID P2)
• Client app type

The tool outputs every policy that would apply to this simulated sign-in, with the grant controls that would be required. This allows you to:

• Verify that a new policy you are about to enable would block the intended users without blocking unintended users
• Diagnose an existing policy by simulating the exact sign-in context of the affected user
• Test named location conditions without waiting for a user to sign in from a specific IP

Before enabling any new Conditional Access policy: run the What If tool with a sample of users from each affected group, with both expected sign-in contexts (corporate network, MFA-registered device) and edge cases (VPN user, guest user, service account if applicable). Confirm the outputs match your intent.