When you submit a request for admin consent, UW-IT follows this process:
- Consult with affected app owners: We verify with the owners of the applications you're requesting permissions for (for Microsoft apps, this is the relevant UW-IT service owner). If they object, the request will be denied.
- Check for precedent: We review similar past approvals and any required mitigations or permissions we've decided not to grant. Some of these precedents are documented below.
- Evaluate business necessity: We ensure the request doesn't exceed what's needed for the stated business purpose.
- Balance risk and need: We aim to enable legitimate business use with minimal friction while properly mitigating risks involving UW confidential data.
- Document the decision: All approvals are recorded for audit compliance.
Appeals process: Decisions may be appealed to the UW-IT Microsoft Change Advisory Board
Applications Without Publisher Verification
We are less likely to approve third-party applications lacking Microsoft publisher verification. Most reputable vendors complete this verification process to establish trust. An "Unverified" notice in the consent dialog is a red flag. Depending on the scenario, we may overlook this.
Applications That Force Enterprise-Wide Consent
We generally won't approve third-party applications that require admin consent solely for non-administrator delegated permissions. This design forces enterprises to accept the application for all users or none at all, which exceeds business need when user consent would work fine. We can sometimes find workarounds which overcome this aggressive vendor design that is inappropriate for an enterprise at our scale and diversity.
Exception: We may make exceptions for verified third-party applications with a large UW user population.
Starting in 2025, Microsoft began requiring admin consent for certain delegated permissions that aren't administrator-level. These permissions are considered risky enough that user consent is no longer allowed by default.
Affected Permissions
| Permission Category |
Permissions |
|
Sharepoint Online and OneDrive for Business via MC1097272.
|
MSGraph: Files.Read.All (delegated) MSGraph: Files.ReadWrite.All (delegated) MSGraph: Sites.Read.All (delegated) MSGraph: Sites.ReadWrite.All (delegated)
|
|
Exchange Online and Teams via MC1163922.
|
MSGraph: Calendars.Read (delegated) MSGraph: Calendars.Read.Shared (delegated) MSGraph: Calendars.ReadBasic (delegated) MSGraph: Calendars.ReadBasic.Shared (delegated) MSGraph: Calendars.ReadWrite (delegated) MSGraph: Calendars.ReadWrite.Shared (delegated) MSGraph: ChannelMessage.Read.All (delegated) MSGraph: Chat.Read (delegated) MSGraph: Chat.ReadWrite (delegated) MSGraph: EAS.AccessAsUser.All (delegated) MSGraph: EWS.AccessAsUser.All (delegated) MSGraph: IMAP.AccessAsUser.All (delegated) MSGraph: Mail.Read (delegated) MSGraph: Mail.Read.Shared (delegated) MSGraph: Mail.ReadBasic (delegated) MSGraph: Mail.ReadBasic.Shared (delegated) MSGraph: Mail.ReadWrite (delegated) MSGraph: Mail.ReadWrite.Shared (delegated) MSGraph: MailboxItem.Read (delegated) MSGraph: OnlineMeetings.Read (delegated) MSGraph: OnlineMeetings.ReadWrite (delegated) MSGraph: OnlineMeetingsRecording.Read.All (delegated) MSGraph: OnlineMeetingTranscript.Read.All (delegated) MSGraph: POP.AccessAsUser.All (delegated)
|
Options for These Permissions
We have two potential solutions:
Option 1: Add to Custom Consent Policy
This re-enables user consent for the application. Available when one of the following conditions are valid:
- The application's home tenant is UW, there's a valid business need, and no security concerns exist
- The third-party application has publisher verification and has no security concerns
Option 2: Grant Admin Consent
Available when one of the following conditions are valid:
- The application's home tenant is UW, there's a valid business need, and no security concerns exist
- The third-party application has publisher verification, serves a large UW user population, and has no security concerns
If your application qualifies for one of these solutions,
submit a request for our consideration.
Note: UW may expand the user consent options in the future as we adapt to Microsoft's significant changes in consent policies. This topic is under active discussion.
UW-IT continuously monitors the enterprise Entra ID tenant for applications with risky permissions. When we detect an unapproved application with risky permissions:
- Alerts are raised
- The application is disabled
- The application enters a review process
- If approved, the application is re-enabled; if not, it's deleted
What Qualifies as Risky?
Currently, UW-IT considers any permission with a type of admin to be risky. These are broad permissions typically requiring administrator-level authority, such as the ability to access an application as any user without their knowledge or consent.
Want to suggest additional risky permissions? Email
help@uw.edu with "Entra ID risky permission request" in the subject line. The service manager will review your request.
If you don't know the specific permission scopes but have gotten the admin consent error, please share the specific URL with us in your request. That URL should look something like this:
https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}