ASD ISM 2138Six-Monthly Review of OAuth Application Consents and Granted Permissions
Check every OAuth app consent and its permissions at least twice a year, then revoke apps nobody uses and permissions that go beyond what the app needs.
Plain language
When a user or administrator consents to an OAuth application (for example a third-party add-in, a SaaS integration or an automation tool) that application is granted a set of permissions to act against your tenant or accounts: reading mail, accessing files, managing users and so on. Those consents persist silently. The person who granted them may leave, the application may fall out of use, or the vendor may have asked for far more scope than the job needed. Attackers know this and actively target consented applications, either by compromising the vendor or by tricking users into consenting to a malicious app, because a valid OAuth token bypasses passwords and often multi-factor authentication. This control requires a review of all OAuth application consents, including the specific permissions each has been granted, at least every six months. The review must produce action: applications that are no longer used are revoked, and permissions that exceed what an application genuinely needs are removed. The point is to keep the set of applications with standing access to your environment small, current and least-privileged.
Framework
ASD Information Security Manual (ISM)
Control effect
Detective
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
OAuth application consents, including their granted permissions, are reviewed at least every six months, with unused applications and excessive permissions revoked.
Why it matters
Without periodic review, the number of consented applications and the permissions they hold only ever grows. Forgotten or abandoned applications keep valid access tokens that nobody is watching, and over-scoped applications give a compromised vendor or a malicious app a wide path into mail, files and directory data. A breach through one of these consents can look like legitimate application activity and go unnoticed for a long time, and the organisation will struggle to explain to regulators or customers why an unused application still had access to their data.
Operational notes
Treat this as a recurring calendar task with a named owner, run at least every six months and ideally aligned with other access reviews. Each cycle, export the full list of OAuth application consents from every identity platform you operate (tenant-wide admin consents and individual user consents both count), together with the permission scopes granted to each. For every application, confirm with the business owner that it is still in use and that each permission is needed; where nobody can vouch for an application, treat it as unused and revoke it. Where an application needs to stay but holds broader permissions than its function requires, remove the excess scopes and re-test the integration. Record the decisions and actions taken so the next cycle can start from a known baseline, and keep an eye on sign-in or usage data between cycles to spot applications that have gone quiet.
Implementation tips
- Identity or security administrators enumerate every OAuth application consent across all identity providers (including both admin-consented and user-consented applications) by exporting the enterprise application or consented app list along with each application's granted permission scopes, and store that export as the baseline for the review.
- The identity team schedules the review as a recurring task at least every six months, assigns a named owner, and puts it in the same calendar or ticketing system used for other access reviews so it cannot be missed.
- For each application in the export, the review owner records a business owner and asks them to confirm whether the application is still in use and what it actually does; the owner uses last sign-in or token usage data from the identity provider to challenge answers where an application has shown no activity.
- The review owner revokes consent for any application that is unused, abandoned or that nobody can justify, and for applications that remain, removes any permission scope that is broader than the function requires (for example replacing full mailbox or directory write scopes with read-only or narrower equivalents), then confirms with the business owner that the integration still works.
- The identity team records the outcome of each cycle (applications reviewed, revoked, and permissions reduced, with dates and approvers) and updates the baseline export so the next six-monthly review starts from the current state.
Audit / evidence tips
- AskAsk for the schedule or procedure that sets out how often OAuth application consents are reviewed and who is responsible.Look atLook for a defined frequency of at least every six months, a named owner, and coverage of both permissions and the revocation of unused applications and excessive scopes.GoodA documented procedure exists with a six-monthly (or more frequent) cadence, a named owner, and explicit steps for revoking unused applications and reducing excessive permissions.
- AskAsk for the records of the last two review cycles.Look atCheck the dates of each review and confirm the gap between them is no more than six months, and that each record shows the full list of applications and permissions considered.GoodTwo completed reviews within the past twelve months, each covering every consented application and its granted permissions, with no gap exceeding six months.
- AskAsk for the export of OAuth application consents and permissions used as the input to the most recent review.Look atCompare it against the live application consent list in the identity provider to confirm the review covered everything, including user-consented applications, not just admin-approved ones.GoodThe reviewed list matches the current tenant state, and any applications added since the review are recent and awaiting the next cycle rather than having been missed.
- AskAsk for evidence of applications that were revoked as unused during the most recent review.Look atCheck the identity provider audit log or change records for the revocation events and confirm those applications no longer appear in the consented list.GoodRevocation events in the audit log line up with the review record, and the named applications are absent from the current consent list.
- AskAsk for examples where an application's permissions were reduced because they exceeded what it needed.Look atCompare the permission scopes before and after the review and look for the reasoning recorded for the change.GoodClear before-and-after scope lists showing excessive permissions removed, with a documented justification and confirmation that the application still functions.
Cross-framework mappings
How ISM-2138 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 5.15 | ISM-2138 requires a specific access control procedure of reviewing OAuth application consents and granted permissions at least every six ... | |
linkRelated(1)expand_less | ||
| Annex A 5.18 | ISM-2138 requires reviewing OAuth consents and permissions every six months, revoking unused permissions, directly aligning with Annex A ... | |
E8
| Control | Notes | Details |
|---|---|---|
handshakeSupports(1)expand_less | ||
| E8-RA-ML3.1 | ISM-2138 requires six-monthly review of OAuth application consents and permitted permissions, revoking unused apps and excessive permissions | |
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.