ASD ISM 2137 Block user OAuth consent, reserve it for authorised administrators
What it says
Human users are prevented from granting consent to third-party OAuth applications, with such consent granted only by an authorised administrator.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOrdinary users cannot approve third-party OAuth apps to access organisational data or accounts. Only an authorised administrator can grant that consent, after review.
Many cloud platforms let a person click "Accept" when a third-party app asks for permission to read their mail, files, calendar or contacts. That single click can hand an outside application ongoing access to organisational data through an OAuth token, with no password needed afterwards. This control turns that user-level consent off. When a third-party OAuth application asks for access, the request cannot be approved by the person using the app. Only an authorised administrator can grant consent, which means someone with the right knowledge looks at what the app is, who publishes it and what permissions it wants before access is given. It matters because "consent phishing" is a common attack: an adversary publishes a convincing app, tricks a user into approving it, and then reads mailboxes or files quietly through the granted token, even after the user changes their password. Removing the ability for users to consent closes that door and puts every third-party app through a deliberate approval decision.
Free. Save your status, tasks and notes.
Why it matters
If users can consent to third-party OAuth applications themselves, an adversary only needs one person to click "Accept" on a malicious or over-privileged app to gain persistent access to mail, files and other organisational data. That access survives password resets, bypasses multi-factor authentication on later sign-ins and is easy to miss, so data can be exfiltrated for a long time before anyone notices. Unvetted legitimate apps also accumulate broad permissions nobody reviewed, expanding the attack surface and complicating incident response.
How to implement
Identity administrators: in each identity platform that supports OAuth consent (for example the organisation's cloud identity tenant), set the user consent policy so that users cannot consent to third-party applications at all, then test with a standard user account to confirm the consent prompt is blocked.
Identity administrators: enable the platform's admin consent request workflow so that a blocked user request is forwarded to a named approval queue rather than silently failing, and configure notifications so requests reach the approvers.
Security lead: define the authorised administrator role that may grant OAuth consent, assign it to a small named group through role-based access, and remove consent-granting rights from all other administrator roles.
Approvers: use a short written checklist when granting consent (publisher verified, business need confirmed, permissions limited to what the app needs, data classification acceptable) and record the decision, the requester and the approver for each application.
Identity administrators: export the current list of applications and service principals that already hold delegated or application consent, have the authorised administrator review each one, and revoke consent for apps that are unknown, unused or over-privileged.
Keep it running
Day to day, the identity platform (for example a cloud identity tenant) is configured so the user consent setting is disabled, and requests for a third-party OAuth application are routed to an authorised administrator instead of being approved on the spot. Users will see a message that admin approval is required, so expect a steady trickle of requests and give administrators a simple way to receive and record them.
Administrators review each request against what the app is, who publishes it and which permissions it asks for, then grant or reject consent. Keep the set of people allowed to grant consent small and tied to a defined role, and re-check it when staff change. Periodically confirm the consent setting has not drifted back to allowing user consent, and review the list of applications that already hold consent so anything granted before the control was applied is reassessed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for a screenshot or export of the user consent settings from each identity platform the organisation uses for OAuth.
Look at
Check whether the setting allows users to consent to third-party applications, either fully or for low-risk permissions.
Good evidence
User consent to third-party applications is disabled entirely, with no exceptions for low-risk permissions or verified publishers.
- Check 2 of 5What an auditor asks for
Ask for
Ask who is able to grant admin consent to OAuth applications and how that permission is assigned.
Look at
Look at the role assignments and group membership behind the consent-granting privilege.
Good evidence
A small, named set of authorised administrators holds the privilege through a defined role, and no standard user or unrelated admin role can grant consent.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the consent event log or audit log covering a recent period.
Look at
Look at who approved each consent event and whether any were granted by non-administrator accounts.
Good evidence
Every consent grant in the period was performed by an authorised administrator account, and there are no user-granted consents after the control was applied.
- Check 4 of 5What an auditor asks for
Ask for
Ask to see the admin consent request workflow and a sample of recent requests.
Look at
Look at how a user's blocked request reaches an approver, what the approver reviewed and what decision was recorded.
Good evidence
Requests are routed to the authorised administrators, each decision is recorded with the requester, the app, the permissions and the approver, and rejected apps show a reason.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the current inventory of third-party applications that hold consent in the tenant.
Look at
Look for apps with broad permissions, unknown publishers or consents that pre-date the control and have not been reviewed.
Good evidence
The inventory has been reviewed by an authorised administrator, legacy user-granted consents have been reassessed, and unnecessary or unknown apps have had consent revoked.
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-2137 requires that human users are prevented from granting OAuth consent to third-party applications, reserving approval to an authorised administrator. Annex A 5.15 requires the organisation to establish and implement rules and procedures to control logical access based on business and security requirements, which is the broader governance mechanism that would include an OAuth-consent restriction rule. ISM-2137 is a specific access-control policy enforcement use case, while Annex A 5.15 covers access control policy/procedure across many assets and access methods beyond OAuth.
This control partially meets A.5.18.
ISM-2137 requires restricting the ability to grant OAuth consent so that only an authorised administrator can approve third-party application access. Annex A 5.18 covers provisioning, reviewing, modifying, and removing access rights to information assets in line with access control rules, which would include controlling who can grant and revoke third-party application access. ISM-2137 is a specific rule about the consent-grant mechanism, while Annex A 5.18 is broader across the full access-rights lifecycle and many access types.
This control partially meets A.8.3.
ISM-2137 requires preventing standard users from authorising third-party OAuth applications, with only authorised administrators able to grant consent. Annex A 8.3 requires restricting access to information and other associated assets in accordance with the organisation's access control policy, which can include restricting who can authorise third-party app access to organisational data. Annex A 8.3 is broader and asset-centric, whereas ISM-2137 targets a specific consent-granting pathway (OAuth) and administrative approval model.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML1.1.
ISM-2137 requires that only an authorised administrator can grant OAuth consent to third-party applications, preventing end users from doing so. E8-RA-ML1.1 requires validation of requests for privileged access when first requested, which aligns with the idea that elevated approvals (including app authorisations that effectively grant access) should be reviewed before being granted. E8-RA-ML1.1 is about validating privileged access requests generally, while ISM-2137 is specifically about third-party OAuth consent controls in identity platforms.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.