App consent policies and the admin consent workflow

Every OAuth application that touches your Microsoft 365 data got in through a consent prompt — someone, at some point, clicked "Accept" on a permissions screen. App consent policies in Entra ID control who can click that button and for what, and they're one of the highest-leverage security settings in the tenant. The default history here is ugly: for years, any user could consent to third-party apps reading their mail, files, and contacts, and attackers noticed.

Why this matters: consent phishing

Consent phishing is the attack that makes this a priority rather than housekeeping. The attacker registers an innocuous-looking app ("Document Viewer Pro", "Meeting Assistant"), sends users a legitimate Microsoft sign-in link, and the user sees a real login.microsoftonline.com page asking to grant the app permission to read their mail and files. No password is stolen, MFA is irrelevant — the user authorises the attacker's app, which then holds tokens that keep working until someone revokes them.

This defeats most of the controls organisations rely on. Password resets don't help; the app has its own grant. MFA doesn't help; the sign-in was genuine. Only two things help: restricting what users can consent to in the first place, and finding and revoking bad grants fast.

What an app consent policy controls

An app consent policy defines which permissions users may grant to which apps without admin involvement. Entra ID ships three built-in options, configured under Enterprise applications → Consent and permissions:

• Do not allow user consent — everything routes through admins. Maximum control, maximum friction.
• Allow user consent for apps from verified publishers, for selected permissions (the recommended baseline) — users can self-serve low-impact delegated permissions (basic sign-in and profile) from publishers who've verified their identity with Microsoft; everything else needs an admin.
• Allow user consent for apps (the legacy default) — users can grant any delegated permission to any app. If your tenant still has this, changing it is this quarter's job.

Custom policies (via Graph or PowerShell) let you fine-tune the permission list, but the recommended built-in is the right answer for almost everyone. Note the scope: user consent only ever covers delegated permissions — application permissions (app-only access, no signed-in user) always require admin consent regardless of policy.

The admin consent workflow: the half people skip

Locking down user consent without giving users a paved road creates a new problem: legitimate requests die in the dark, and frustrated users find workarounds — or IT quietly relaxes the policy after the third escalation. The admin consent workflow is the paved road: when a user hits a permission they can't grant, they get a "request approval" button instead of a dead end. Designated reviewers get notified, see the app, publisher, and requested permissions, and approve or deny in one place; the user gets an answer instead of silence.

Turn it on the same day you tighten the consent policy. Assign at least two named reviewers (not a shared mailbox nobody owns), set the request expiry so stale requests don't rot, and agree on a review standard before the first request arrives — otherwise every decision is improvised.

How to review a consent request

A workable rubric for reviewers, in order:

1. Who's the publisher? Verified publisher with a real company behind it, or an unverified app registered last week? Unverified plus data-access permissions is a strong no.
2. Do the permissions match the app's job? A PDF viewer requesting Mail.Read is answering its own question. Least privilege applies to apps exactly as it does to admins.
3. Delegated or application permissions? Application permissions mean tenant-wide access with no user in the loop — the bar should be much higher, and the request should come with a business owner attached.
4. Is there an existing sanctioned alternative? Half of app requests duplicate something already approved.
5. Grant narrowly. Prefer consenting for the specific user or group over tenant-wide admin consent when the app serves one team.

Write the outcomes down, even as a simple list. "Why does this app have these permissions" is a question you will be asked — by an auditor or by an incident responder.

The other half: reviewing what's already there

Tightening consent policy governs new grants; it does nothing about the accumulated sediment of years under the legacy default. Schedule a recurring review of existing grants: the Enterprise applications list filtered to recent consent activity, Defender for Cloud Apps' OAuth app governance (App governance, included with E5 or as an add-on) for risk-scored triage, or plain Graph PowerShell dumping service principals with their OAuth2 permission grants sorted by scope breadth.

Prioritise ruthlessly: unverified publishers with mail/files access, apps with application permissions nobody remembers approving, and grants from users who've since left. Revoking a grant is low-drama — if the app mattered, someone will request it again through the workflow, which is exactly how the system should work.

The rollout, in one afternoon

1. Check your current policy under Consent and permissions; if it's the legacy default, switch to the recommended verified-publisher baseline.
2. Enable the admin consent workflow with two named reviewers and an agreed rubric.
3. Communicate the change — one short message: "you may see a request-approval step for new apps; here's why."
4. Export existing grants and book the cleanup review as a recurring task, not a one-off.

Few controls in Microsoft 365 buy this much attack-surface reduction for this little user impact. The consent prompt is the front door to your tenant's data — an app consent policy decides who holds the keys, and the workflow keeps the door usable.