What this check looks at
Finds delegated permission grants made on behalf of all users ("AllPrincipals") that include scopes able to read or move company data.
When an administrator ticks Consent on behalf of your organisation, or a vendor’s set-up asks for admin consent, Microsoft Entra ID creates a delegated permission grant with consent type AllPrincipals. It applies to every user in the tenant: whenever anyone uses that app, it receives the granted scopes without asking, and with offline_access it keeps a refresh token and can act long after the user closes it.
This check reads all delegated permission grants and picks out tenant-wide (AllPrincipals) grants that include a high-risk scope: Mail.Read, Mail.ReadWrite, Mail.Send, MailboxSettings.ReadWrite, Files.Read.All, Files.ReadWrite.All, Sites.Read.All, Sites.ReadWrite.All, Sites.FullControl.All, Directory.Read.All, Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, Notes.ReadWrite.All, Chat.ReadWrite or offline_access. The check fails when any such grant exists.
Illicit consent is a well-established attack: someone is sent a link to a genuine Microsoft consent page for an attacker’s app with a plausible name. Once consented, the app reads mail and files through Microsoft Graph with tokens Microsoft issues. A password reset does not remove the grant, MFA plays no part after the first consent, and a tenant-wide grant means every user who opens the app hands it their data without being asked.
Why it matters
An admin-consented, tenant-wide grant applies to every user at once. If the application is attacker-controlled or later compromised, it reads the whole organisation's mail and files without a single sign-in.
A Global Administrator at a 70-person firm is phished with a link to a real Microsoft consent page for an app named like a PDF viewer, and ticks Consent on behalf of your organisation. The app now gets Mail.Read and Files.Read.All for every user who opens it, and the attacker spreads the same link internally. Mail and SharePoint content leave the business without one failed sign-in, and the incident becomes a personal data breach report to the ICO and a long review of what was read.
Reviewing tenant-wide grants is quick, and revoking one that is not needed costs nothing. For legitimate apps, narrowing the scopes to what the app uses keeps the business process and removes the blanket access.
CIS Controls v8 safeguard 5.5 asks for app identities to be inventoried. ISO 27001 A.5.15 (access control) and A.5.19 (information security in supplier relationships), the NCSC 10 Steps on supply chain security and the NCSC CAF supply chain outcome expect third-party access to company data to be known and justified.
How to fix it
Where: Entra admin centre → Identity → Applications → Enterprise applications → Permissions
Before you start
- List what each granted app does and who asked for it. Revoking a tenant-wide grant affects every user of that app.
Step by step
- Identify each app. The evidence lists each grant by the app’s service principal object ID with its high-risk scopes. In the Microsoft Entra admin centre go to Entra ID > Enterprise apps > All applications, clear the application type filter and search for each ID or name. Note the publisher, whether it is verified, and when the app was added.
- Review the granted permissions. On each app, select Permissions under Security. The Admin consent tab lists the delegated permissions granted for all users. Find who consented and when in Entra ID > Monitoring & health > Audit logs, activity Consent to application.
- Decide with the owner: keep, narrow or revoke. Agree with the client who uses each app and why, and mark it keep, narrow (keep the app but drop some scopes) or revoke. An app nobody recognises, from an unverified publisher, with mail or file scopes, should be revoked and blocked at once.
- Revoke or narrow the grant. In Microsoft Graph PowerShell (Connect-MgGraph -Scopes DelegatedPermissionGrant.ReadWrite.All), find the grant with Get-MgOauth2PermissionGrant -Filter "clientId eq '<service principal id>' and consentType eq 'AllPrincipals'". Revoke it with Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId <grant id>, or narrow it with Update-MgOauth2PermissionGrant -OAuth2PermissionGrantId <grant id> -Scope "openid profile User.Read" listing only the scopes the app needs. Revoke permission on the app’s Permissions page does the same one scope at a time.
- Block revoked apps and check what they read. For an app revoked because nobody recognises it, open Enterprise apps > the app > Properties, set Enabled for users to sign in? to No and Save, so nobody can consent to it again. If it may have been malicious, search the Microsoft Purview audit log (Audit, in the Microsoft Purview portal) for its app ID, including MailItemsAccessed and file access events, to establish what it read.
- 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 reviewers and Save, so future tenant-wide requests are reviewed rather than granted in the moment.
- Confirm no unagreed high-risk grant remains. Run Get-MgOauth2PermissionGrant -All -Filter "consentType eq 'AllPrincipals'" and check that no remaining grant includes a high-risk scope you have not agreed with an owner, or reopen each app’s Permissions page. The finding clears at the next assessment.
What users will notice
Users of a revoked app are asked to consent again, or blocked if consent is restricted.
How to confirm it worked
Enterprise applications, the app, Permissions: the high-risk delegated scopes are no longer granted for all users.
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 chain |
| 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 | PA-7 Follow just enough administration (least privilege) |
| 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
- Detect and remediate illicit consent grants (Microsoft Learn)