Upcoming Change to Entra App Consent Defaults: What Admins Need to Know Before July 16
Starting July 16, 2025, Microsoft is rolling out a significant update to how user consent to applications works in Entra ID. If your tenant is still on the original wide-open default consent setting, you will be automatically migrated to a more secure configuration designed to reduce the risk of excessive data exposure.
Here’s a quick rundown of what’s currently in place, what’s changing, and what you should do now to avoid surprises.
TL;DR
- Microsoft is revoking user consent to four high-impact permissions starting July 16, unless you opt out.
- All existing app consents remain, but new ones requesting
Files.*orSites.*will need admin approval. - Enable Admin Consent Workflow now to avoid disruption.
- Review your current consents to understand what’s already been granted and whether that access is still appropriate.
- Take action before July 16 to control the timing and impact of this change in your environment.
Current Consent Policy Options
Entra offers three main user consent policies. If you haven’t changed anything manually, you’re probably on the bottom one (defualt):
Allow user consent for all apps (Legacy default most common)
- Users can grant delegated permissions to any app, as long as those permissions don’t require admin consent.
- Ideal for agility, but can expose data unintentionally, especially with high-privilege delegated permissions like
Files.Read.All.
Do not allow user consent
- Users are blocked from consenting to any app. All consent requests require admin approval.
- Users will hit what’s known as the “brick wall” experience, an error saying they’re not authorized, with no built-in way to proceed unless additional workflows are enabled.
- Admins can enable the Admin Consent Workflow to capture and review these blocked requests.
Allow user consent for verified publishers and low-risk permissions (Goldilocks/recommended)
- Users can only consent to apps from verified publishers, and only for permissions you’ve explicitly marked as low risk (e.g.,
User.Read,profile,openid). - Offers a strong balance between security and flexibility.
- Users can only consent to apps from verified publishers, and only for permissions you’ve explicitly marked as low risk (e.g.,
About the Brick-Wall & Admin Consent Workflow
If you block user consent without further configuration, users get a dead-end error during sign-in to apps. They won’t know who to contact or what to do next. This leads to frustration or worse—shadow IT workarounds.
To soften the impact, Microsoft offers the Admin Consent Workflow:
- When turned on, blocked users can submit a justification for access.
- Admins get notified via email (if configured) and can review requests in the Entra portal.
- They can then grant consent for that user or the entire tenant, depending on the app and permissions.
Highly recommended if you restrict user consent at all.
I wrote a post about the Admin Consent Workflow experience way back in 2020
What’s Changing July 16?
Microsoft is pushing Secure by Default to the next level:
- New tenants created after July 16 will start with the “Microsoft-recommended” consent policy.
- Existing tenants on the legacy wide-open policy will be migrated to this Microsoft-managed recommended policy automatically.
Check if you’re impacted
If you haven’t touched your app consent settings since tenant creation, you’re likely on the default and will be migrated.
- Use the Microsoft Graph API:
GET https://graph.microsoft.com/v1.0/policies/authorizationPolicy
Look under permissionGrantPoliciesAssigned to defaultUserRolePermissions to check if it’s set to microsoft-user-default-legacy.
{
"id": "authorizationPolicy",
"allowInvitesFrom": "everyone",
"allowedToSignUpEmailBasedSubscriptions": true,
"allowedToUseSSPR": true,
"allowEmailVerifiedUsersToJoinOrganization": false,
"allowUserConsentForRiskyApps": null,
"blockMsolPowerShell": false,
"displayName": "Authorization Policy",
"description": "Used to manage authorization related settings across the company.",
"guestUserRoleId": "10dae51f-b6af-4016-8d66-8c2a99b929b3",
"defaultUserRolePermissions": {
"allowedToCreateApps": true,
"allowedToCreateSecurityGroups": true,
"allowedToCreateTenants": true,
"allowedToReadBitlockerKeysForOwnedDevice": true,
"allowedToReadOtherUsers": true,
"permissionGrantPoliciesAssigned": [
"ManagePermissionGrantsForSelf.microsoft-user-default-legacy",
"ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team",
"ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat"
]
}
}
What’s different in the “recommended” policy?
The recommended policy blocks user consent to just four high-impact permissions by requiring admin approval:
Files.Read.AllFiles.ReadWrite.AllSites.Read.AllSites.ReadWrite.All
These permissions cover OneDrive and SharePoint access at scale and are being locked behind admin consent due to their potential for massive data exposure.
All other permissions behave as they did under the legacy policy.
Note:
Microsoft emphasizes that this change is just the beginning of their Microsoft Managed, Secure by Default initiative. The recommended policy is a starting point, and Microsoft may introduce further restrictions in the future if new vulnerabilities or high-risk permissions are identified. Staying informed and regularly reviewing your consent policies will help ensure your tenant remains secure as these defaults evolve.
Will Apps Break?
No. Existing user or admin consents will remain valid.
However, new users trying to use apps that request these now-protected permissions will be blocked, unless:
- The app has already been granted tenant-wide consent, or
- The admin approves the consent request manually via workflow or policy.
Review Existing App Consents Now
Even though apps already in use won’t be blocked, some of them may already have permissions like Files.Read.All that were previously granted without admin oversight.
As a tenant admin, this is a good time to:
Review existing consents:
- Go to Audit logs in Entra > Search for “Create delegated permission grant”.
- Or run a KQL query in your Log Analytics workspace if you’re using Microsoft Sentinel.
Identify apps with elevated access:
- Pay attention to the four newly restricted permissions and evaluate whether those apps should retain that level of access.
- Consider revoking and re-consenting with tighter scope or delegation to fewer users.
Plan a governance strategy:
- For business-critical apps, consider granting admin consent tenant-wide and using app assignments or access packages to control usage.
Can I Opt Out?
Yes. Before July 16, you can:
- Switch to the “verified publisher” policy,
- Turn off user consent entirely, or
- Create a custom Permission Grant Policy that suits your security model.
If you take any of these actions, Microsoft will not auto-migrate your tenant.
However, be aware: if you just duplicate the old wide-open policy as a custom one, you’ll retain all current risks, and won’t benefit from Microsoft’s ongoing improvements.
How to Create a Custom Permission Grant Policy
If the built-in consent policies don’t fit your organization’s needs, you can define a custom app consent policy to control exactly which permissions users can consent to.
Microsoft provides step-by-step guidance on creating and assigning custom permission grant policies using PowerShell or Microsoft Graph:
With a custom policy, you can:
- Allow or block user consent for specific permissions or publishers.
- Restrict consent to only certain apps or permission types.
- Fine-tune your security posture beyond the default options.
📢 Reference Message Center Notice
This change was formally announced via Message Center post MC1097272.
You can find more details and track status updates here:
🔗 https://mc.merill.net/message/MC1097272
Thanks to Merill Fernando for maintaining this excellent public tracker of Message Center announcements.
