App Governance and Permission Policies

Org-wide app settings act as a master switch controlling whether third-party apps, custom apps, and Microsoft apps can be installed in Teams at all across the tenant. Beneath that, app permission policies govern which specific apps, categorized as Microsoft apps, third-party apps, or custom apps, individual users or groups are allowed to install, are blocked from installing, or must have explicitly approved by an admin. A block always takes precedence over an allow when an app appears on both a policy's allow and block list simultaneously.

Admins create custom app permission policies that specify allowed and blocked apps per category, and can assign a different policy to, for example, the legal department versus the sales department. Publisher verification, shown as a blue verified badge earned through Microsoft 365 Publisher Attestation or Partner Center identity verification, signals that an app's publisher completed identity and security attestation, giving admins a stronger signal before allowing an app tenant-wide, especially for apps requesting broad Microsoft Graph permissions.

The App governance add-on, part of Microsoft Defender for Cloud Apps, continuously evaluates OAuth-consented apps registered in Microsoft Entra ID and calculates a risk score based on the sensitivity of the Microsoft Graph permissions they hold, such as Mail.ReadWrite or Files.ReadWrite.All being far riskier than User.Read. It surfaces anomaly alerts, for example an app suddenly calling Graph from an unfamiliar country, and lets admins configure automated policies that alert on, or automatically revoke, tokens for apps deemed over-privileged or behaving suspiciously.

When publishing internal line-of-business Teams apps, developers should request the narrowest Microsoft Graph scopes needed for the feature, for instance requesting Chat.Read instead of Chat.ReadWrite for a bot that only summarizes conversations. Admins should route consent requests for apps needing high-privilege, tenant-wide, or admin-consent-required permissions through the admin consent workflow in Entra ID rather than allowing individual users to consent, since user consent for sensitive scopes bypasses centralized security review.