Entra Login shows a successful "deviceCodeFlow" login when this is Globally blocked in Conditional Access Policy

Question

A user's Email in our tenant has been compromised. While auditing the Entra logs, we found a login on 3/13/2026 that looks fishy. We noticed that the Authentication Protocol used for a particular login was "deviceCode" and the original transfer method was "deviceCodeFlow" which is an authentication flow type that has been blocked on the Global level (via a Conditional Access Policy created by Microsoft in May of 2025). I need assistance determining how this login was successful given the policy that has been in place for almost a year.

Answer 1

Hey Lucas, it sounds like your device code flow block policy simply wasn’t enforced for that particular sign-in. In Microsoft Entra ID Conditional Access is only evaluated when a token is issued, so if the policy didn’t apply at the moment of token issuance (or if an existing refresh token was reused) you’ll still see a “successful deviceCodeFlow” entry even though you think you’ve blocked it globally.

Here’s what to check:

1. Review the Conditional Access tab in the sign-in log
   • Go to Entra ID > Sign-in logs > select that 3/13/2026 event > Conditional Access.
   • See if your “Block device code flow” policy shows as Applied, Not applied or Excluded – and note the reason.
2. Confirm policy scope and state at that timestamp
   • Was the policy set to Enabled (not Report-only)?
   • Does it include All users (or the compromised user) and All cloud apps (or the target app)?
   • Are there any exclusions (users, groups, or emergency/break-glass accounts)?
3. Check client app settings
   • Under Conditions > Client apps, ensure “Other clients” (where device code flow lives) is covered.
4. Look for a pre-existing refresh token
   • If the user had a valid refresh token issued before you enabled the block, CA won’t re-evaluate until that token expires.
   • In the log’s Basic info, check “Original transfer method” vs. “Authentication Protocol” to see if this was a protocol-tracked refresh.
5. Simulate with the What If tool
   • In Entra ID > Conditional Access > What If, select the user/app and the Device code flow condition to confirm whether your policy would block it.
6. Remediate & harden
   • Revoke the user’s refresh tokens (Azure AD admin center > Users > revoke sessions).
   • Reset their password and re-enroll MFA to force fresh authentication under your CA rules.

Follow-up questions to narrow it down:

1. In the CA tab for that sign-in, what enforcement state and reason did you see for your device code flow policy?
2. Was the policy in “Enabled” mode (not report-only) and targeting “Other clients” at the time?
3. Are there any break-glass or emergency accounts excluded that might include this user?
4. Have you observed other deviceCodeFlow successes, or was this a one-off?

Reference list

• Troubleshoot Conditional Access policies: https://learn.microsoft.com/entra/identity/conditional-access/troubleshoot-conditional-access
• Block authentication flows with CA policy (device code flow): https://learn.microsoft.com/entra/identity/conditional-access/policy-block-authentication-flows?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#overview
• Conditional Access authentication flows concept: https://learn.microsoft.com/entra/identity/conditional-access/concept-authentication-flows?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider
• Sign-in logs in Microsoft Entra ID: https://docs.microsoft.com/azure/active-directory/reports-monitoring/concept-sign-ins
• What If tool for Conditional Access: https://learn.microsoft.com/entra/identity/conditional-access/what-if-tool

Hope this helps you pinpoint why that login bypassed your block!

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

Answer 2

The first thing you need to do as immediate reponse is to:

1. Use Microsoft Entra admin center or PowerShell to revoke all active sessions for the compromised account.
2. Force the affected user to reset their password and invalidate any refresh tokens tied to it.
3. Require the user to re-register Multi-Factor Authentication (MFA) methods to ensure no unauthorized individuals have access.

To find out how the policy to block device code flow was not invoked, You can check using on etra. Steps below: Target the signin logs, audit logs and CA policy configuration. On thing must have made the CA policy not apply if the login was supposed to be CA blocked

To determine why the Conditional Access Policy wasn't applied in the mentioned scenario, the following points need to be checked:

Verify if the User and App Were in Scope

1. Ensure there are no Conditional Access policy exclusions for this user, app, or group that could have bypassed the policy.

Policy Status at the Time

1. Validate whether the policy was enabled and not in "Report-only" mode during the time of the login (March 13, 2026).

Check Conditional Access Logs

Access the Conditional Access tabin the affected sign-in logs to see whether:

The policy was applied.

The policy was bypassed/excluded.

The reason for the bypass.

Review Targeted Client Applications

Determine if the policy applies broadly, including **“Other clients”**under Client apps, ensuring "deviceCodeFlow" activities are covered.

Refresh Tokens

Assess whether the compromised user had a valid refresh tokenat the time. Refresh tokens can circumvent Conditional Access re-evaluation for some time (as they maintain session validity until expiration).