ISM-2138: Review OAuth App Consents Every 6 Months

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).

#What does ISM-2138 require?

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:

• A review at least every six months of every consent, "including their granted permissions": what each app can do, not only which apps are on the list.
• Unused applications revoked. ASD does not define unused. Our reading: no sign-in or token use since the last review, or nobody in the organisation can name the app's owner or purpose.
• Excessive permissions revoked. Our reading: any permission the app's purpose does not need, such as access to every mailbox for an app that reads one calendar.

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.

#Why does it matter?

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:

• An app compromised through its vendor. Google Threat Intelligence Group reported that from as early as 8 August 2025 to at least 18 August 2025 an actor "targeted Salesforce customer instances through compromised OAuth tokens associated with the Salesloft Drift third-party application", and noted the issue "does not stem from a vulnerability within the core Salesforce platform". Its advice included: "Ensure that applications have the minimum necessary permissions and avoid overly permissive scopes like full access" (Google).
• A forgotten app with too much access. In January 2024 Microsoft reported that, in an attack on its own corporate systems, "Midnight Blizzard leveraged their initial access to identify and compromise a legacy test OAuth application that had elevated access to the Microsoft corporate environment" (Microsoft). An old test app with broad permissions is what a six-monthly review should find and remove.

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.

#How does it fit with the other controls?

• ISM-2137 has an authorised administrator, not staff, grant consent to third-party apps. That goes further than common defaults: Google Workspace's default for apps an administrator has not configured is "Allow users to access any third-party apps", and Microsoft recommends allowing user consent "only for applications that have been published by a verified publisher". Both platforms offer a way for staff to request an app and an administrator to approve it (Google, Microsoft).
• ISM-2139 logs consent grants, token issuance and token use centrally. ASD's reason is "to support the detection of anomalous use", and the same logs tell the review which apps are still in use.
• ISM-2140 switches off the device code sign-in flow unless it is needed (see the next section).
• ISM-2148 revokes active sessions and refresh tokens when credentials are reset or compromised (see our ISM-0428 guide). After an account is compromised, do both: revoke the person's sessions, and check which apps that account consented to, because, as ASD notes, an app's tokens survive credential resets.

#What is device code phishing, and what does ISM-2140 ask?

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.

#How do you meet ISM-2138?

1. List every place apps hold consent. The identity platform behind your email and files first, then other cloud services where staff connect apps.
2. Export each platform's app list: publisher, who consented (an administrator or individual staff), permissions, number of users and last use. Google Workspace, for example, lists "Accessed apps" with the Google services each one requests, and can download the list (Google).
3. Give each app an owner and a purpose. An app nobody claims is a candidate for removal.
4. Revoke unused apps. Write the test down, such as no sign-in or token use since the last review, and check it against the central logs (ISM-2139).
5. Trim permissions to the purpose. Replace broad permissions with narrower ones where the app offers them; where it does not, record the risk and the owner's acceptance, or replace the app.
6. Stop the same grants coming back. Microsoft notes that "Revoking the current granted permission doesn't stop users from re-consenting to the application's requested permissions" (Microsoft), so switch off user consent (ISM-2137) before or with the first clean-up.
7. Record the review: the date, the reviewer, each decision and each revocation. Book the next one within six months.
8. Review early when something changes: the vendor of a connected app reports an incident, an app's owner leaves, or an app asks for new permissions.

#What evidence shows ISM-2138 is met?

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

#What gets in the way?

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.

#What tools and skills help?

• The identity platform's own settings and reports: user consent switched off, a request process, and the list of apps with their permissions. Microsoft, for example, documents how to review and revoke an app's permissions, and Google how to mark each app Trusted, Limited, Specific Google data or Blocked (Microsoft, Google).
• Access review features in identity governance tools, which schedule the review, send each app owner their list and record the decisions.
• A cloud app security tool (sometimes called SaaS security posture management) that gathers connected apps and their permissions from many cloud services and flags the risky ones.
• A central log platform that keeps consent and token events (ISM-2139) long enough to show each app's last use.
• Sign-in policies that block the device code flow and allow named exceptions (ISM-2140), such as the Conditional Access policies Microsoft describes (Microsoft).
• Skills: someone who can read OAuth permission names, tell an app acting for one person from one acting for the whole organisation, and knows which processes depend on which apps.

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.

#What changed in recent ISM releases?

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.

#Sources

• ASD, Information security manual: ISM-2137 to ISM-2140, ISM-2148, and the section guidance quoted on this page
• ASD, ISM September 2026 changes
• Microsoft, Configure how users consent to applications
• Microsoft, Review permissions granted to enterprise applications
• Microsoft, Conditional Access: Authentication flows
• Microsoft, Block authentication flows with Conditional Access policy
• Microsoft Threat Intelligence, Storm-2372 conducts device code phishing campaign (February 2025)
• Microsoft Threat Intelligence, Midnight Blizzard: Guidance for responders on nation-state attack (January 2024)
• Google Threat Intelligence Group, Widespread Data Theft Targets Salesforce Instances via Salesloft Drift (August 2025)
• Google, Control which apps access Google Workspace data
• IETF, RFC 8628: OAuth 2.0 Device Authorization Grant (August 2019)