What this check looks at
Checks that people can ask an administrator to approve an app they are not allowed to approve themselves, and that someone reviews the requests.
When user consent is restricted, someone who tries to add an app needing more permission than they may grant is told they need an administrator, and that is the end of it. The admin consent workflow replaces that dead end with a request: it goes to named reviewers, who approve or deny it under Entra ID > Enterprise apps > Admin consent requests, with email notifications and an expiry date. It is off by default.
This check reads the admin consent workflow setting. It passes when the workflow is on with at least one reviewer, and warns when it is on but nobody is set to review, so requests go unanswered. When the workflow is off, the check fails if user consent is already restricted, so people have no way to ask; it warns if users can still consent to apps themselves, or if the user consent setting could not be read.
Without a request route, restricted consent produces workarounds: people email IT, someone grants consent for the whole organisation in a hurry, or staff sign up for the same tool with personal accounts. Either the restriction is loosened again, or company data ends up in services nobody manages.
Why it matters
Restricting who may consent to apps stops illicit-consent attacks, but without a way to ask, people work around it with personal accounts and shadow IT. The workflow keeps the restriction and gives every request an owner and an audit trail.
After restricting user consent, a 100-person firm’s MSP receives a dozen emails a week asking for apps. One technician, under time pressure, grants consent for the whole organisation to a calendar scheduling app with Mail.ReadWrite that one person wanted. Through the workflow the request would have arrived with the permissions listed and a named requester, giving the reviewer the information to say no.
Turning the workflow on is a single settings page, and it makes restricted consent workable: the restriction stays, people have a proper way to ask, and every decision is recorded.
CIS Microsoft 365 Foundations Benchmark 5.1.5.2 asks for the admin consent workflow to be enabled, and CISA SCuBA MS.AAD.5.3 asks for it to be configured. CIS Controls v8 safeguard 4.1, ISO 27001 A.5.15 and A.5.19, the NCSC 10 Steps and CAF supply chain outcomes and NIST CSF PR.AA-05 expect app access to be authorised through a defined process.
How to fix it
Where: Entra admin centre → Enterprise applications → Admin consent settings
Before you start
- Decide who reviews requests; the change uses Global, Application and Cloud Application Administrators, which you can narrow afterwards.
Step by step
- Choose the reviewers. Decide who reviews requests: usually two or three people from the MSP or the client’s IT lead. Reviewers need a role that can grant consent, such as Global Administrator, Privileged Role Administrator, or Application or Cloud Application Administrator for most apps.
- Open the admin consent settings. In the Microsoft Entra admin centre, go to Entra ID > Enterprise apps > Consent and permissions > Admin consent settings.
- Turn the workflow on. Set Users can request admin consent to apps they are unable to consent to to Yes. Under the reviewers section, add the chosen users, groups or roles. Turn on email notifications for requests and expiry reminders, set requests to expire after 30 days, and Save.
- Check user consent is restricted. Under Consent and permissions > User consent settings, check the setting is Allow user consent for apps from verified publishers, for selected permissions, or Do not allow user consent. With the workflow on, restricting it no longer leaves people stuck.
- Agree how requests are handled. Tell staff that a blocked app now offers a request for approval, and agree with the reviewers how quickly to answer and what to check: the publisher, the permissions asked for and the business need.
- Confirm requests reach the reviewers. As an ordinary test user, try to add an app that needs admin consent (for example one requesting Mail.Read): a request option should appear, and the request should arrive under Entra ID > Enterprise apps > Admin consent requests and by email to the reviewers. The finding clears at the next assessment.
What users will notice
People blocked from consenting to an app see a "request approval" button instead of a dead end.
How to confirm it worked
Entra ID, Enterprise applications, Admin consent requests shows the workflow on; a test request from an ordinary account arrives with the reviewers.
Frameworks and controls
This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | A4.a Supply chainB2.d Identity and access management (IdAM) |
| DSPT | Standard 10: Accountable suppliers |
| NIS2 | Art. 21(2)(d) Supply chain security |
| Microsoft Cloud Security Benchmark | IM-3 Manage application identities securely and automatically |
| Zero Trust | Applications |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| NIST SP 800-171 | 3.1.1 Limit system access to authorised users, processes and devices |
| CMMC Level 2 | AC.L2-3.1.1 Authorized Access Control |
| ISO 27001:2022 | A.5.15 Access controlA.5.19 Information security in supplier relationships |
| CISA SCuBA | MS.AAD.5.3v1 Admin consent workflow configured |
| CIS M365 | 5.1.5.2 Ensure the admin consent workflow is enabled |
| CIS Controls v8.1 | 4.1 Establish and maintain a secure configuration process (IG1) |
| NIST CSF 2.0 | PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties |
| NCSC 10 Steps | Identity and access managementSupply chain security |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Configure the admin consent workflow (Microsoft Learn)