ASD ISM 2140Disable OAuth Device Code Flow Unless Required and Restrict Its Use
Turn off the OAuth device code sign-in flow by default, and where a genuine need exists, allow it only for approved user accounts signing in from organisation-managed devices.
Plain language
The OAuth device code flow is a sign-in method built for devices that have no browser or keyboard of their own, such as smart TVs, printers, command-line tools and some IoT gear. The device shows a short code, the user types that code into a browser on another device and signs in there, and the original device then receives an access token. This control says two things. First, the device code flow should be switched off unless there is an actual business need for it. Second, where it is needed, it must be limited to authorised user accounts and to devices the organisation manages, rather than being open to every account and any device. Why it matters: the device code flow is a favourite of attackers because it is easy to abuse through phishing. An attacker starts the flow themselves, sends the victim a legitimate-looking link and code, and asks them to "confirm" their sign-in. The victim types the code into a genuine login page, so nothing looks wrong, but the token is issued to the attacker's device, not the victim's. Because the flow was designed for devices that cannot run a normal interactive login, it can also sidestep some of the checks organisations rely on. Leaving the flow enabled for everyone, everywhere, hands attackers a well-understood path into user accounts and the data behind them.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessTopic
Third-party application access and device code authentication
Official control statement
The OAuth device code authentication flow is disabled unless required, and where required, is restricted to authorised user accounts and managed devices.
Why it matters
If the device code flow is left enabled for all accounts and any device, an attacker can phish a user into approving a sign-in that actually lands a token on the attacker's machine. That token gives access to the user's mailbox, files, cloud applications and anything else the account can reach, without the attacker ever needing the password or touching a managed device. Because the sign-in happened through a genuine identity provider page, the victim rarely realises anything is wrong, so the compromise can persist and spread. Restricting the flow to approved accounts on managed devices removes this path for the majority of users and confines the residual exposure to a small, known population.
Operational notes
Day to day, this control lives in the identity provider's authentication policies. Identity or platform administrators own the setting that blocks the device code flow and the exception that permits it for a defined set of users and managed devices.
Keep a short register of why the flow is needed at all (for example a specific headless device, a particular command-line tool, or a conferencing appliance), which accounts are permitted to use it, and which managed devices are involved. Review that register when people change roles or leave, when devices are replaced or retired, and when the original business need goes away, so that the exception shrinks rather than grows.
Treat any device code sign-in from an account or device outside the approved set as a policy failure worth investigating, since it usually means either the policy has drifted or someone is testing the boundary. Include the device code flow in normal change control: enabling it for a new use case should be a deliberate, recorded decision, not an ad hoc toggle.
Implementation tips
- Identity administrators inventory where the device code flow is actually used by searching sign-in logs in the identity provider for device code authentications over the past few months, then confirm with the relevant application or device owners whether each use is still required.
- Identity administrators disable the OAuth device code flow for all users as the default position by configuring an authentication or conditional access policy in the identity provider that blocks that specific flow, and confirm the block by attempting a device code sign-in with a test account.
- Where a use case is confirmed as required, identity administrators create a dedicated security group containing only the authorised user accounts and scope the exception policy to that group, so the flow is permitted for those accounts and remains blocked for everyone else.
- Endpoint and identity administrators add a managed-device condition to the exception policy, using the organisation's device management or device compliance signal, so that even authorised accounts can only complete the device code flow from a device the organisation manages.
- The identity team records each approved exception (the business need, the accounts, the managed devices and the approver) in a register, and schedules a periodic review to remove entries where the need has lapsed, the user has left, or the device has been retired.
Audit / evidence tips
- AskAsk for the identity provider policy that governs the OAuth device code authentication flow, exported or shown live in the console.Look atCheck whether the policy blocks the device code flow for all users by default, rather than leaving it in the provider's out-of-the-box enabled state.GoodThe flow is explicitly blocked organisation-wide, with any allowance handled as a separate, narrowly scoped exception.
- AskAsk for the documented business justification for each case where the device code flow has been permitted.Look atRead the justification to see whether it names a genuine need, such as a headless device or tool that cannot use another flow, and who approved it.GoodEvery enabled use of the flow traces back to a recorded, approved need, and there are no permissions with no owner or reason.
- AskAsk for the membership of the group or condition that defines which user accounts may use the device code flow.Look atCompare the members against the justified use cases and current staff lists to see whether only authorised accounts are included.GoodMembership is small, matches the documented use cases, and contains no departed staff, generic accounts or unexplained additions.
- AskAsk for the managed-device condition attached to the device code exception, along with the device management or compliance configuration it relies on.Look atConfirm that the exception requires the device to be organisation-managed and that the management signal is actually enforced, not just referenced.GoodAn authorised account attempting the flow from an unmanaged device is refused, and a test or log entry demonstrates this.
- AskAsk for sign-in logs filtered to device code authentications over a recent period.Look atLook for any successful device code sign-ins from accounts or devices outside the approved set, and check whether blocked attempts are visible.GoodAll successful device code sign-ins come from authorised accounts on managed devices, and attempts from anyone else appear as blocked.
Cross-framework mappings
How ISM-2140 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(2)expand_less | ||
| Annex A 5.15 | ISM-2140 requires a defined logical access rule: the OAuth device code flow must be disabled by default and only permitted for authorised... | |
| Annex A 8.5 | ISM-2140 requires organisations to disable the OAuth device code flow unless there is a genuine requirement, and where enabled, restrict ... | |
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.17 | ISM-2140 requires disabling OAuth device code flow unless required and constraining any permitted use to authorised accounts on managed d... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.