How are you controlling Microsoft 365 device-code authentication with Conditional Access?
Asked by
MellowCedar47
Microsoft's reporting on device-code phishing highlights an awkward security tradeoff: device-code authentication is legitimate, but attackers can abuse it by persuading users to authorize a session on another device. For Microsoft 365, are you blocking device-code authentication for everyone, or allowing narrowly defined exceptions? I'm especially interested in approaches for Teams Rooms, Teams Phones, shared devices, Linux or Azure Arc enrollment, CLI and IoT scenarios, and other services that still depend on the flow. Are you also monitoring device-code sign-ins after the initial authorization, rather than relying only on Conditional Access to block them?
Answers
The usual safest baseline is to block device-code authentication for all users, then create a very small exception group only when a service genuinely requires it. Keep that group limited to specific accounts and resources, and review it regularly. For temporary administrative or troubleshooting needs, a separate Privileged Identity Management-eligible group can make the exception time-limited instead of permanent.
Reply to this answer
Teams Phones are a particularly awkward edge case. Device-code flow is the default and has a better user experience, but it is possible to select the smaller option to sign in directly on the phone with a username, password, and MFA. The catch is that registration through the Teams service may hit a device-compliance policy before the phone exists in the directory, creating a chicken-and-egg failure. Device filtering cannot help if there is no registered device to filter yet. In practice, organizations may have to choose between allowing device-code flow for tightly controlled phone accounts or creating a carefully scoped exception to the compliance requirement during registration. Either way, test the complete registration path and inspect the sign-in logs rather than assuming the Conditional Access evaluation works as expected.
SilverMaple18: This is why a blanket block can break legitimate deployments even when the service technically supports another sign-in method. The alternative login option is easy to miss, and password-based registration may still conflict with device-compliance requirements.
Reply to this answer
We block the flow by default and use narrowly scoped exclusions for things such as Teams Rooms or other service accounts. Where possible, restrict those exceptions by application, resource, named location, or trusted network. The exception accounts should be non-user accounts where practical, have strong monitoring, and be limited to the minimum services they need. For devices that only authenticate from office networks, network restrictions add another useful layer.
CopperWren56: For our shared-room devices, we also watch the sign-in activity after setup. Device-code authentication can result in a refresh token being used later, so the initial authorization event is not the only thing worth monitoring.
Reply to this answer
Add your answer
Answers are reviewed before publication.
AmberKite31: That works well for occasional use, but permanent exceptions can become much larger than expected when hardware phones or other shared devices are involved. Those cases need to be identified explicitly rather than assuming the exception group will stay small.