Microsoft recommends allowing user consent only for apps from verified publishers, and only for permissions you classify as low impact. The alternatives are turning user consent off entirely or allowing all users to consent to anything that does not need an admin. Changing the setting affects future consents only.
What the default allows
By default, all users can consent to applications for permissions that do not require administrator consent. A user can let an app read their own mailbox, for example, but cannot let an app read and write every file in the organization.
That default is the opening consent phishing relies on. A convincing app name and a normal looking consent screen are enough when the permission falls inside what users may grant.
The three choices
- Do not allow user consent. Every request goes to an admin.
- Allow user consent for apps from verified publishers, for selected permissions. Limited consent for apps from verified publishers and apps registered in your own tenant, and only for permissions you classified as low impact.
- Allow user consent for apps. All users may consent to any permission that does not need admin consent, for any application.
The built in policy names for the second and third are microsoft-user-default-low and microsoft-user-default-legacy.
How to choose
If you have no one to review requests quickly, option 2 is usually the practical choice. It keeps normal productivity apps working while blocking the unknown publisher case. Remember the second half: you have to classify which permissions are low impact, or the policy has little to allow.
If you can staff a review queue, option 1 plus the admin consent workflow gives the tightest control. Users who cannot consent send a request to designated reviewers.
Option 3 is the one to move away from.
Two things people miss
Apps that require user assignment must be consented by an admin even if your policy would let the user consent for themselves.
Updating the setting does not clean up the past. Existing consent grants remain, and users keep access based on what they already granted. You need a separate review of granted permissions, and revoking a grant does not stop a user re-consenting unless consent itself is restricted.
When you script the change through Graph, read the current authorization policy first. Overwriting the assigned policy list can remove permissions that let developers manage consent for apps they own.
A rollout order
- Pull the current list of enterprise apps and their permissions.
- Classify low impact permissions.
- Move to option 2 or option 1.
- Turn on the admin consent workflow so users have somewhere to go.
- Review existing grants and revoke what you cannot justify.
The Safeguard asset discovery view is one way to keep an inventory of SaaS apps connected to your organization alongside the rest of your assets.
Quick check
Does switching to a stricter consent setting remove apps users already approved?
No. Only future consent operations are affected. Review and revoke existing grants separately.
What is the setting Microsoft recommends?
Allow user consent only for apps from verified publishers, with selected low impact permissions.
Sources
Last reviewed: 19 October 2026.
