Join our Newsletter — 33% off our NHI Course

How do you manage and evaluate application consent requests in Microsoft Entra ID?

Manage consent requests by reviewing the permissions requested, the requesting application, and the business need before approval. Evaluate whether the app needs delegated or application permissions, whether the request is excessive, and whether the publisher and tenant risk are acceptable. Keep a record of approved requests and regularly recheck granted consent for unnecessary access.

Application consent review is partly permissions hygiene and partly trust assessment. The point is not just to see whether the request looks normal, but whether the app’s requested access is proportional to its business purpose, whether the permission type matches the use case, and whether the requester is introducing tenant-wide exposure through delegated or application permissions.

A good review starts with the consent surface itself: what resource is being requested, what the app can do after approval, and whether the permission set is broader than the stated workflow needs. Requests that ask for Graph access, mail or file access, or tenant-level permissions deserve closer scrutiny because the blast radius is usually larger than the user experience suggests.

Publisher trust matters too, but it should not replace technical review. A verified publisher, a known vendor, or an internal app can still request excessive access, and a low-friction approval path can still become a persistence mechanism if the app is later repurposed or abused.

How to judge delegated versus application permissions

Delegated permissions should normally be tied to a real user session and a clearly bounded workflow. Application permissions deserve a higher bar because they can operate without a signed-in user and often imply broader, longer-lived access. When the business need can be met with delegated permissions, that is usually the safer choice.

The practical question is whether the app needs to act only when a user is present, or whether it genuinely needs unattended access. If the answer is unclear, treat that ambiguity as a review finding, not a reason to approve by default. An app that only needs a single mailbox, site, or data set should not be reviewed as if it needs full tenant reach.

Document the approval rationale in a way that makes later recertification possible. A consent request that cannot be explained in business terms, mapped back to an owner, and reconciled against its permission scope is hard to defend later and even harder to revoke cleanly.

Approved consent is not a one-time event. Granted access should be periodically rechecked for scope creep, dormant apps, abandoned owners, and permissions that were justified once but no longer match the current use case. This is especially important when an app has broad Graph permissions or can access sensitive content across the tenant.

Keep the record of who approved the request, what business need was accepted, and what permissions were granted so the original decision can be challenged later if risk changes. That record becomes the basis for access review, incident triage, and offboarding when the application is no longer needed.

For practical governance, connect consent review to ownership and lifecycle management. If no accountable owner can explain why the app still needs the granted access, the default posture should shift toward review, reduction, or revocation rather than quiet retention.

Risk and Threat Considerations

Consent requests are a common trust boundary because they can turn a single approval into broad access, token theft opportunities, or tenant persistence. Malicious or compromised apps may use consent to reach mail, files, directories, or Graph data without needing to defeat password-based controls again.

Failure mechanism: Overly broad or poorly understood consent grants create durable access paths that survive user sign-in events and can be abused later if the app, publisher, or tenant context is compromised.

Impact: The result can be unauthorized data access, lateral movement through Graph-connected services, difficult-to-detect persistence, and a larger blast radius than the original approval appeared to justify.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AC-2 — Account Management Consent approval and periodic recheck are account and access lifecycle decisions.
AC-6 — Least Privilege Consent requests should be limited to the minimum permissions needed for the stated use case.
IA-5 — Authenticator Management App consent often exposes tokens, secrets, or other credentials that need lifecycle control.
Recommendation — Review approved app access periodically and revoke consent that no longer has a business need. Approve only the narrowest permission set that satisfies the application workflow. Protect and rotate exposed credentials or tokens when consented access increases compromise risk.
CIS Controls v8 CIS-6 — Access Control Management Consent review is fundamentally about granting, reviewing, and removing access rights.
Recommendation — Maintain a review process that removes app access when the business need no longer exists.
ISO/IEC 27001:2022 A.5.15 — Access control Consent approval and review are access control decisions tied to authorization and governance.
Recommendation — Use access control policy to approve consent only when the requested scope is justified.
OWASP ASVS V8 — Authorization Consent requests should be evaluated for excessive authority and scope before approval.
Recommendation — Verify that the app receives only the permissions required for its authorized function.
OWASP API Security Top 10 API5 — Broken Function Level Authorization Overbroad app consent can grant functions the app should not be able to perform.
Recommendation — Check that granted app permissions do not expose privileged functions beyond the intended workflow.

Practitioner Guidance

What to verify: Confirm the exact resource scopes, the app owner, and whether the requested permission type matches the actual workflow. If the request is for application permissions, require a stronger justification than you would for delegated access.

Decision rule: If the business case can be met with a narrower permission set or a user-bound flow, do not approve the broader request just because it is operationally convenient.

What good looks like: Every approved request has a named owner, a recorded justification, a documented permission scope, and a scheduled review point for revalidation or removal.

Common mistake: Treating a familiar publisher or a smooth admin consent workflow as evidence that the request is safe. Familiarity is not proportionality.

Practitioner takeaway: The best consent decision is the smallest access grant that still supports the business need, with enough documentation to challenge it later if the app’s purpose or trust level changes.