Disable User OAuth App Consent: Unreviewed Third-Party App Access Risk

Why this risk matters

By default, Microsoft 365 allows users to consent to third-party applications accessing their account data directly — without any administrator review. When a user clicks Accept on an OAuth consent prompt, they grant the application access to read their emails, files, calendar, or contacts, depending on what permissions the app requests.

This default creates a significant attack surface. Malicious apps disguised as productivity tools, document viewers, or AI assistants can trick users into granting broad permissions that give the attacker persistent, MFA-bypassing access to the user's data. Unlike credential phishing, this access survives password resets because it is tied to an OAuth token, not a password.

Restricting user consent forces all third-party app authorisations through an administrator review step. This doesn't block legitimate app usage — it adds a human checkpoint before access is granted. For most organisations, this is the right default. The companion control — enabling the admin consent workflow — ensures users still have a path to request app access.

What happens if this is abused

  • Users consent to apps requesting Mail.Read, Files.ReadWrite, Contacts.Read, or similar broad permissions without any admin review
  • A convincing fake productivity app gains access to every email in a user's mailbox through a single consent click
  • OAuth tokens granted via user consent survive password resets and persist until explicitly revoked
  • Tenant-wide exposure multiplies when a phishing campaign targets many users simultaneously, each granting access via their own consent
  • Legitimate-looking apps registered by attackers accumulate broad access across the tenant without triggering any security alert
  • Access persists silently in the Enterprise Applications list, often never reviewed after the initial consent

When this is expected or acceptable

Some organisations have reasons to allow more flexible consent:

  • Organisations with a mature admin consent workflow may allow verified publisher apps to be consented by users as a convenience for well-known, low-risk applications
  • Developer populations may need more flexibility to consent to test apps as part of their workflow
  • Managed service environments where third-party integrations are frequently deployed may want a streamlined consent path for specific app categories

The safest default is to disable user consent entirely and redirect all requests through the admin consent workflow. If you allow user consent for verified publisher apps only, ensure that policy is explicitly configured rather than left as an open default.

Checks to perform before taking action

  • In Entra ID > Enterprise Applications, review the full list of apps users have already consented to — assess whether any should be revoked before enforcing the new policy
  • Confirm the admin consent workflow is configured and designated reviewers are assigned before restricting user consent — requests should not fail silently
  • Pre-grant admin consent for known, legitimate applications your organisation relies on so users aren't blocked from day one
  • Communicate the change to users so they understand why app consent requests now require approval and how to submit a request
  • Check the current User consent setting in Entra ID > Enterprise Applications > Consent and permissions > User consent settings

Safe remediation steps

  1. First enable the admin consent workflow (Entra ID > Enterprise Applications > Consent and permissions > Admin consent settings) — this is a prerequisite before restricting user consent
  2. Assign designated reviewers to the admin consent workflow and configure notification emails
  3. Pre-grant admin consent for critical business applications currently relying on user consent
  4. In Entra ID > Enterprise Applications > User settings, set user consent to "Do not allow user consent"
  5. Monitor the admin consent request queue and establish a review SLA (e.g. 2 business days)
  6. Communicate to users how to submit app access requests and what to expect

Related risks and follow-on checks

After enforcing this control, review these related areas:

  • Apps with Risky Permissions — review existing user-consented apps for overly broad permissions; this control prevents new risky consents but doesn't clean up existing ones
  • OAuth Phishing via First-Party Microsoft Apps — blocking user consent reduces but doesn't eliminate OAuth phishing risk; combine with Disable Device Code Flow
  • Dormant Apps — after restricting new consent, audit existing consented apps for those no longer in use
  • Enable Admin Approval for App Consent — deploy this companion policy at the same time to ensure users have a legitimate request path
TBD CTA