What this check looks at
Finds apps that individual users have allowed to read their mail, files or directory data, outside any administrator review.
Unless the tenant restricts it, Microsoft 365 lets ordinary users consent to third-party apps that ask for access to their own data. Microsoft has tightened the default for new tenants, but many older tenants still let users consent to any app that does not need administrator approval. Each consent creates a delegated permission grant for that one user (consent type Principal) that nobody in IT is told about.
This check looks at apps outside Microsoft’s own that individual users have consented to with at least one high-risk scope (mail, files, sites, the directory, chat or offline_access). The check fails when any of those apps comes from a third-party publisher Microsoft has not verified, and warns when all of them are from verified publishers or built in-house. The evidence gives the number of users who consented to each app and the scopes.
Consent phishing turns this into account takeover without a password: the victim clicks a link, sees a genuine Microsoft consent prompt for an app with a plausible name, and accepts. The app then reads their mail or OneDrive through Microsoft Graph for as long as its refresh token lasts, unaffected by a password change or MFA.
Why it matters
Each user consent is a small, invisible data-sharing agreement. One convincing prompt is all an attacker needs to read a mailbox for months, and nobody in IT is told.
At a 25-person design studio, three people consented to a free email productivity add-in from an unverified publisher that asked for Mail.ReadWrite and offline_access. The publisher later sold the app, and the new owner harvested the mailboxes, including client contracts and staff payslips: a reportable breach under UK GDPR and a difficult conversation with clients.
Revoking unwanted user consents is quick and invisible to everyone else, and limiting future consent to verified publishers and low-impact permissions removes most of the risk while the admin consent workflow keeps a route for genuine requests.
CIS Controls v8 safeguard 5.5 covers app identities. ISO 27001 A.5.15 and A.5.19, the NCSC 10 Steps on supply chain security and the NCSC CAF supply chain and identity outcomes expect access by third-party software to be authorised by the organisation, not by individual users.
How to fix it
Where: Entra admin centre → Identity → Applications → Enterprise applications → Consent and permissions
Before you start
- Group the apps by what they do; replace the useful ones with an approved tool before blocking.
- Restrict user consent (see the user consent finding) so new ones need approval.
Step by step
- Review the apps users have consented to. Open the evidence: each app is listed with the number of users who consented, the scopes and whether the publisher is verified. In the Microsoft Entra admin centre, Entra ID > Enterprise apps > All applications, open each app and select Permissions under Security, User consent tab, to see who consented to what.
- Agree with the client what to keep. Useful apps from verified publishers can stay. Anything unrecognised, unverified or unnecessary should go. Where a useful app is unverified, find an approved alternative with the client before removing it.
- Revoke the user consents for unwanted apps. In Microsoft Graph PowerShell (Connect-MgGraph -Scopes DelegatedPermissionGrant.ReadWrite.All), list the app’s user grants with Get-MgOauth2PermissionGrant -All -Filter "clientId eq '<service principal id>' and consentType eq 'Principal'" and remove each with Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId <grant id>. Removing a grant stops new tokens; run Revoke-MgUserSignInSession -UserId <upn> for the users concerned to end refresh tokens already issued.
- Block the apps you removed. On each removed app, open Properties, set Enabled for users to sign in? to No and select Save, so nobody can consent to it again.
- Restrict user consent. Go to Entra ID > Enterprise apps > Consent and permissions > User consent settings and choose Allow user consent for apps from verified publishers, for selected permissions (or Do not allow user consent). Under Permission classifications, classify only User.Read, openid, profile and email as low impact, so apps asking for mail or file access need an administrator.
- Turn on the admin consent workflow. Under Consent and permissions > Admin consent settings, set Users can request admin consent to apps they are unable to consent to to Yes, choose reviewers, turn on email notifications and Save. Tell users they will see a request approval option instead of the consent prompt.
- Confirm consent is closed off. Reopen each removed app’s Permissions page: the User consent tab should be empty and Properties should show Enabled for users to sign in: No. As an ordinary test user, try an app that asks for Mail.Read and check you are asked to request approval. The finding clears at the next assessment.
What users will notice
Users lose the apps you block, and future apps need an administrator to approve them.
How to confirm it worked
Enterprise applications, filtered on user consent: only approved apps remain enabled.
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.a Identity verification, authentication and authorisation |
| 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 |
| SOC 2 | CC6.3 Role-based access and least privilege |
| PCI DSS 4.0.1 | 7.2.5 Application and system accounts are managed with least privilege |
| 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 |
| CIS Controls v8.1 | 5.5 Establish and maintain an inventory of service accounts (IG2) |
| 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 how users consent to applications (Microsoft Learn)