Why tenant-wide admin consent deserves a change ticket

01 / 11

A free PDF tool, approved for everyone, on day two

Consider a fictional 70-person architecture practice, labelled hypothetical throughout. A new IT hire spends their second day clearing a backlog of vendor sign-in requests, and one of them is a browser add-on that promises to compress and merge PDFs for the whole firm. It asks for permission once, at the top of the tenant, rather than from each person who wants to use it.

The new hire holds the role that can grant it. They click Accept. The request disappears, the add-on starts working, and nobody else at the firm ever sees a consent prompt for it — because there is nothing left for them to approve.

Nothing about that click was reckless. It matches what most tenant-wide admin consent requests actually look like: an ordinary app, a small ask, one person clearing a queue on a Tuesday. That is exactly why it deserves the discipline of a production change, and almost never gets it.

02 / 11

What one click of tenant-wide admin consent actually grants

Microsoft is specific about the effect, and it is broader than most people expect the first time they read it. By default, granting tenant-wide admin consent to an application allows all users to access the application unless otherwise restricted. Not the department that asked for it. Everyone with an account in the tenant, unless the person granting it takes an extra step to narrow that down.

Microsoft also names the ceiling on what a request like this can be asking for: admin consent is a sensitive operation, potentially allowing the application's publisher access to significant portions of the organization's data, or the permission to do highly privileged operations — its own examples run to role management, full mailbox access and full user impersonation. Most apps requesting tenant-wide consent are not asking for anything close to that. Some are, and the consent screen looks the same either way.

Only a short list of roles can even present the button: Privileged Role Administrator for any API, or Cloud Application Administrator, Application Administrator, AI Administrator or a scoped custom role for everything short of Microsoft Graph application permissions. That is a narrower list than most tenants assume, and worth checking against who currently holds those roles — a separate exercise from this post, but the natural next one.

03 / 11

The grant itself has no expiry date

Here is the detail that turns a single click into an open-ended one. The record Microsoft creates for a tenant-wide grant is an object it calls oAuth2PermissionGrant. Its documented properties are the client, the consent type, an id, a principal id, a resource id and the scope string. There is no expiration property anywhere on that list.

That is not a gap we are reading into the schema — it is the entire property table, and expiry is simply not one of the fields. The only lifecycle event Microsoft documents for that object is deletion: When a delegated permission grant is deleted, the access it granted is revoked. Deleting it, in the admin center, means opening the app's Permissions tab and choosing Revoke permission by hand.

Compare that with the admin consent workflow, covered below, where an unreviewed request can be set to expire after a number of days you choose. That expiry belongs to the request for permission, not to the permission itself. Once a tenant-wide grant exists, nothing in Microsoft's own data model schedules its end — our reading of the two pages side by side, not a line Microsoft states outright.

04 / 11

Why this is a production change

A production change, in most shops, gets a ticket, a named approver and a way to back it out. Tenant-wide admin consent gets a button. Our argument, and we are labelling it as ours: those two things should look more alike than they do, because the reach is comparable and the undo is not automatic.

The figure below puts the two facts that matter next to each other. Every current user in the tenant can reach the app the moment consent is granted, and the record Microsoft keeps of that grant carries no field that ends it on its own. A change with that reach, in most other systems, would not ship on one click from one person with nobody else looped in.

05 / 11

The three settings that decide who else can do this

Tenant-wide admin consent is not the only door into a tenant. Microsoft gives every organisation three settings for what an ordinary user, holding no special role, can consent to on their own: Disable user consent, which removes the option entirely; a middle setting limited to apps from verified publishers, or registered in your own tenant, requesting only permissions your own administrators have classified as low impact; and Allow user consent for apps, which lets any user consent to any permission that does not require admin consent, for any application.

Microsoft's own recommendation names a direction, if not one specific setting of the three: we recommend that you allow user consent only for applications that have been published by a verified publisher. Whichever of the three a tenant is running today was chosen by someone, or inherited from whatever the tenant shipped with — worth finding out which, in the same sitting where you check who can grant tenant-wide consent.

06 / 11

A review step you can turn on before the next click

The admin consent workflow adds a stop between a request and a grant. Once it is turned on, a user who hits a permission wall can request admin consent instead of being stuck, and the request routes to reviewers you name, who can view, block, or deny it — though approving a request for Microsoft Graph application permissions specifically still needs a Global Administrator.

Turning it on is a short trip through Enterprise apps, Consent and permissions, and Admin consent settings, and Microsoft notes it can take up to an hour to take effect after you save it. Nothing routes to a reviewer until someone does this. Microsoft's documentation gives the steps to switch it on; it does not say a tenant arrives with it already running, so we are not claiming that either way.

You also choose how long an unreviewed request stays open, in the Consent request expires after (days) setting. That expiry is real, and it belongs to the request, not to the grant that results if the request is approved — the distinction from the section above.

07 / 11

Consent policies: narrowing who can approve what

Beyond the three blanket settings, Microsoft supports custom app consent policies: rules built from condition sets that describe a consent request by traits such as verified-publisher status, the permission's classification, or which API is being asked for. A policy can be tied to a role, so only the people holding it can approve consent that matches its conditions.

This is the tool for a rule narrower than no user consent at all — letting a help-desk role approve low-impact requests from verified publishers, say, while routing anything else to a smaller admin group. It takes more setup than the three-way toggle above, and it earns that setup once the toggle stops matching how the organisation actually works.

08 / 11

The audit entry a consent leaves behind

Every consent, tenant-wide or not, writes an entry to the Entra audit log under the ApplicationManagement category, with the activity name Consent to application. A related Restore consent activity appears when a previously revoked grant is put back. Both are searchable the same way as any other audit event: by date, by the person who performed it, and by the application it names.

That log entry answers a question a change-ticket process asks automatically and a single click does not: who approved this, and when. If nobody is looking at the log, the answer still exists. It is just waiting to be asked for, usually after something has already gone wrong.

09 / 11

Reviewing what has already been granted

None of the above helps with consent that already happened before anyone was watching for it, which describes most tenants. The review path is the same Permissions tab mentioned earlier: Enterprise apps, All applications, the app in question, then Permissions, then the Admin consent tab for whatever was granted tenant-wide.

Revoking there removes the grant, but Microsoft is explicit that it does not stop the app asking again: Revoking the current granted permission doesn't stop users from re-consenting to the application's requested permissions. Stopping that for good means changing the user-consent setting from the earlier section, adding a consent policy that excludes the app, or removing the application's ability to request the permission at all.

10 / 11

Five ways consent happens, side by side

The paths mostly differ in who can start them and how the access ends. Read the last column first — it is the fastest way to see which of these basically police themselves and which need the change-ticket habit this post is arguing for.

11 / 11

Where to start

Before the next consent request lands on anyone's screen, do two things this week: check which roles in your tenant can currently grant tenant-wide admin consent, and open Enterprise apps, then Consent and permissions, to see which of the three user-consent settings you are actually running. Neither requires a purchase, and both take less time than the incident that can follow an ungoverned grant.

Disclosure: this is a category we sell into. Avalon CloudSec is a read-only Microsoft 365 and Azure monitoring service Avalon Web Services runs for customers; every Microsoft Graph permission it holds is *.Read.All, so it cannot grant, change or revoke a consent itself. What it can do is list the enterprise applications and OAuth grants already in a tenant, including which ones carry tenant-wide consent, flag a high-risk app that has no registered owner as a governance finding, and show what changed if a grant's permissions drift after the fact. It does not replace the admin consent workflow, the user-consent settings, or the click in Enterprise apps that actually revokes anything — those stay with your team, in Microsoft's own screens. If you want a second set of eyes on what your tenant has already approved, email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.