ASD ISM 2140 Disable OAuth device code flow unless required and restrict its use
What it says
The OAuth device code authentication flow is disabled unless required, and where required, is restricted to authorised user accounts and managed devices.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishTurn 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the identity provider policy that governs the OAuth device code authentication flow, exported or shown live in the console.
Look at
Check 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.
Good evidence
The flow is explicitly blocked organisation-wide, with any allowance handled as a separate, narrowly scoped exception.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the documented business justification for each case where the device code flow has been permitted.
Look at
Read 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.
Good evidence
Every enabled use of the flow traces back to a recorded, approved need, and there are no permissions with no owner or reason.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the membership of the group or condition that defines which user accounts may use the device code flow.
Look at
Compare the members against the justified use cases and current staff lists to see whether only authorised accounts are included.
Good evidence
Membership is small, matches the documented use cases, and contains no departed staff, generic accounts or unexplained additions.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the managed-device condition attached to the device code exception, along with the device management or compliance configuration it relies on.
Look at
Confirm that the exception requires the device to be organisation-managed and that the management signal is actually enforced, not just referenced.
Good evidence
An authorised account attempting the flow from an unmanaged device is refused, and a test or log entry demonstrates this.
- Check 5 of 5What an auditor asks for
Ask for
Ask for sign-in logs filtered to device code authentications over a recent period.
Look at
Look for any successful device code sign-ins from accounts or devices outside the approved set, and check whether blocked attempts are visible.
Good evidence
All successful device code sign-ins come from authorised accounts on managed devices, and attempts from anyone else appear as blocked.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets 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 accounts on managed devices when required. This aligns with ISO/IEC 27001:2022 Annex A 5.15, which requires establishing and implementing access control rules and procedures based on business and information security requirements. Annex A 5.15 sets the overarching requirement for access control governance, whereas ISM-2140 is one concrete rule within that broader access control framework.
This control partially meets A.8.5.
ISM-2140 requires organisations to disable the OAuth device code flow unless there is a genuine requirement, and where enabled, restrict it to authorised user accounts and managed devices. This is a specific configuration decision that implements secure authentication design consistent with ISO/IEC 27001:2022 Annex A 8.5, which requires secure authentication technologies and procedures aligned to access restrictions and access control policy. Annex A 8.5 is broader across all authentication methods and assurance levels, while ISM-2140 is narrowly focused on controlling a higher-risk OAuth authentication flow.
This control partially overlaps A.5.17.
ISM-2140 requires disabling OAuth device code flow unless required and constraining any permitted use to authorised accounts on managed devices. This overlaps with ISO/IEC 27001:2022 Annex A 5.17 because limiting device code flow reduces exposure and mishandling of authentication information (e.g. user/device codes and resultant tokens) by constraining where and by whom it can be used. Annex A 5.17 is primarily about lifecycle management, allocation and handling guidance for authentication information, whereas ISM-2140 is a specific technical restriction on an authentication pathway rather than credential management procedures.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.