device code phishing sign-in passed conditional access and no alert fired

Not specified by the original author.

TL;DR

Block the flow where you do not need it, because a successful device code phish produces a completely legitimate sign-in: create a Conditional Access policy that blocks the device code authentication flow for all users except a small group that manages approved devices, review recent device code sign-ins in the logs for victims, force password resets and session revocation for affected accounts, and brief users that a code prompt from a message is never how IT will ask them to sign in.

device code phishing sign-in passed conditional access and no alert fired

Use this when

• Sign-in logs show a device code grant for a user who was lured by a message or call.
• The sign-in passed Conditional Access and MFA because the user completed a real Microsoft sign-in page.
• No alert fired at the time of the sign-in.

Not for this skill when

• A user lost a password to a fake login page with no device code involved. That is a classic credential phish response.
• Approved televisions or conference devices genuinely need the flow. Scope the exception, do not abandon the block.

Steps

1. Search sign-in logs for the device code protocol across the tenant for the past month and list the users and IPs involved. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every device code sign-in in the window is listed with user and result
2. For any phished account, revoke sessions, reset the password, and review mailbox rules and registered authentication methods for attacker changes. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: affected accounts show revoked sessions and a clean rules and methods check
3. Build a Conditional Access policy blocking the device code flow, scoped to all users with an exclusion group for approved device administrators, in report only mode first. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the policy exists in report only and the exclusion group is named
4. Review report only results for a week to catch any legitimate business use you did not know about. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: legitimate uses found are documented and either excluded deliberately or moved to another flow
5. Enable the policy and test a device code sign-in as a normal user. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the test sign-in is blocked and the block is visible in the sign-in log

Why it happens

Device code phishing abuses a real flow built for devices without browsers. The victim signs in on the genuine Microsoft page and enters a code the attacker generated, so the attacker session inherits real MFA and passes most Conditional Access checks. There is no fake page to block and no malicious link to scan. The durable control is therefore at the authentication flow itself, which most tenants can block almost everywhere without any user impact.

Variants and edge cases

device code phishing sign-in passed conditional access no alert

The exact incident shape with the missing alert.

block device code flow conditional access policy entra

The policy action variant.

device code grant phish token stolen user entered code fix

The mechanism variant naming how the grant is abused.

Compatibility: Microsoft Entra ID Conditional Access authentication flows condition, sign-in logs, device code flow documentation.

Edge cases to check:

• Check authentication transfer and related newer flow controls during the same review; attackers move between lesser used flows.
• Hunt historically before enabling the block: victims from earlier sign-ins still hold valid refresh sessions until revoked.

Provenance

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

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

Thread query: device code phishing sign-in passed conditional access and no alert fired

TL;DR: Block the flow where you do not need it, because a successful device code phish produces a completely legitimate sign-in: create a Conditional Access policy that blocks the device code authentication flow for all users except a small group that manages approved devices, review recent device code sign-ins in the logs for victims, force password resets and session revocation for affected accounts, and brief users that a code prompt from a message is never how IT will ask them to sign in.