Skip to main content

App governance and OAuth app risk

Microsoft documentedDefender for Cloud Apps · Source checked 2026-10-22 · Not yet verified in tenant · Sources: [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17]

What it is​

App governance is the part of Defender for Cloud Apps that deals with OAuth apps rather than SaaS sessions. Learn defines it as "a set of security and policy management capabilities designed for OAuth-enabled apps registered on Microsoft Entra ID, Google, and Salesforce". In practice it answers four questions about every non-Microsoft app in the tenant: which permissions it holds, which users consented, what data it actually moves through Microsoft Graph and EWS, and whether its behaviour looks like consent phishing, token abuse or a compromised line-of-business app.

It is not the Entra enterprise apps blade with a new skin. Entra tells you what was granted. App governance adds what was used: API calls per day, GB uploaded and downloaded, services touched, sensitivity labels read, whether granted permissions have been exercised in the last 90 days, and a 1 to 100 risk score. On top of that sit two kinds of detection: user-defined and predefined policies you can read, and built-in machine learning threat detections you cannot edit.

It also is not the consent framework. Who may consent, to what, and whether blocked users can ask an admin are Entra settings. App governance watches the result. This article covers both halves because you cannot run one without the other: tight consent settings reduce the inflow of new apps, and app governance handles the ones already in, plus the ones admins approve. See the MDCA overview for where this sits next to the SaaS connectors, and policies and alerts for the wider policy engine.

Licensing and prerequisites​

  • Licence: Learn says app governance "requires a valid Defender for Cloud Apps license", standalone or in a bundle, and points at the Microsoft 365 licensing datasheet for the bundles. TODO: confirm the exact bundle list against the datasheet rather than memory.
  • Billing region: not available when the billing address is in Singapore, Poland, Italy, Qatar, Israel, Spain, Mexico or Taiwan. Other regions can hit capacity limits and land on a waitlist.
  • Roles to turn it on: Global Administrator, Security Administrator, Compliance Administrator, Compliance Data Administrator or Cloud App Security Administrator. Cloud App Security Administrator can switch it on but cannot see or manage anything afterwards.
  • Roles to run it: Security Operator and Security Administrator can read and change policies, alerts and settings. Security Reader and Global Reader are read-only. Only Global Administrator holds the Update remediation capability in the role table.
  • Microsoft 365 connector: recommended. Without it the activities and resources an OAuth app touched do not show in advanced hunting, which hurts investigation of several threat detections.
  • Google Workspace and Salesforce: their app connectors must be connected before the Google apps and Salesforce apps tabs populate.
  • Portal provisioning: alerts do not flow to the Defender portal or to app governance until both the Defender for Cloud Apps portal and the Defender portal have been opened at least once.
  • Time to data: up to 10 hours after enabling.
  • Entra consent settings: Privileged Role Administrator to change user consent settings. Global Administrator to turn on the admin consent workflow. Graph scopes Policy.ReadWrite.Authorization and Policy.ReadWrite.ConsentRequest respectively.
  • Workload identity risk (one paragraph later): all tenants get the detections, full detail and risk-based Conditional Access need Workload Identities Premium.

How it works​

Coverage​

Three app platforms feed the inventory. Entra-registered apps are the main one: every non-Microsoft service principal in the tenant, registered locally or in another tenant. For those, app governance reads Graph and EWS traffic, so data usage, API access, services accessed and sensitivity label signals exist only for apps that call Graph or EWS. Apps on non-Graph APIs still appear, but conditions marked Graph only are skipped for them. Google Workspace and Salesforce apps come in through their app connectors with a smaller column set: authorised-by count, permission level High, Medium or Low, community use, last used, risk score, and approve or ban actions. For Salesforce the inventory includes both Connected Apps and External Client Apps.

The inventory​

The Microsoft 365 tab is a grid of service principals. Key columns: risk score, permission type (Delegated, Application, Entra roles, Mixed or None), origin, consent type with the number of users whose data the app can reach, publisher verification, certification, last used (tracked back to June 2022), permission usage in the last 90 days, data usage in the last 30 days, privilege level, community use, and a preview column for AI agents using the identity. Saved queries such as Apps authorized by admins sit above the grid, and New policy from search turns a filter into a policy.

Opening an app gives tabs for Summary, Risk score with its factors, Graph (identity graph into Attack Map, Entra apps only), Data usage per workload, Users with priority account flags, Permissions, and Sensitivity labels. The Permissions tab lists each Graph and legacy permission with consent type, privilege level and in-use state, plus directly assigned Entra roles. Roles inherited through groups and Azure RBAC are not shown. With admin consent, Total consented users equals every user in the tenant.

Policies​

Policies evaluate app attributes, not individual events. Predefined policies are on by default and Microsoft changes their conditions over time. User-defined policies combine conditions with AND. Conditions include registration age, risk score, certification, publisher verified, application or delegated Graph permissions from a list, highly privileged, overprivileged (granted but unused Graph permissions), non-Graph API permissions, data usage and API access with their trends, number and growth of consenting users, priority account consent, named users or Entra roles of consenting users, sensitivity labels accessed, services accessed, error rate, last used, and origin. Severity on the policy becomes the alert severity. The only automated action is Disable app. Status is Active or Inactive. Templates cover unused app, new app with high data usage, increase in users, overprivileged app, new highly privileged app, new app with non-Graph API permissions, new high risk app, and new uncertified app.

Threat detections​

Separate from policies, and not listed on the Policies tab, are 45 built-in detections mapped to MITRE tactics. Initial Access is the consent phishing set: suspicious reply URLs, bad URL reputation, encoded or lookalike app names with mail scopes, new apps from new publisher tenants with mail permissions and a low consent rate, and apps reading or sending bulk mail shortly after consent. Persistence covers apps that add credentials then make anomalous Exchange calls, create inbox rules, or share metadata with a known phishing campaign. Collection covers unusual mail search, OneDrive and SharePoint enumeration, Teams reads, and EWS application permissions reading many mailboxes. Smaller groups cover Graph PowerShell enumeration, failed Key Vault reads through ARM, dormant Graph apps suddenly calling ARM, and bulk VM creation. Most are Medium; the High ones are the two suspicious OAuth app email activity alerts (Graph and EWS) and the unusual user agent on EWS. For Google and Salesforce there are four anomaly policies: misleading app name, misleading publisher name, malicious OAuth app consent, and suspicious file download.

Learn warns that these detections run on transient data, so an alert may show counts and spikes rather than a full activity record. For full Graph call history you need Graph activity logs in Log Analytics or Sentinel.

The dashboard​

App governance > Overview has a card for Entra connected OAuth apps (total, unused in 90 days, possibly overprivileged, highly privileged, high risk score), an incident summary split into threat incidents and policy incidents with the latest ten, top alerts, data accessed through Graph and EWS over the current and previous three months, apps accessing SharePoint, OneDrive, Exchange Online or Teams in the last 30 days, and apps that touched sensitivity-labelled content in the same window.

A user hits an app's consent prompt. Entra checks the user consent setting: none, verified publishers with low-impact permissions only, legacy allow-all, or a custom consent policy. If the setting blocks the grant and the admin consent workflow is on, the user files a request, reviewers get mail, and someone with the right role approves, which creates an AllPrincipals grant. If the setting allows it, a Principal grant is written for that user. Either way a service principal now exists, and app governance picks it up, scores it, runs the policies and starts watching its traffic. Consent settings affect future consents only; existing grants stay until revoked.

Entra workload identity risk​

ID Protection also scores applications and service principals, independently of app governance. Its detections are offline: Entra threat intelligence, suspicious sign-ins against a 2 to 60 day baseline, leaked credentials, malicious application (apps Microsoft disables for terms of service violations, shown as DisabledDueToViolationOfServicesAgreement), suspicious application, anomalous service principal activity, suspicious API traffic, and admin confirmed compromised. Managed identities are out of scope. Everyone gets the detections; Workload Identities Premium unlocks the detail and risk-based Conditional Access, which can block at-risk single-tenant service principals. Risk is viewed under ID Protection > Risky workload identities or through riskyServicePrincipals and servicePrincipalRiskDetections in Graph. App governance sees what the app does to data; ID Protection sees how the app authenticates.

Configure​

Enable app governance:

  1. Defender portal > Settings > Cloud apps > App governance (security.microsoft.com/cloudapps/settings).
  2. Select Use app governance. If the option is missing, join the waitlist; Microsoft turns it on by mail when capacity or region allows.
  3. Open both the Defender for Cloud Apps portal and the Defender portal at least once, then wait up to 10 hours.
The app governance toggle under Cloud apps settings. Source: Microsoft Learn, CC BY 4.0.
The app governance toggle under Cloud apps settings. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Review an app's permissions:

  1. Cloud apps > App governance > Microsoft 365 tab.
  2. Sort by Risk score or load the Apps authorized by admins query. Filter on Permission usage or Publisher.
  3. Select the app. Summary gives first consent date and app ID, Users gives who consented and priority account flags, Permissions gives each scope with consent type, privilege level and 90-day use.
  4. View in Microsoft Entra ID opens the enterprise app for the raw registration.
The Microsoft 365 apps grid. Risk score, permission type, consent type and publisher are the columns to sort on first. Source: Microsoft Learn, CC BY 4.0.
The Microsoft 365 apps grid. Risk score, permission type, consent type and publisher are the columns to sort on first. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22
Permissions tab: each Graph scope with consent type, privilege level and in-use state. Unused high-privilege scopes are the cleanup list. Source: Microsoft Learn, CC BY 4.0.
Permissions tab: each Graph scope with consent type, privilege level and in-use state. Unused high-privilege scopes are the cleanup list. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Create a policy for a new app with high-privilege mail permissions and few users:

  1. App governance > Policies > Microsoft 365 > Create New Policy.
  2. Category Custom > template Custom policy > Next.
  3. Name it, give it severity High. Severity becomes the alert severity.
  4. Policy settings: All Apps.
  5. Edit conditions > Add condition. Add Registration age within last 7 days. Add Application permissions and pick mail scopes such as Mail.Read, Mail.ReadWrite, Mail.Send; add Delegated permissions with the same scopes if you want both consent types. Add Number of consenting users less than 5. Save each rule. Conditions are AND.
  6. Policy actions: leave Disable app off for the first weeks. Check alert volume on the Policies page, then switch the action on if the hits are clean.
  7. Status Active > Submit.

The nearest template is New highly privileged app. The custom version narrows it to mail and adds the low user count typical of consent-phishing apps.

Template picker: usage, permission, risk and certification templates, or Custom. Source: Microsoft Learn, CC BY 4.0.
Template picker: usage, permission, risk and certification templates, or Custom. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Disable an app:

  1. App governance > Microsoft 365 > select the app > Disable app in the details pane. Enable app reverses it. The Status column records who disabled it.
  2. For Google and Salesforce apps, use the Actions column to mark the app approved or banned, or revoke from the permission details.

Dashboard check: App governance > Overview, read the four Entra OAuth app counters and the incident split.

Overview page incident summary: threat incidents versus policy incidents. Source: Microsoft Learn, CC BY 4.0.
Overview page incident summary: threat incidents versus policy incidents. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Entra user consent settings:

  1. Entra admin center > Identity > Applications > Enterprise apps > Consent and permissions > User consent settings.
  2. Pick Do not allow user consent, or Allow user consent for apps from verified publishers for selected permissions (needs permission classification set up), or the legacy Allow user consent for apps. Save. Applies to future consents only.
User consent settings: the three built-in choices. Source: Microsoft Learn, CC BY 4.0.
User consent settings: the three built-in choices. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Admin consent workflow:

  1. Entra admin center > Enterprise apps > Consent and permissions > Admin consent settings.
  2. Set Users can request admin consent to apps they are unable to consent to = Yes.
  3. Pick reviewers (users, groups or roles), turn on reviewer email and expiry reminders, set the expiry in days. Save. Up to an hour to take effect.
  4. Reviewers see requests in My Pending. Being a reviewer does not grant the right to approve; the reviewer still needs the role that can grant admin consent, and only Global Administrator can approve requests for Graph application permissions.
Admin consent workflow settings: reviewers, notifications, reminders, expiry. Source: Microsoft Learn, CC BY 4.0.
Admin consent workflow settings: reviewers, notifications, reminders, expiry. Source: Microsoft Learn, CC BY 4.0. · captured 2026-10-22

Verify​

  • Settings > Cloud apps > App governance shows the service as on. App governance > Overview populates within 10 hours.
  • The Microsoft 365 tab lists your known third-party apps with a risk score and a Last used date. If an app you know calls Graph shows no data usage, the Microsoft 365 connector is the usual gap.
  • Policies > Microsoft 365 lists predefined policies with Source Predefined and your custom policy with Source User defined and Status Active. Watch Active alerts and Total alerts on the row over the first days.
  • Consent setting: Get-MgPolicyAuthorizationPolicy returns the policy ids you set. A test user consenting to an unverified multi-tenant app should get the admin approval prompt instead of a grant.
  • Revocation: after DELETE on a grant, the same GET filtered on clientId no longer returns it. The list API is eventually consistent, so re-query after a minute.
  • Alerts: Defender portal > Incidents and alerts, filter Detection source = App Governance.
// New consents in the last 7 days from the Microsoft 365 connector feed.
// Needs the Microsoft 365 connector; TODO confirm exact ActionType strings in the dev tenant.
CloudAppEvents
| where Timestamp > ago(7d)
| where ActionType in ("Consent to application.", "Add delegated permission grant.", "Add app role assignment to service principal.")
| extend App = tostring(RawEventData.Target[3].ID)
| project Timestamp, ActionType, AccountDisplayName, App, RawEventData
| order by Timestamp desc

Troubleshoot​

SymptomLikely causeFix
Use app governance option missing in settingsRegion not supported, capacity constraint, or billing address in an excluded countryJoin the waitlist. Excluded billing countries cannot enable it
Enabled, Overview still emptyWithin the 10 hour populate windowWait, then confirm the account holds a role that can read app governance
Cloud App Security Administrator cannot open app governanceThat role can only enable itAdd Security Operator or Security Reader
No alerts in the Defender portalOne of the two portals never openedOpen both the Cloud Apps portal and the Defender portal once
App shows no data usage or services accessedMicrosoft 365 connector missing, or app uses only non-Graph APIsConnect Microsoft 365; accept that Graph only conditions are skipped for non-Graph apps
Custom policy fires far less than expectedConditions are AND, Graph only conditions skippedRemove a condition at a time; check Policies page counts
Policy with Disable app broke a line-of-business appAction fired on a legitimate appEnable app in the details pane, loosen conditions, run alert-only first
Grant deleted but app still worksExisting access tokens remain valid until expiryWait for token lifetime, or also disable the service principal
Revoked one grant, app still has accessBoth Principal and AllPrincipals grants existList with clientId filter and delete both
Users blocked from consent and no request optionAdmin consent workflow off, or under the one hour enable delayTurn the workflow on and wait
Reviewer cannot approveReviewer lacks the role to grant admin consent; app requests Graph application permissionsUse an account with the required role, Global Administrator for app roles
Google or Salesforce tab emptyConnector not connectedConnect the app connector first

Gotchas and limits​

  • No report-only mode on the create page. The trial user guide mentions an audit mode, the create page does not. Until checked, alert-only (Disable app unticked) is the test mode. TODO: check the wizard.
  • Policy names cannot be changed after creation. Learn says disable rather than delete a policy you may need again.
  • Predefined policies change under you. Microsoft edits their conditions and adds new ones, so alert volume can move with no change on your side.
  • The Permissions tab omits roles inherited through groups and all Azure RBAC. An app holding Owner on a subscription looks clean here.
  • Last used tracking only goes back to June 2022. Older apps with no sign-ins since then show as unused.
  • With admin consent, Total consented users is the whole tenant, so consenting user count conditions behave differently for admin-consented apps.
  • Deleting an OAuth grant does not kill issued tokens. For a live incident, disable the service principal and reset the consenting users as the detection playbooks say.
  • Consent settings are future-only. Switching to verified publishers plus low-impact does nothing to existing grants, and that mode is useless until permission classification has something marked low.
  • Reviewers removed from the admin consent workflow keep their open requests and reminders. New reviewers do not inherit older requests.
  • Workload identity Conditional Access covers only single-tenant service principals in your own tenant. The multi-tenant SaaS apps behind most OAuth incidents are out of its reach; app governance is the control for those.
  • Learn's user consent page has a doubled managePermissionGrantsForSelf. prefix in one PowerShell sample and a malformed JSON body in one REST sample. This article uses the corrected form.

Further reading​

My notes​

TODO: Sohail's notes after verification.

Changelog​

DateChangeSource
2026-10-22Drafted from Learn, with Learn images and diagrams[1]