When you submit a request for admin consent, UW-IT follows this process:

1. 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.
2. 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.
3. Evaluate business necessity: We ensure the request doesn't exceed what's needed for the stated business purpose.
4. Balance risk and need: We aim to enable legitimate business use with minimal friction while properly mitigating risks involving UW confidential data.
5. Document the decision: All approvals are recorded for audit compliance.

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 discourage 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. Microsoft publishes which permissions are included at https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/manage-app-consent-policies?pivots=ms-powershell#microsoft-recommended-user-consent-policy and may change the list at any time, so the list there may not match what is listed here. 

Affected Permissions

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

UW-IT continuously monitors the enterprise Entra ID tenant for applications with risky permissions. When we detect an unapproved application with risky permissions:

1. Alerts are raised
2. The application is disabled
3. The application enters a review process
4. 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.