Enable Admin Approval for App Consent: Safer App Access Review

Why this risk matters

Disabling user OAuth consent is the right first step — but without a way for users to legitimately request app access, you either block real work or push people toward shadow IT. The admin consent workflow solves this by giving users a structured path to request app access, while ensuring an administrator reviews and approves it before any permissions are granted.

When enabled, users who need a third-party app submit a request with context on what they need and why. Designated reviewers receive a notification, review the app's requested permissions and publisher, and approve or deny. This creates a documented record of every app granted access to your tenant, replaces invisible user-level consents with a visible governed process, and prevents malicious apps from slipping through under the guise of user productivity.

This policy is the necessary companion to disabling user consent. They should always be deployed together.

What happens if this is abused

  • Users who can't consent and have no request pathway attempt workarounds — personal accounts, shadow IT, or pressure on admins to re-enable open consent
  • Without a structured workflow, app approval decisions are made ad hoc, without a record, and without consistent review of permissions being granted
  • Legitimate app access is blocked with no resolution path, creating friction that can lead to the user consent restriction being reversed
  • No audit trail of which apps have been reviewed, who approved them, and why — making future security reviews impossible
  • Unreviewed apps accumulate in the tenant over time with no accountability

When this is expected or acceptable

Most organisations benefit from the native admin consent workflow. Some scenarios may warrant a different approach:

  • Very small organisations where the IT admin is already directly approving all app requests informally — though even here a formal record is valuable
  • Organisations using a PAM or ITSM tool (ServiceNow, Jira Service Management) may prefer to route consent requests through those systems and use the Entra workflow as a fallback

In all cases, there should be a named person or team responsible for reviewing consent requests, and a defined response SLA so requests don't sit unreviewed for weeks.

Checks to perform before taking action

  • Confirm that designated reviewers are assigned in the admin consent workflow configuration before enabling it — the workflow is ineffective if no one receives requests
  • Ensure reviewers understand what to look for when evaluating an app: publisher verification status, requested permissions, whether the app is in the Microsoft app gallery, and whether the requesting user has a legitimate business need
  • Set up email notification routing so reviewers are alerted promptly
  • Communicate to users how to submit a consent request and what information to include in the request
  • Establish and document a review SLA — typically 2 business days

Safe remediation steps

  1. In Entra ID > Enterprise Applications > Consent and permissions > Admin consent settings, enable "Users can request admin consent to apps they are unable to consent to"
  2. Assign designated reviewers — typically IT security leads, compliance officers, or senior admins
  3. Configure email notifications for reviewers
  4. Document the review SLA and communicate it to users
  5. Enable this workflow before or simultaneously with disabling user consent (see Disable User OAuth App Consent)
  6. Monitor the request queue weekly and review pending requests within the defined SLA
  7. Periodically audit approved app consents to confirm they are still needed and appropriate

Related risks and follow-on checks

After enabling this control, review these related areas:

  • Disable User OAuth App Consent — this policy and the admin consent workflow should be deployed together; neither is complete without the other
  • Apps with Risky Permissions — use the consent workflow audit trail to review apps that were approved and confirm permissions are still appropriate
  • Dormant Apps — approved apps that are no longer actively used should have their consent revoked
  • OAuth Phishing via First-Party Microsoft Apps — a governed consent process reduces the OAuth phishing surface; combine with blocking device code flow for layered protection
TBD CTA