Table of Contents
New Microsoft-Managed App Consent Policy to Control User Consent for Apps
Message center notification MC1097272 (17 June 2025) announces Microsoft’s intention to restrict access to some legacy protocols and introduce a new managed app consent policy to the ability of users to grant consent to third-party apps that want access to files and sites.
Microsoft says that they are updating default settings to help Microsoft 365 tenants “meet the minimum security benchmark and harden your tenant’s security posture.” As far as I can tell, this appears to be a reference to section IM-2 of the Microsoft cloud security benchmark. For good measure, Microsoft throws in the Secure Future Initiative and Secure by Default principle to provide further justification for the change.
No Problem with Blocking Obsolete and Insecure Protocols
I don’t think anyone will complain about blocking browser access to SharePoint and OneDrive via the Relying Party Suite (RPS – another relatively unknown component for most Microsoft 365 tenants). Legacy protocols are blocked in the SharePoint tenant configuration, and this change reinforces the block.
Get-SPOTenant | Select-Object LegacyBrowserAuthProtocolsEnabled LegacyBrowserAuthProtocolsEnabled --------------------------------- True
Likewise, I don’t think anyone will complain about blocking the FrontPage Remote Procedure Call (FPRPC) protocol for Office file opens. It’s an outdated protocol that attackers have leveraged (here’s an example).
App Consent Policy to Prevent Third-Party Access to Files and Sites
My interest was drawn to the third block, which will introduce a Microsoft-managed app consent policy to require administrator consent for third-party apps that access files and sites. There are a bunch of app consent policies already present in tenants that you can see by running the Get-MgPolicyPermissionGrantPolicy cmdlet from the Microsoft Graph PowerShell SDK (any policy prefixed by “microsoft” is a Microsoft-managed app consent policy):
Get-MgPolicyPermissionGrantPolicy | Format-Table Id, DisplayName, Description -AutoSize
Like many other Microsoft 365 policies, the policy is a container, and the real settings (“condition sets”) are found by running the Get-MgPolicyPermissionGrantPolicyInclude cmdlet. For example, this app consent policy allows administrators to manage all aspects of all apps in a tenant:
Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "microsoft-application-admin" | Format-List ClientApplicationIds : {all} ClientApplicationPublisherIds : {all} ClientApplicationTenantIds : {all} ClientApplicationsFromVerifiedPublisherOnly : False Id : 811d2da7-443c-43da-96e7-28d285b234e9 PermissionClassification : all PermissionType : application Permissions : {all} ResourceApplication : any AdditionalProperties : {} ClientApplicationIds : {all} ClientApplicationPublisherIds : {all} ClientApplicationTenantIds : {all} ClientApplicationsFromVerifiedPublisherOnly : False Id : 60461179-740e-4d8b-9e00-1456a338c44b PermissionClassification : all PermissionType : delegated Permissions : {all} ResourceApplication : any AdditionalProperties : {}
For more details, see the Graph documentation for permission grant policies. There’s no UX in the Entra admin center to manage app consent policies. This article throws more light onto how to build your own app consent policies.
The Change Doesn’t Affect All Tenants
The change only affects tenants that use the default user consent settings. In my case, I changed the settings (Figure 1) to allow users to consent to a set of low-impact permissions such as User.Read. The Sites.Read.All or Files.Read permissions are definitely not in the low-impact category, which is why Microsoft is blocking them.

If you allow users to consent to permissions, you should monitor the consents to make sure that apps are not asking for unexplainable permissions. You can check permission consents through audit records. You’ll also need to make sure that the admin consent request workflow is operational.
See this article for a script to use the Microsoft Graph PowerShell SDK to generate a report of all delegated permission grants that exist in a tenant. The script reports permissions that apply to all users (consent type of “AllPrincipals”) and specific users (“Principal”). It ignores common permissions such as those required to read the user’s own profile and focuses on permissions that might disclose information if used badly. If you’re concerned about the permissions users have already granted to their data, filter on the grants of the Principal consent type and review those.
The ChatGPT Conundrum
What’s interesting about Microsoft’s move is that it neatly blocks the ability of users to grant consent for the permissions needed by the ChatGPT app to upload files from SharePoint Online and OneDrive for Business for processing by one of the ChatGPT models. A cynic might say that Microsoft is taking this step to make sure that Microsoft 365 Copilot has sole access to files stored in SharePoint Online and OneDrive for Business. A more benign reading is that Microsoft is simply making sure that users can’t inadvertently grant access to third-party apps to access and read their Microsoft 365 files.
In any case, I don’t think people should upload files to ChatGPT because this activity creates all sorts of security concerns. Fortunately, it’s easy to find and block the ChatGPT app if it’s already in a tenant. In addition, ChatGPT cannot process encrypted files protected by sensitivity labels because it doesn’t have the access right needed to open protected files.
Don’t Drop Your Guard
No can argue that we do need to do better to secure tenants, so the changes proposed by Microsoft are welcome. The changes will begin rolling out in mid-July and are due to be in all tenants sometime in August 2025.
There are still too many tenants that don’t protect user accounts with multifactor authentication, which is why bad actors keep using password spray attackers in an attempt to compromise accounts. A recent report describes a password spray attack by a group called SneakyStrike against Entra ID accounts. The report is a little overhyped, but it’s a good reminder that attackers still patiently look for weak tenants to penetrate.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
thank you
Blocking user consent is generally a good practice, but it can have a significant impact on existing applications. If a user’s token expires or they need to reconsent, admin approval will be required by the system. For example, if an app is used by multiple users via user consent, any new user will also need admin approval to use the same app. It may be helpful to explore alternative methods for managing future user consent before implementing this change.
Or be proactive and create a report about existing apps and permissions and take appropriate action to make sure that everyone stays working. The new restriction only applies to new grants. It is not retrospective.