Updated
The settings and what they mean
In the Entra admin center, go to Entra ID > Enterprise apps > Consent and permissions > User consent settings. The options are:
- Do not allow user consent. Every app needs an administrator's approval.
- Allow user consent for apps from verified publishers, for selected permissions. Users can only grant low-impact permissions, and only to apps from publishers Microsoft has verified.
- Let Microsoft manage your consent settings. Microsoft's managed policy, which blocks user consent to sensitive permissions such as mail, files, calendars, chats and contacts. Microsoft made it the default for new tenants in mid-2025 and moved many existing tenants onto it.
- Allow user consent for apps. Any user can grant any app the permissions it asks for, within what users are allowed to grant. This is the setting to get rid of.
Changing the setting does not remove grants that were already given. That needs a separate review.
How to fix it
- Choose 'Do not allow user consent' or 'Allow user consent for apps from verified publishers, for selected permissions'. The Microsoft-managed setting is a reasonable floor if you need users to keep connecting low-risk apps.
- Go to Consent and permissions > Admin consent settings and set 'Users can request admin consent to apps they are unable to consent to' to Yes. Choose reviewers. Users now get a request button instead of a dead end, so they stop looking for workarounds.
- Review the apps that already have access (next section) and revoke what nobody can explain.
Changing the consent setting in the portal needs the Global Administrator role. In Microsoft Graph, Privileged Role Administrator is enough.
How to review apps that already have access
- Entra ID > Enterprise apps > All applications lists every app with a presence in the tenant. Open an app and look at Permissions to see what it was granted, by admins and by users.
- Entra ID > Users > select a user > Applications shows the apps one user has signed in to and granted access.
- In the Microsoft Defender portal, an audit log search for the activity 'Consent to application' shows when consent was given, and by whom.
With Microsoft Graph PowerShell, list the delegated grants. ConsentType 'AllPrincipals' is admin consent for the whole organisation, 'Principal' is one user's consent:
Connect-MgGraph -Scopes "Directory.Read.All"
Get-MgOauth2PermissionGrant -All |
Select-Object ClientId, ConsentType, PrincipalId, Scope |
Sort-Object ConsentTypeLook for mail, file and offline_access scopes on apps you do not recognise. Remove a grant with Remove-MgOauth2PermissionGrant, and disable sign-in for the enterprise app if it should not be used at all.
Frequently asked
Is the Microsoft-managed consent setting good enough?
It is a real improvement on allowing all user consent, because it blocks the mail, file and calendar permissions attackers want. Tenants with sensitive data or many users are better off with consent limited to verified publishers and selected permissions, or with no user consent and an admin consent workflow.
Does changing the setting remove apps that already have access?
No. Existing grants stay until you remove them. Review the enterprise applications and the permission grants after changing the setting.
Why doesn't MFA stop consent phishing?
Because the user completes MFA themselves while signing in to the app. The attacker never needs the password: the app receives a token with the permissions the user accepted, and refresh tokens keep it working after a password change.