Skip to content
System access
ASD ISMISM-2138

ASD ISM 2138 Six-monthly review of OAuth application consents and granted permissions

What it says

OAuth application consents, including their granted permissions, are reviewed at least every six months, with unused applications and excessive permissions revoked.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

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.

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.

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.

How to implement

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

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

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

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

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

Keep it running

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.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the schedule or procedure that sets out how often OAuth application consents are reviewed and who is responsible.

    Look at

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

    Good evidence

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

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the records of the last two review cycles.

    Look at

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

    Good evidence

    Two completed reviews within the past twelve months, each covering every consented application and its granted permissions, with no gap exceeding six months.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the export of OAuth application consents and permissions used as the input to the most recent review.

    Look at

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

    Good evidence

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

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for evidence of applications that were revoked as unused during the most recent review.

    Look at

    Check the identity provider audit log or change records for the revocation events and confirm those applications no longer appear in the consented list.

    Good evidence

    Revocation events in the audit log line up with the review record, and the named applications are absent from the current consent list.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for examples where an application's permissions were reduced because they exceeded what it needed.

    Look at

    Compare the permission scopes before and after the review and look for the reasoning recorded for the change.

    Good evidence

    Clear before-and-after scope lists showing excessive permissions removed, with a documented justification and confirmation that the application still functions.

Mappings

Closest match in ISO/IEC 27001: A.5.18, Managing access rights to information assets, which asks for the same thing.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.5.18Managing access rights to information assetsEquivalent
  • A.5.15Access control policies and proceduresPartially meets
Essential Eight

ASD Essential Eight: 1 mapping

  • E8-RA-ML3.1Limit privileged access to what is necessary for dutiesSupports

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.