ASD ISM 2137Block User OAuth Consent, Reserve It for Authorised Administrators
Ordinary users cannot approve third-party OAuth apps to access organisational data or accounts. Only an authorised administrator can grant that consent, after review.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
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
Human users are prevented from granting consent to third-party OAuth applications, with such consent granted only by an authorised administrator.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for a screenshot or export of the user consent settings from each identity platform the organisation uses for OAuth.Look atCheck whether the setting allows users to consent to third-party applications, either fully or for low-risk permissions.GoodUser consent to third-party applications is disabled entirely, with no exceptions for low-risk permissions or verified publishers.
- AskAsk who is able to grant admin consent to OAuth applications and how that permission is assigned.Look atLook at the role assignments and group membership behind the consent-granting privilege.GoodA small, named set of authorised administrators holds the privilege through a defined role, and no standard user or unrelated admin role can grant consent.
- AskAsk for the consent event log or audit log covering a recent period.Look atLook at who approved each consent event and whether any were granted by non-administrator accounts.GoodEvery consent grant in the period was performed by an authorised administrator account, and there are no user-granted consents after the control was applied.
- AskAsk to see the admin consent request workflow and a sample of recent requests.Look atLook at how a user's blocked request reaches an approver, what the approver reviewed and what decision was recorded.GoodRequests 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.
- AskAsk for the current inventory of third-party applications that hold consent in the tenant.Look atLook for apps with broad permissions, unknown publishers or consents that pre-date the control and have not been reviewed.GoodThe inventory has been reviewed by an authorised administrator, legacy user-granted consents have been reassessed, and unnecessary or unknown apps have had consent revoked.
Cross-framework mappings
How ISM-2137 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 5.15 | ISM-2137 requires that human users are prevented from granting OAuth consent to third-party applications, reserving approval to an author... | |
| Annex A 5.18 | ISM-2137 requires restricting the ability to grant OAuth consent so that only an authorised administrator can approve third-party applica... | |
| Annex A 8.3 | ISM-2137 requires preventing standard users from authorising third-party OAuth applications, with only authorised administrators able to ... | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| E8-RA-ML1.1 | ISM-2137 requires that only an authorised administrator can grant OAuth consent to third-party applications, preventing end users from do... | |
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.