What this check looks at
Rates every app holding a permission in the tenant, and flags those that can make themselves an administrator, or that reach mail, files or the directory from a publisher Microsoft has not verified.
Every app with a permission in the tenant, whether added by an administrator, consented to by a user or installed from a vendor, has an enterprise application (service principal) in Microsoft Entra ID. Microsoft 365 does not rate them: nothing in the admin centres flags an unverified publisher with mailbox access, or an app that can grant itself admin roles.
This check rates every app outside Microsoft’s own that holds a permission and can sign in. An app is high risk when it holds an application permission that lets it make itself a Global Administrator (RoleManagement.ReadWrite.Directory, AppRoleAssignment.ReadWrite.All, Application.ReadWrite.All or PrivilegedAccess.ReadWrite.AzureAD), or when its publisher is not verified by Microsoft and it can reach mail, files or the directory. Organisation-wide data access, user consents to risky scopes and long disuse make it medium. The check fails when any app is high risk, and warns when the worst is medium.
Consented apps keep their access after a password reset, after MFA is enforced and after the person who consented leaves, because the app holds its own grant and refresh tokens. Attackers rely on this: an illicit consent grant through a real Microsoft consent screen is persistence that survives the usual clean-up after an account compromise, and an app that can assign itself roles is in effect a hidden Global Administrator.
Why it matters
A consented app keeps its access after passwords are reset and MFA is enforced, because it never signs in as the user. Attackers use convincing consent prompts ("illicit consent grants") precisely because the access survives every usual clean-up.
After a phishing incident at a 30-person recruitment firm, the MSP reset the victim’s password, revoked sessions and enforced MFA. Three weeks later the same mailbox was being read again: during the original compromise the attacker had consented to an unverified app called “Mail Sync” with Mail.Read and offline_access, which nobody looked at. Blocking it on day one would have ended the incident.
Reviewing the high-risk list with the client usually takes one conversation, and blocking an unrecognised app is reversible: its permissions are kept, so unblocking restores it exactly if someone turns out to need it.
CIS Controls v8 safeguards 2.1 (software inventory) and 5.5 (service accounts) cover knowing which apps exist and what they can do. ISO 27001 A.5.19, A.5.15 and A.8.2, and the NCSC 10 Steps and CAF supply chain outcomes expect third-party access to be reviewed and justified.
How to fix it
Where: Entra admin centre → Identity → Applications → Enterprise applications
Before you start
- Ask the users who consented what they use the app for; some will be legitimate and need a sanctioned alternative.
Step by step
- Review the flagged apps. Open the evidence: each app is listed with its publisher, whether the publisher is verified, its risk and the reasons. In the Microsoft Entra admin centre, Entra ID > Enterprise apps > All applications, open each high-risk app and look at Properties (publisher, date created) and Permissions under Security.
- Ask the client who uses each app. Go through the list with the client contact and record who uses each app and for what. The app’s Users and groups page and Entra ID > Monitoring & health > Sign-in logs, filtered on the application, show who has used it recently.
- Block anything nobody recognises. Open Enterprise apps > the app > Properties, set Enabled for users to sign in? to No and select Save. Do this straight away for any unrecognised app with mail, file or directory access, or with permissions that can grant admin roles. In Microsoft Graph PowerShell: Update-MgServicePrincipal -ServicePrincipalId <object id> -AccountEnabled:$false. The permissions are kept, so the change is reversible.
- Investigate apps that look malicious. If a blocked app may have been used in an attack, search the Microsoft Purview audit log (Audit, in the Microsoft Purview portal) for its app ID over the period available, including MailItemsAccessed and file access events, to establish what it read. Decide with the client whether this is a personal data breach to report to the ICO within 72 hours.
- Reduce the permissions of apps that stay. For apps the client keeps, open Permissions and revoke any scope or application permission the vendor does not document as required. Ask the vendor about a verified-publisher version and narrower permissions such as Sites.Selected or mailbox-scoped access.
- Restrict user consent. Go to Entra ID > Enterprise apps > Consent and permissions > User consent settings and select Allow user consent for apps from verified publishers, for selected permissions. Under Permission classifications, classify only User.Read, openid, profile and email as low impact. Turn on the admin consent workflow under Admin consent settings so people can still ask for apps.
- Confirm the high-risk apps are dealt with. Reopen each blocked app’s Properties and check Enabled for users to sign in shows No, and each app that stays shows only the permissions agreed with its owner. The finding clears at the next assessment.
What users will notice
Blocked apps stop working for everyone. Their permissions are kept, so unblocking restores them exactly.
How to confirm it worked
Enterprise applications, the app, Properties: "Enabled for users to sign in" is No for every blocked app.
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.c Privileged user management |
| 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)IM-3 Manage application identities securely and automatically |
| Zero Trust | Applications |
| SOC 2 | CC6.3 Role-based access and least privilegeCC9.2 Assessing and managing risks from vendors and business partners |
| 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.19 Information security in supplier relationshipsA.5.15 Access controlA.8.2 Privileged access rights |
| CIS Controls v8.1 | 2.1 Establish and maintain a software inventory (IG1)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 dutiesID.AM-02: Inventories of software, services, and systems managed by the organization are maintained |
| 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)
- Publisher verification (Microsoft Learn)