Check app permissions and admin consent: identify overprivileged applications

How can you check whether an Enterprise Application or App Registration has too many permissions? First, distinguish whether the application uses delegated permissions in the context of a user or Application Permissions without a user context. Then, review the actual business process, required API actions, granted consent, owner, sign-in logs, and technical credentials. Unnecessary permissions are revoked after a controlled test.

A permission name alone does not reveal the full risk. What matters are the scope, data type, user context, tenant scope, credential security, and whether the application can use its rights automatically and permanently.

Delegated permissions and application permissions

Delegated permissions

The application acts in the context of a logged-in user. The effective access results from the app permissions and the user's rights. A user cannot grant the app more access than they possess themselves—however, broadly delegated scopes can still allow significant data access.

Application permissions

The application acts as its own identity without a logged-in user. It authenticates, for example, with a certificate, secret, managed identity, or federated identity. Application Permissions typically require administrator consent and can affect the entire tenant.

Why app-only must be checked especially carefully

A service can access resources around the clock without a user confirming interactively. If the credential is compromised, an attacker can use the granted app rights. Therefore, Application Permissions and credentials belong in the same review process. Additionally, it is worthwhile to review monitoring secrets and certificates for Entra applications, because permissions and credentials must be evaluated together.

Permission request and actual consent

An App Registration lists requested permissions. This does not automatically make them effective in the tenant. Consent creates the tenant-specific permission state on the Service Principal.

Check both levels:

• Which permissions does the app definition request?
• Which ones have actually been approved in your own tenant?
• For which resource, such as Microsoft Graph or a custom API?
• Delegated or Application?
• By whom and when was consent granted?
• Is the permission actually needed in the code?

User consent and admin consent

If risk-based step-up consent is enabled in the tenant, users can generally no longer grant far-reaching permissions to newly registered, unverified multi-tenant apps. Such requirements belong in the admin process and should be handled there with manufacturer, data, and permission review.

Microsoft Entra allows control over when users are permitted to grant consent themselves. A restrictive configuration can limit User Consent to apps from verified publishers and selected, low-risk permissions. For blocked requests, an admin-consent workflow can be set up.

The goal is not to block every app in general. A controlled process enables production use of SaaS without individual users inadvertently granting far-reaching data access.

Correctly assess publisher verification

Publisher Verification indicates that Microsoft has verified the identity of a publisher according to the intended program. This is a trust signal, but not a complete security or privacy review.

Even with a verified publisher, you must check:

• actual permissions,
• contract and data protection status,
• data processing and hosting,
• business need,
• manufacturer security information,
• incident and deletion procedures.

An unverified app is not automatically harmful; it may be expected from an internal developer. However, it requires a particularly clear ownership and origin check.

Build an admin consent workflow

Reviewers in an Admin Consent Workflow do not automatically receive the technical rights to approve based on their role. They review and recommend; the actual approval must then be performed by a sufficiently privileged administrator. In particular cases involving Microsoft Graph Application Permissions, a Global Administrator may be required.

A complete workflow includes:

1. User submits request with business justification.
2. Reviewer checks manufacturer, app, permissions, and target audience.
3. Business owner confirms need.
4. Data protection/security are involved for relevant rights.
5. Technical testing occurs in a controlled environment or pilot group.
6. Authorized administrator grants or denies consent.
7. User and group assignments are set.
8. Review and expiration dates are documented.

Not every reviewer can approve every permission. Microsoft roles differ; especially Microsoft Graph Application Permissions may require higher administrator rights. Current role prerequisites must be checked.

Assess permissions from a business perspective

For each permission, answer the following questions:

• Which API operation does the process require?
• Is a more specific permission sufficient?
• Does the app need to access tenant-wide or only specific objects?
• Can delegated access be used instead of application permissions?
• Are there application access policies, resource-specific consent, or other restrictions for the target system?
• What data can be read, modified, or deleted?
• Are privileged directory objects or mailboxes accessed?
• How is misuse detected?

Example

An application needs to read calendar appointments from a functional mailbox. A broad Graph application permission can technically work but may access more mailboxes than necessary. Depending on the workload, it should be checked whether access to specific resources can be limited.

Inventory of existing consents

Record the following per service principal:

• App and service principal ID,
• Vendor and verified publisher,
• Owner,
• Delegated grants,
• App role assignments/application permissions,
• Target resources,
• User/group assignments,
• Sign-in activity,
• Credentials and expiration dates,
• Last business review.

Microsoft Graph and portal views can provide different partial information. For large tenants, an automated export is useful.

Risk categories

High risk

• Directory, role, or authentication management,
• tenant-wide mail, file, or chat access,
• write or delete rights on many objects,
• Application Permissions with a long-lived secret,
• App without an owner,
• unknown publisher and missing contract.

Medium risk

• broad read rights with a clear application,
• delegated rights for large user groups,
• external SaaS app with a well-documented purpose,
• rarely reviewed consent.

Lower risk

• minimal sign-in and profile data,
• narrow target audience,
• verified and contractually reviewed provider,
• no app credentials in the customer tenant,
• regular reviews.

The category must be assessed based on the tenant and the process.

Typical error patterns

User sees "need admin approval"

The requested permission is not allowed for user consent or the tenant policy blocks the app. The user should submit a consent request, not look for an administrator who spontaneously grants global consent.

Admin consent was granted, but the app still does not work

Possible causes:

• wrong tenant,
• wrong API or permission,
• The app requests a token for the wrong resource,
• User or group assignment is missing,
• Credential or redirect URI is incorrect,
• Application code uses delegated instead of app-only or vice versa,
• Consent is not present for the expected app or service principal instance.

Permission removed, application continues to function

Existing tokens can remain valid until their expiration. Additionally, another grant or a different app instance may exist. Check the token lifecycle, service principal, consent objects, and actual API calls.

App is unused, but no one dares to delete it

Use a phased process:

1. Identify the owner,
2. Check sign-ins and dependencies,
3. Block new sign-ins or assignments,
4. Observation period,
5. Revoke consent,
6. Disable credentials,
7. Delete only after that.

Secure revocation of permissions

Preparation

• Export current grants,
• Document dependencies and test cases,
• Inform the owner and business team,
• Define rollback procedures,
• Schedule a test window.

Revocation

Remove the specific permission that is not needed or revoke consent. For app-only access, you can also rotate or disable the credential.

Test

• expected functionality without the permission,
• application error log,
• token reissuance,
• access attempt to a resource that is no longer allowed,
• functions that are still required.

Rollback

Microsoft documents ways to regrant revoked permissions. Restoration can occur through renewed admin consent or targeted Graph/PowerShell operations. Therefore, the previous state must be documented.

Admin consent for your own apis

For your own APIs, developers define scopes or app roles. Check:

• understandable names and descriptions,
• minimal rights,
• who is allowed to grant consent,
• preauthorization only for known clients,
• separation of reading, writing, and administration,
• claims and server-side authorization.

Consent alone does not replace authorization checks in the API. The API must validate the token target, tenant, client, scopes, or roles.

Operations and regular reviews

A review should check at least quarterly or based on risk:

• new consents,
• new application permissions,
• apps without sign-in activity,
• apps without owners.
• unverified publishers,
• expiring or unused credentials,
• user assignments,
• manufacturer or contract changes,
• documented purpose.

Access Reviews can check user access to enterprise applications. They do not replace the application's own permission review.

Test catalog

1. Users with allowed user consent.
2. Users with blocked permissions and an admin consent request.
3. Reviewer rejects the request.
4. Reviewer approves the controlled app.
5. Delegated token contains the expected scope.
6. App-only token contains the expected app role.
7. Access outside the required resource fails.
8. Consent is revoked and the token is renewed.
9. Rollback reissues the permission.
10. Apps without an owner are detected and blocked.

If you want to distinguish between the object model and the permission state, you should also read Enterprise Applications and App Registrations. For ongoing user access reviews, Access Reviews in Microsoft Entra ID adds the consent topic.

How app consent becomes a controlled approval process

A secure consent process connects technical permission analysis with business need, ownership, and recurring review. Delegated and application permissions are evaluated separately, publisher verification is used only as a signal, and permission revocation is secured with real tests. This keeps applications usable without tenant-wide rights growing unnoticed.