Restrict user consent by disabling general user consent and allowing only the consent conditions your organisation approves. That prevents users from granting applications access to data on their own. Review consent settings, publish an app approval process, and monitor for shadow IT apps that appear when users try to bypass central controls.
What changes when you restrict user consent in Entra ID?
Restricting user consent changes who can authorise third-party apps to access organisational data. Instead of every user being able to approve permissions on the spot, you force consent through an organisation-approved path, which reduces unsanctioned app access and makes permission grants reviewable. In practice, the control is about permission governance, not just tenant settings.
This matters because consent is often how low-friction app access enters the environment. If users can approve broad delegated permissions without central review, the tenant can accumulate shadow IT, overbroad scopes, and untracked integrations that are hard to unwind later. A well-run consent model should align with how your organisation vets apps, publishers, and permission requests.
For a practical starting point, pair consent restriction with a clear approval route for legitimate business apps. NHIMG’s Entra ID Applications and Consent Guide covers the consent workflow, enterprise apps, and the review path for delegated permissions in more depth.
How do consent settings, admin approval, and app governance fit together?
Consent restriction is only effective when it is part of a broader application governance model. You need to decide which permissions users may grant directly, which permission types require admin approval, and how app registrations are reviewed after they appear. Without that surrounding process, the tenant may still accumulate risky apps, only with more manual cleanup later.
In Entra ID, the real control point is the balance between user convenience and permission authority. Many organisations allow only low-risk consent conditions and route everything else through an approval workflow. That approach gives users a path for legitimate SaaS onboarding while keeping high-impact permissions, such as directory-wide or mailbox-wide access, under central control.
Good governance also depends on knowing which apps already exist and whether they are trusted. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is useful when you need to turn consent review into an ongoing inventory and revocation process rather than a one-time policy change.
What should you watch for after tightening user consent?
Once you restrict consent, the main operational risk is bypass behaviour. Users may keep trying to install unapproved integrations, request workarounds, or forward requests to shadow admins and business units that do not own the approval process. The control only works if you can see those requests and if the approved path is faster than informal workarounds.
Another concern is that previously granted apps remain active until you review them. Tightening future consent does not automatically fix old grants, so stale OAuth permissions and dormant enterprise apps can continue to expose data. That is why consent restriction should be followed by an inventory sweep and a review of already-consented applications.
Attackers also abuse consent flows because they offer a legitimate-looking way to gain access. NHIMG’s CoPhish OAuth phishing via Copilot Studio shows how consent phishing can turn an ordinary approval action into token theft, while Storm-1283 OAuth apps abuse 2023 illustrates how malicious app grants can be weaponised after access is obtained.
Risk and Threat Considerations
Restricting user consent reduces the chance that a single user can hand an app access to sensitive data, but the residual risk shifts to approval abuse, stale grants, and consent phishing. If the organisation does not monitor what users are asking for, attackers can still target the approval path itself and use trusted-looking applications to obtain access.
Failure mechanism: Users approve an app with permissions that are broader than intended, or an attacker persuades a user to consent to a malicious or compromised app that then harvests tokens or data.
Impact: The tenant can accumulate shadow IT, overprivileged access, and persistent third-party access paths that are difficult to detect until data exposure or account abuse is already underway.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-16 — Security and Privacy Attributes | Restricting consent depends on controlling authorization attributes and permission decisions for app access. |
| IA-5 — Authenticator Management | Consent grants often create long-lived access paths that must be managed and revoked like credentials. | |
| AC-6 — Least Privilege | Consent restriction is a least-privilege control that prevents users from authorising unnecessary app access. | |
| Recommendation — Apply AC-16 to limit which permission attributes users can grant to applications. Use IA-5 to govern lifecycle and revocation of app credentials and tokens tied to consented access. Enforce AC-6 by limiting app permissions to the minimum necessary and requiring approval for higher privilege. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | User consent is an access-control decision about which apps may obtain data access. |
| Recommendation — Set and enforce access-control rules that define which app permissions users may approve. | ||
Practitioner Guidance
What to verify: Confirm which consent settings are actually enforced in the tenant, not just documented in policy. The useful check is whether users can still approve delegated permissions, whether admin consent is required for sensitive scopes, and whether the exception path is controlled and auditable.
Common mistake: Treating consent restriction as a one-time configuration task. In practice, you also need an app approval process, periodic review of existing grants, and a response path for suspicious or unnecessary consented apps.
Practitioner takeaway: The goal is not to stop every app integration, but to make permission grants deliberate, reviewable, and reversible so that convenience does not turn into unmanaged access.