AegisAI Perspectives · 016
Block device code flow with a Conditional Access policy, test it in report-only mode, then turn it on and exclude only Teams devices that need the flow.
Block the device code flow with a Conditional Access policy, test it in report-only mode, then turn it on. The FBI advised a block after a device code phishing kit for Microsoft 365 appeared in April 20264.
AegisAI reads each message for what it is trying to do. A device code lure is trying to get the reader to type a code on a legitimate Microsoft sign-in page13. The attacker started that sign-in, so the user finishes it on the attacker's behalf.
Close the flow for everyone, then reopen it only for named accounts that need it. Microsoft Learn calls device code flow a high-risk authentication method that can be part of a phishing attack10. RFC 8628, the standard behind the flow, warns that it can be started on a device in an attacker's possession26.
The user has 15 minutes from the request to sign in17. Once the code is entered, the attacker reaches Outlook, Teams and OneDrive with no password and no further MFA challenge5. For a campaign that automated the lures with AI, read how a Midnight Blizzard-linked actor automated device code phishing.
In the Entra ID sign-in logs, filter on Authentication protocol = Device code flow and export every account that still signs in this way1612.
Audit each result before you write the policy7. Keep exceptions to required business processes, such as Teams devices that sign in with a code6.
Users in scope need a Microsoft Entra ID P1 or higher licence14.
In Conditional Access, target all users, set the Authentication flows condition to Device code flow and set the grant to Block access8. Exclude one exception group of named accounts and nothing else.
Set Enable policy to Report-only and compare the policy impact with the accounts from step 19.
When the report-only results match the inventory, move the Enable policy toggle from Report-only to On.
Enforce Token Protection in Conditional Access so only refresh tokens cryptographically bound to the device are used25.
Protocol tracking state carries through later refreshes, so sessions that began with device code flow stay subject to the policy11. Re-run the Authentication protocol filter each week.
AegisAI agents read sign-ins and mailbox activity for each account, as the account takeover protection page describes1. When behavior stops matching the owner, they raise one explained finding. They weigh impossible travel, new devices, inbox rule changes and suspicious internal sends together per account2. Every finding comes with recommended steps, and your team acts in Entra ID3.
Five Conditional Access and Entra ID settings do the work, and two time limits decide how fast you act. The table lists where each one lives and what it changes.
| Setting or signal | Where it lives | What it changes | Fact |
|---|---|---|---|
| Authentication flows condition: Device code flow, Block access | Conditional Access policy | Blocks new device code sign-ins for users in scope | |
| Report-only mode | Enable policy toggle | Shows the impact before enforcement | |
| Authentication protocol = Device code flow | Sign-in logs filter | Lists the accounts that still use the flow | |
| Exception group | Policy exclusions | Exempts named accounts only, because an exception is account-scoped | 15 |
| Token Protection | Conditional Access session control | Accepts only refresh tokens bound to the device | |
| Device code lifetime | Device authorization request | The user has 15 minutes to sign in | |
| Access token lifetime | Entra ID default | Access tokens last 1 hour by default | 20 |
A single code typed from a fake meeting invite gives the attacker a session, and the sign-in logs show it as a device code sign-in.
Illustrative example, figures are fictional. A fictional tenant with 400 mailboxes has its block policy in report-only mode during week 1. A finance user receives a Teams meeting invite from an outside address that says to enter a code at the Microsoft device login page to join. The user types the code 6 minutes after the attacker's device requested it, inside the 15 minute window. The sign-in logs show a successful sign-in for the user with Authentication protocol set to Device code flow, from an IP address the user has never used. The Conditional Access tab shows the block policy in report-only with a result of failure, which means it would have blocked the sign-in if it were On. The admin revokes the user's sessions, finds a new inbox rule that moves replies to RSS Subscriptions, deletes it and switches the policy On. A second invite to the same user 2 days later produces a failed sign-in with the block policy listed as the reason.
Yes, in practice, because the user completes MFA on the real Microsoft page for a sign-in the attacker started. The FBI describes Kali365 as a service that obtains Microsoft 365 access tokens and bypasses MFA without intercepting the user's credentials. After that, the attacker needs no password and passes no additional MFA challenge.
A stronger MFA method on the user's side protects the user's own sign-in. It does not change which device receives the tokens, since the device that started the flow can be the attacker's. That is why the FBI and Microsoft both point to blocking the flow.
Token Protection adds a second layer by refusing refresh tokens that are not bound to the device. For the full kit breakdown, read how the Kali365 kit defeated MFA without breaking it.
Use one policy that covers all users and blocks the Device code flow authentication flow, with a single exception group. Microsoft recommends getting as close as possible to a unilateral block, and the FBI asks for limited exceptions for required business processes.
Keep three settings fixed. The scope is all users, the condition is Authentication flows with Device code flow selected, and the grant is Block access. Report-only comes first, then On once the impact is confirmed.
Put exclusions in one group so they are visible and countable. Each exception is account-scoped, so add the account that needs the flow, never a whole department. Before you add anyone, check the sign-in logs filtered by authentication protocol for that account.
Revoke the user's sessions first, then look for what the attacker changed. Revoking active sessions immediately invalidates active access from the stolen credentials and stops further actions on the account23.
1 hour is the default life of an access token issued by Entra ID. Apps that use access tokens lose access when that token expires22. In CAE sessions, token lifetime increases to long-lived, up to 28 hours19. Do not wait out a timer in either case.
Work through this order in the first hour. Revoke the user's Entra ID refresh tokens with Revoke sessions in the admin center or Revoke-MgUserSignInSession in PowerShell21. Then check the mailbox for rules that move messages to the Notes, Junk Email or RSS Subscriptions folders24. For where each takeover stage leaves evidence, read how email account takeover works step by step.
Yes, with an exception group that holds only the Teams device accounts that sign in with a code. Microsoft Learn has a dedicated page for this setup, and the setup needs Entra ID P1 or higher for the users in scope.
Find those accounts with the sign-in log filter Authentication protocol = Device code flow before rollout. Because an exception is account-scoped, it allows every device code sign-in by that account, from any device. Keep the group to the resource accounts the inventory found, and review it each month.
Track three numbers each week, and expect the first one to reach zero once the policy is On.
From the moment the request is sent, the user has 15 minutes to sign in. An attacker sends the code and asks the user to enter it straight away, so the lure fits inside that window. A short lifetime does not replace the block.
Start with an inventory, then a report-only policy that blocks Device code flow for all users. Microsoft recommends getting as close as possible to a unilateral block. Exceptions go into one group of named accounts, because an exception is account-scoped.
Filter the sign-in logs for device code flow, create a Conditional Access policy that blocks it for all users, run it in report-only mode, then turn it On. Add an exception group only for accounts the logs show need it.
Not by itself. Protocol tracking state carries through later refreshes, so those refreshes can meet the policy. Access tokens already issued stay valid until they expire. Revoke the refresh tokens of any account you suspect.
Microsoft Learn lists a Microsoft Entra ID P1 or higher licence for the users in scope. Check it before you build the block, since the block is a Conditional Access policy.
Yes, for required business processes such as Teams devices that sign in with a code. Microsoft Learn notes the flow can also be used to reach corporate resources on unmanaged devices. Audit existing use before you block it, so real dependencies get an exception.
