Admin consent in Microsoft Entra explained for MSPs

A customer is asked to give an MSP's tool access to their Microsoft 365 tenant. The mechanism for that is admin consent. Whoever grants it should know what gets created in the tenant, which permissions are needed and how to remove the access again.

Consent in Entra: two kinds of consent, two kinds of permission

Microsoft Entra ID has two kinds of consent:

User consent: a user allows an app to access data on their behalf. The grant applies to that user only.
Admin consent: an administrator allows an app access for the whole organization. No user is asked afterwards.

There are also two permission types:

Delegated permissions work in the context of a signed-in user. The app can do at most what that user can do. Users can grant many of them themselves, high-privilege ones only an admin.
Application permissions (in Graph also called app roles) work without a signed-in user. Application permissions always require admin consent.

A monitoring service for expiring secrets runs without a user. It needs application permissions and therefore admin consent.

What tenant-wide admin consent does technically

A multi-tenant app has exactly one app registration, and it lives in the vendor's tenant. During admin consent, Entra creates a service principal in the customer tenant. In the portal it appears under Enterprise applications. It is the local instance of the app.

The granted permissions hang off this service principal:

Application permissions are stored as an appRoleAssignment: the app's service principal is assigned an app role of the resource Microsoft Graph.
Delegated permissions are stored as an oAuth2PermissionGrant with consentType set to AllPrincipals, the tenant-wide grant for all users.

If the vendor later changes the requested permissions, they only take effect after a new consent, which may replace earlier tenant-wide grants.

The admin consent URL

The vendor sends the customer's admin to the admin consent endpoint of the Microsoft identity platform. Version 2 of the endpoint looks like this:

https://login.microsoftonline.com/{tenant}/v2.0/adminconsent
    ?client_id={application-client-id}
    &scope=https://graph.microsoft.com/.default
    &redirect_uri={registered-redirect-uri}
    &state={opaque-value}

The parts:

Tenant segment: the customer's tenant ID, a verified domain of the customer, or the placeholder organizations. With organizations the consent lands in the home tenant of the admin who signs in. common is not meant for admin consent.
adminconsent: the path that makes Entra require an authorized administrator and ask tenant-wide.
client_id: the Application (client) ID from the vendor's registration. It decides who gets access, so it is the value to verify.
scope: https://graph.microsoft.com/.default requests every permission configured in the registration. For application permissions, .default is mandatory.
redirect_uri: must exactly match a redirect URI registered on the app. Entra sends the result there.
state: any value, returned unchanged, so the vendor can match the response.

The older endpoint without v2.0 still works and requests all registered permissions without a scope. After a successful consent, Entra redirects to the redirect URI with admin_consent=True and the customer's tenant ID as parameters.

Who may consent and what the prompt shows

Tenant-wide consent for Microsoft Graph application permissions can be granted by a Global Administrator or a Privileged Role Administrator. Application Administrator and Cloud Application Administrator can consent tenant-wide, but not for Graph application permissions. A monitoring service with Application.Read.All therefore needs one of the first two roles.

The consent prompt shows:

the name of the app,
the publisher, either with a blue verified badge or with the word "Unverified",
the list of requested permissions. The chevron next to each permission opens its description.

The description reveals the type: application permissions end in "without a signed-in user", delegated ones in "on behalf of the signed-in user". Admins arriving via the admin consent endpoint see a prompt whose title and text make clear that the grant applies to the whole organization. Admins who open the app the normal way see the checkbox "Consent on behalf of your organization"; without the tick, consent applies to their own account only.

The vendor side: multi-tenant and verified publisher

Customers from other tenants can only consent if the vendor's app registration is multi-tenant. In the manifest, signInAudience is AzureADMultipleOrgs; in the portal the option is called "Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant)".

Then there is publisher verification. The vendor links the app registration to a verified account in the Microsoft AI Cloud Partner Program (formerly Microsoft Partner Network) and to a verified publisher domain. The consent prompt then shows the blue badge with the company name; without verification it says "Unverified".

Customers are entitled to expect this. Microsoft's recommended setting for user consent is "Allow user consent for apps from verified publishers, for selected permissions". A vendor requesting application permissions in other tenants should have cleared that bar.

Least privilege: why only Application.Read.All

A tool that monitors expiry dates of secrets and certificates has to read app registrations. Nothing more. Microsoft Graph lists Application.Read.All as the least privileged permission for listing applications. The alternatives are far broader:

Permission	Display name	Allows, per Microsoft Graph
`Application.Read.All`	Read all applications	Read all applications and service principals, without a signed-in user
`Application.ReadWrite.All`	Read and write all applications	Create, read, update and delete applications and service principals, including their credentials
`Directory.Read.All`	Read directory data	Read directory data, including users, groups and apps

Application.ReadWrite.All is wrong for monitoring: whoever can add credentials to other apps can act as those apps, which Microsoft's permissions reference warns about explicitly. Directory.Read.All additionally reads all users and groups, which secret monitoring never needs. Microsoft advises against directory permissions when a resource-specific one is enough.

Rule of thumb: anything with "ReadWrite" or "Directory" in the prompt needs an explanation from the vendor.

Reviewing and revoking consent

In the Microsoft Entra admin center under Entra ID > Enterprise apps > All applications, open the app, then Permissions, and check the Admin consent tab for every tenant-wide grant. The three dots next to a permission offer Revoke permission; Cloud Application Administrator is enough for this.

To remove the app from the tenant completely, delete the service principal via Properties > Delete. The app then sits in the recycle bin for 30 days and can be restored during that time.

Consent in the audit log

Every consent leaves traces in the Entra audit logs, service Core Directory, category ApplicationManagement. Relevant activities:

Add service principal: the app was created in the tenant,
Add app role assignment to service principal: an application permission was granted,
Add delegated permission grant: a delegated permission was granted tenant-wide,
Consent to application: the consent operation itself, with the consenting user as the actor.

On revocation the counterparts appear: Remove app role assignment from service principal, Remove delegated permission grant and Remove service principal. Graph permissions specifically show up under Enterprise apps in the Microsoft Graph application's Audit logs; the Reports Reader role is enough.

GDAP and admin consent are two different things

MSPs in the CSP program work with Granular Delegated Admin Privileges (GDAP). The partner requests an admin relationship in Partner Center with specific Entra roles and a duration of 1 to 730 days. A Global Administrator at the customer approves it in the Microsoft 365 admin center. The roles are assigned to security groups in the partner tenant. MSP technicians then act as people with those roles in the customer tenant.

Admin consent for an app is independent of that. It gives no person a role; it gives a service principal a permission. It has no expiry date and does not end with the GDAP relationship. The customer should therefore grant it deliberately and document it.

Checklist for customers before consenting

Check that the client_id in the URL matches the Application ID the vendor stated in writing.
Check that the prompt shows a verified publisher with the expected company name.
Check that the list contains only permissions that fit the purpose. For secret monitoring: Application.Read.All and nothing else.
Check that every description ends in "without a signed-in user" and that the vendor explains why the app runs without a user.
Record who granted the consent and when, and where the vendor documents revocation.
After consenting, check the audit log entry and the actor named in it.

How SecretExpiry helps

SecretExpiry requests exactly one application permission: Application.Read.All, read-only. The customer grants admin consent once per tenant; after that the service monitors client secrets and certificates across all connected tenants in one dashboard with an urgent list. Notifications go out by e-mail per event or as a weekly digest, to a Teams or Slack channel via webhook, and as a calendar subscription (ICS), with a per-tenant notification address and snooze. What an expiry causes is covered in Entra app registration secrets expire, the consent flow in the docs. The trial is free for 14 days, then from 10 € per tenant per month.