Device code flow supports applications and devices with limited input. In a phishing scenario, an attacker persuades a person to enter a code and complete a legitimate-looking authorization for a session the attacker initiated. The real Microsoft sign-in page does not prove that the surrounding request is legitimate.
Check whether your organization needs the flow
Inventory actual use before enforcement: meeting-room devices, administrative tools and other applications may have a legitimate dependency. Capture the account, application and business owner for each allowed scenario. An unexplained exception should be investigated, not silently made permanent.
Microsoft now documents device-code blocking in Security Defaults, including the behavior for new tenants from July 1, 2026. Security Defaults is a baseline with limited customization. Organizations needing granular exceptions should assess Conditional Access and its licensing. Microsoft Security Defaults guidance.
Use a tested policy for granular control
Microsoft provides a Conditional Access policy for blocking authentication flows. Start in report-only, examine legitimate use and define explicit exceptions before enforcement. A policy that breaks a meeting-room sign-in and gets disabled a week later has not delivered durable protection.
| Test | What to observe |
|---|---|
| Ordinary user, unnecessary device-code sign-in | Blocked under the agreed policy |
| Approved device or application | Expected sign-in still works |
| Account recovery or reauthentication | Approved use remains possible after the tested change |
| Detection and ownership | Relevant events reach the named reviewer |
If you suspect a session is already compromised
Do not assume a password reset ends every session. The effect depends on the reset action and token type; see Microsoft’s revocation matrix. Follow the authorized response process, explicitly revoke sessions and verify that affected applications no longer accept the access. Review new authentication methods, application grants and mailbox changes as part of the investigation.
The session-token theft guide explains the related containment limits. Preventive policy work and live incident response need distinct scopes and owners.
What a useful handover contains
- The permitted sign-in scenarios and why each exception exists.
- Policy settings, pilot results and the enforcement approval.
- The observed block/allow tests and any unresolved limitations.
- An operating owner, review date and rollback instructions.
If the flow’s use is unknown, begin with discovery. If the permitted scenarios are known, the MFA and Conditional Access hardening offer can scope the configuration and validation.
Close the access and sharing gaps putting company data at risk.
We identify the legitimate sign-in paths, agree policy exceptions and test access before enforcement.