Join our Newsletter — 33% off our NHI Course

How do you configure app consent policies in Microsoft Entra ID?

Configure app consent policies by limiting who can grant consent, defining when user consent is allowed, and requiring admin approval for sensitive permissions. Start from the organisation’s risk tolerance, then allow only the permission classes that users can safely approve themselves. Review policy exceptions and consent events regularly so over-privileged applications do not enter unnoticed.

App consent policies decide which permissions users may grant to applications, which permissions require admin approval, and which consent flows are allowed at all. They sit between convenience and control: too loose, and users can authorise risky access without review; too strict, and legitimate apps become hard to adopt. A good policy matches the permissions you are willing to trust to ordinary users.

For most organisations, the real design question is not whether consent exists, but which consent decisions can be made safely without a privileged approver. That is why policy design should start from permission sensitivity, tenant risk tolerance, and the business apps users actually need, rather than from a blanket allow or deny approach.

One useful way to think about the policy is as a boundary around delegated trust. If users can approve an app, that app may gain access to mail, files, profiles, or directory data depending on the scope requested. The policy therefore needs to distinguish low-risk delegated permissions from scopes that materially increase exposure or enable persistence, data extraction, or tenant-wide access.

A practical policy usually begins by reducing the default surface area of user consent and then explicitly allowing only the permission classes that are acceptable for self-service approval. That often means requiring admin approval for sensitive or high-impact permissions, while permitting limited user consent for low-risk apps that support common productivity use cases.

Where an organisation uses third-party or custom apps, the policy should also reflect app provenance and the operational controls around it. For example, apps that are unverified, multi-tenant, or requesting broad Microsoft Graph access deserve more scrutiny than first-party tools or narrowly scoped internal apps. Entra ID Applications and Consent Guide covers the consent and admin-consent patterns that matter when you are separating routine approval from higher-risk access.

Consent policy design is also stronger when paired with administrative controls that limit who can make exceptions and how those exceptions are reviewed later. If an approver can override the policy, the organisation should treat that path as a governed exception, not as a permanent bypass. Regular review of consent events and granted apps helps prevent quiet privilege accumulation. The companion Microsoft 365 Security Guide is useful here because it ties app consent to broader tenant hardening, audit visibility, and governance.

The main failure mode is not just unwanted apps, but unwanted access that looks legitimate at the moment it is granted. A user can approve an app that later becomes a data-exfiltration path, a persistence mechanism, or a way to expand access beyond the original business purpose. That is why consent policy is as much about preventing future misuse as it is about stopping initial mistakes.

Permissions requested through consent are especially sensitive when they enable access to mailboxes, files, directory information, or offline access that survives the user session. Those permissions can create durable exposure if the app is malicious, compromised, or simply over-scoped. Historical abuse patterns show why consent governance matters in practice, not just on paper: adversaries and criminals routinely target OAuth apps, application credentials, and delegated permissions because they can provide lasting footholds inside a tenant. Storm-1283 OAuth apps abuse 2023 is a clear example of how app secrets in Entra ID can be abused after consent or app registration is already in place.

Permission review also matters because consent abuse is often quiet. The app may appear legitimate, but the granted scopes are broader than expected, the publisher is untrusted, or the app is used only once and then forgotten. That is where approval workflows, consent audits, and exception reviews become essential controls rather than administrative overhead.

Risk and Threat Considerations

Overly broad consent policies can turn ordinary user clicks into durable tenant exposure. The security issue is not only malicious apps, but legitimate-looking apps that request more access than the business need justifies, then retain that access after the initial use case has ended.

Failure mechanism: A user approves an app with sensitive delegated or application permissions, or an exception path bypasses normal review, allowing the app to read data, persist access, or expand privilege without central oversight.

Impact: The tenant can lose confidentiality, integrity, and control over app-driven access paths, with consequences ranging from data exposure to persistence, privilege abuse, and difficult-to-detect tenant compromise.

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 and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 AC-2 — Account Management Consent policy governs who may obtain app access paths.
IA-5 — Authenticator Management App consent often leads to long-lived tokens, keys, or secrets.
AC-6 — Least Privilege Consent should limit apps to the smallest permission set users can safely approve.
Recommendation — Restrict consent rights and review granted app access regularly. Rotate or revoke exposed app secrets and tokens promptly. Approve only the minimum scopes needed for the app's function.
OWASP API Security Top 10 API3 — Broken Object Property Level Authorization Overbroad consent can expose more data fields and Graph access than intended.
Recommendation — Validate app permissions against the exact data and actions required.
CIS Controls v8 CIS-6 — Access Control Management Consent approval is an access-control decision that needs governance and review.
Recommendation — Centralize approval rules and recertify granted app access paths.

Practitioner Guidance

What to verify: Confirm which permission classes users can actually grant, which ones still require admin approval, and whether the policy matches the app types in active use. If the policy is permissive in principle but restrictive in practice through exceptions, the exception process becomes the real control and should be reviewed as such.

Common mistake: Teams often tune consent policy once and then rely on it as if it were static. In reality, new apps, new integrations, and changing business needs can make yesterday’s safe permission set too broad today.

What good looks like: Low-risk apps are self-service, sensitive permissions route to approval, and every exception leaves an audit trail that can be reviewed alongside the consented app inventory. The policy should reduce surprise, not merely document it.

Practitioner takeaway: The best consent policy is one that makes low-risk approval easy, high-risk approval deliberate, and post-consent review routine enough that over-privileged apps do not accumulate unnoticed.