What this check looks at
Checks whether ordinary users may grant applications access to company data without review.
When someone signs in to a third-party app with their Microsoft 365 account, the app can ask for permissions to their data: to read their mail, files or contacts, and to keep that access while they are offline. Whether an ordinary user may agree to that is set by the user consent settings. Many tenants still let users consent to any app for any permission, which was Microsoft’s default for years.
The check reads which consent policies apply to the default user role. It passes when users cannot consent at all, so every grant goes through an administrator. It fails when users may consent to any app for any permission. It warns, at low severity, when consent is limited to apps from verified publishers asking for low-impact permissions, Microsoft’s middle ground, because the CIS benchmark asks for no user consent at all. A custom consent policy also warns, so someone confirms what it allows.
This is how an illicit consent grant works: the attacker registers an app with a plausible name such as "Document Viewer", sends a link, and the user approves a consent screen that looks like any other Microsoft sign-in. The app now holds a token to read the mailbox and OneDrive. No password was stolen and MFA was done properly, so resetting the password or enforcing MFA removes nothing; only revoking the grant does.
Why it matters
Unrestricted user consent is the mechanism behind illicit-consent-grant attacks: a convincing sign-in prompt persuades a user to hand an attacker-controlled app permanent read access to their mailbox and files. No password is stolen, so no password reset helps.
For a small professional-services firm, a consent grant to a malicious app can quietly copy every client email and document for months. That is a personal data breach under UK GDPR, and until it is spotted the firm cannot tell the ICO or its clients what was taken. Often the first sign is a client receiving a fraudulent invoice that quotes a real email thread.
Consent grants also outlive the person who gave them: an app a leaver approved keeps whatever access was granted until someone revokes it. Reviewing each request costs an administrator a few minutes, set against an incident that is slow to find and expensive to scope.
The CIS Microsoft 365 Foundations Benchmark (5.1.5.1) asks for user consent to apps to be turned off, and the CISA SCuBA baseline (MS.AAD.5.2v1) asks that only administrators can consent to applications. Cyber Essentials expects insecure defaults in cloud services to be turned off, and Microsoft’s own guidance is at least to restrict consent to verified publishers and low-impact permissions.
How to fix it
Where: Entra admin centre → Identity → Applications → Enterprise applications → Consent and permissions
Before you start
- Review the apps users have already consented to (see the app consent findings) so you know what they rely on.
- Turn on the admin consent workflow and name who reviews requests, so users have a way to ask.
Step by step
- Review the grants that already exist. In the Microsoft Entra admin centre, go to Entra ID > Enterprise apps > All applications and set Application type to All applications. For each third-party app, open Permissions and look at the User consent tab: who granted what. Remove anything unknown, unused or holding wide permissions such as Mail.Read, Mail.ReadWrite or Files.Read.All (delete the enterprise app, or remove the grant with Remove-MgOauth2PermissionGrant), and tell the people who used it.
- Turn on the admin consent workflow. Go to Entra ID > Enterprise apps > Consent and permissions > Admin consent settings. Set Users can request admin consent to apps they are unable to consent to to Yes, choose the reviewers (a small group of administrators, or the MSP’s service desk group), turn on email notifications and reminders, set requests to expire after 30 days, and select Save. This gives people a way to ask before consent is taken away.
- Turn off user consent. Go to Entra ID > Enterprise apps > Consent and permissions > User consent settings. Under User consent for applications, select Do not allow user consent and select Save. If the client will not accept that, choose Allow user consent for apps from verified publishers, for selected permissions, and classify only low-impact permissions (openid, profile, email, offline_access, User.Read) under Permission classifications; that reduces the risk, but this check will still warn.
- Turn off group owner consent as well. On the same page, if group owner consent is offered, set it to Do not allow group owner consent, so a team owner cannot grant an app access to everything in their team.
- Tell staff what will change. Let staff know that an app asking for access to their data will now show an approval request instead of a consent screen, that requests go to IT, and how quickly IT will answer them.
- Test the request route. Sign in as an ordinary test user to an app that needs consent, for example Graph Explorer asking for a permission it has not been granted. The user should see a screen saying admin approval is needed, with a request form. Approve or deny the request in Entra ID > Enterprise apps > Admin consent requests.
- Confirm. User consent settings shows Do not allow user consent, and Admin consent settings shows the workflow on with reviewers. Re-run the assessment: it passes when no self-consent policy is assigned to users.
What users will notice
Users can no longer grant third-party apps access to their data themselves, except low-risk permissions for verified publishers if you allow that. They request approval instead.
How to confirm it worked
Entra ID, Enterprise applications, Consent and permissions, User consent settings shows the restricted option, and the admin consent workflow is on.
Frameworks and controls
This check maps to controls in 18 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| Cyber Essentials | Secure configuration |
| Cyber Essentials Plus | Secure configuration |
| NCSC CAF | A4.a Supply chainB2.d Identity and access management (IdAM) |
| DSPT | Standard 10: Accountable suppliers |
| DORA | Art. 28 Management of ICT third-party risk |
| NIS2 | Art. 21(2)(d) Supply chain security |
| Microsoft Cloud Security Benchmark | IM-3 Manage application identities securely and automatically |
| Zero Trust | Applications |
| Secure Score | Do not allow users to grant consent to unreliable 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.2v1 User consent to applications restricted |
| CIS M365 | 5.1.5.1 Ensure user consent to apps accessing company data on their behalf is not allowed |
| 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 user consent settings (Microsoft Learn)