ISM-2138 says every OAuth application consent, meaning the permission someone gave an app to reach the organisation's mail, files or other data, is reviewed at least every six months, with unused apps and excessive permissions revoked. It matters because, as ASD notes, an app's tokens "survive credential resets": the access stays until someone revokes it. The control is new in the September 2026 Information Security Manual and has three companions: only an administrator grants consent to third-party apps (ISM-2137), consents and tokens are logged centrally (ISM-2139), and device code sign-in is off unless it is needed (ISM-2140).
OAuth is the open standard behind prompts such as "Sign in with your work account" and "This app would like to read your mail". Accepting one records a consent grant (the app, the permissions it asked for and who agreed), and from then on the app uses tokens to reach the data by itself, without asking again.
ISM-2138 asks for three things:
The review covers both kinds of consent: delegated permissions, where the app acts as the person who signed in and reaches only what they can, and application permissions, where the app acts on its own across the organisation and an administrator must grant it.
Unlike ISM-2137 and ISM-2139, ISM-2138 does not say "third-party", so our reading is that it covers every app holding a consent, third-party apps first. Nor does it name a platform: it covers the identity platform behind your email and files and any other cloud service where staff connect apps, such as a customer relationship system or a code repository. AI assistants connected to mail or files often hold a consent too (see our ISM-2156 guide). ISM-2138 applies at every classification ASD marks, from non-classified systems to TOP SECRET, and is not part of the Essential Eight.
ASD's guidance describes the attack. In an illicit consent grant, "a human user is tricked into granting a malicious third-party application consent to access data, after which the application holds OAuth tokens that operate independently of the human user's credentials and survive credential resets." No password is stolen, and multi-factor authentication does not stop it, because the person signs in and clicks Accept on a genuine page.
ASD then points at the apps already approved: "malicious actors do not need to establish new consent grants if they can compromise an existing third-party application that has already been granted access, such as via a cyber supply chain attack against the application's vendor." Two public cases:
Switching off user consent does not clean up the past either: "Any updates to user consent settings only affect future consent operations for applications. Existing consent grants remain unchanged" (Microsoft). ISM-2137 stops new grants; ISM-2138 deals with the ones you already have.
The device code flow lets you sign in on a device with no keyboard or browser, such as the "smart TVs, media consoles, picture frames, and printers" named in the IETF standard that defines it: the device shows a short code, and you approve the sign-in by entering it on a phone or computer. It also warned: "It is possible for the device flow to be initiated on a device in an attacker's possession" (IETF).
Attackers now do exactly that. Microsoft describes a campaign, active since August 2024 and lured with fake Microsoft Teams meeting invitations, in which "the threat actor generates a legitimate device code request and tricks the target into entering it into a legitimate sign-in page", then uses the resulting tokens "to access the target's accounts and data" (Microsoft). Because the sign-in page is genuine, checking the web address does not reveal the trick.
ISM-2140 asks for the flow to be "disabled unless required, and where required, is restricted to authorised user accounts and managed devices". Microsoft calls it "a high-risk authentication method" and "recommends blocking device code flow wherever possible" (Microsoft). Our reading of "required": a recorded need, such as meeting room devices, digital signage or a command-line tool with no other way to sign in, limited to the accounts and managed devices involved.
| Ask | Look at | Good looks like |
|---|---|---|
| When was the last review? | The review record | Within the past six months, signed off, with the next one booked |
| Does it cover every app? | Each platform's app list against the review | Every app with a consent appears with an owner and a purpose, including those staff approved themselves |
| Were unused apps removed? | Last-use data and the list of revocations | Apps unused since the last review revoked, or kept with a written reason |
| Are permissions the minimum? | Each app's granted permissions | Each permission traceable to the purpose; broad ones justified in writing |
| Can staff consent to third-party apps? | The user consent setting (ISM-2137) | Off, with a request process an administrator approves |
| Is consent activity logged centrally? | A search of the central logs (ISM-2139) | Consent grants, token issuance and token use all visible |
| Is device code sign-in blocked? | The sign-in policy and sign-in logs (ISM-2140) | Blocked, except named accounts on managed devices with a recorded need |
Nobody owns the list. Apps build up over years: trials, integrations a former employee set up, test apps. The platform lists them, but nobody is asked to look. Name an owner for the review and for each app.
Fear of breaking something. Revoking an app that a payroll or sales process quietly depends on stops that process. Ask the owner first; if nobody answers, remove the app on a set date and tell staff how to request it again.
Apps that ask for too much. Some offer only broad permissions. Ask the vendor for a narrower option, limit the app to the people who need it, or record the risk with the owner.
Smaller and larger organisations. A smaller organisation usually has one identity platform and a short list of apps, so its IT provider can switch off user consent, review the list and record the result in one sitting. A larger one often has many platforms, hundreds of apps and business units buying their own software, and needs tooling that gathers apps from every platform, owners who review their own apps, and a procurement step that gives each new app an owner and a purpose.
The business case. The cost is staff time twice a year and an approval step for new apps. What it buys is the removal of access that survives password resets, the route the attackers took in both public cases above.
Which of the products you already pay for help here? The free coverage check shows which ISM and Essential Eight controls your current products can reach, in about three minutes. To see ISM-2138 among the other identity controls, open it in our sample coverage report, or read what an ISM assessment involves.
ISM-2138 is new: ASD added it in the September 2026 release, at revision 0, with ISM-2137, ISM-2139 and ISM-2140, the four controls in the subsection "Third-party application access and device code authentication" of the new system access guidelines (ASD). The same release added ISM-2147 and ISM-2148 on protecting and revoking sessions and tokens. Our ISM September 2026 summary covers the rest of the latest release.