In many of the Microsoft 365 tenants I review, OAuth apps pile up in Entra ID with hardly anyone noticing. Some are leftover tests, some are critical workflow tools, and some have simply been forgotten. The recent wave of attacks abusing OAuth apps has made app governance for OAuth apps something every tenant with cloud integrations should keep an eye on. You need to know who actually holds ongoing access to sensitive data in your tenant, how much permission these apps have, and whether you would spot suspicious activity or be able to shut down abuse before it gets out of hand. Without systematic monitoring, risky apps easily go unnoticed, particularly when user consent is open or the admin consent workflow isn't enforced.

App governance adds usage data to Defender for Cloud Apps

App governance is an add-on to Microsoft Defender for Cloud Apps (included in Defender for Cloud Apps Plan 2 or Microsoft 365 E5) that focuses on monitoring OAuth apps in Microsoft environments (details and requirements). What makes it valuable is that it looks at both the permissions an app has been granted and the actual usage patterns when that app accesses data via Microsoft Graph, often with broad delegated or application permissions. The dashboard does more than list which apps exist. You see who used an app, when, how much traffic it generated and which resources it accessed. That makes it very easy to spot "zombie" apps nobody has touched in months, or apps that clearly have far more rights than they need. You get real usage data to base the cleanup of unused service principals on, and excessive permissions are much less likely to slip through.

The dashboard shows permissions next to real usage

In the app governance view you can quickly answer questions like these:

  • Which OAuth apps are registered, and by whom?
  • Which permissions have they been granted, and are any of them especially broad (like "Mail.ReadWrite" or "Files.Read.All")?
  • When did each app last access data (such as mail or files)?
  • Are there unusual usage spikes or data access anomalies?

Unused apps should be deleted or have their permissions revoked. Overprivileged apps can be restricted or blocked outright, directly from the app governance dashboard. The integration with Defender XDR pushes app-related alerts into incident timelines, which helps a lot during investigations. If you want lessons from a real incident, have a look at my post on Midnight Blizzard, OAuth apps and test tenants.

One thing I keep running into with in-house automations is that developers default to application permissions simply because it's easier. If you still use client secrets for service principals, moving to a modern option like workload identity federation should be high on your list (more in this post).

Built-in policies catch suspicious apps and let you act on them

One of the big strengths of app governance is its set of built-in policies. They raise an alert when, for example, a new app shows up with excessive permissions, an app suddenly downloads large volumes of data, or data access moves to a new geographic region (overview of policy types). Admins can adjust the thresholds and get targeted notifications. The threat detection engine also flags common attack patterns, such as apps trying to export large amounts of email or mass-copy OneDrive files. Apps flagged as suspicious or malicious can be disabled directly in the portal.

Before I get to the code, here's a diagram of the OAuth app lifecycle and where app governance adds monitoring and enforcement.

flowchart TD
  AppReg["OAuth app registered"] --> Consent["User/admin consent granted"]
  Consent --> Graph["Data access via Graph"]
  Graph --> AppGov["App governance monitors access"]
  AppGov --> Detect["Policy triggered?"]
  Detect -- "No" --> Normal["Normal usage"]
  Detect -- "Yes" --> Alert["Alert and block"]

Figure: OAuth app lifecycle and how app governance monitors it

Having real-time monitoring, incident correlation in Defender XDR and the option to act immediately in one place makes a real difference in daily operations. It goes beyond visibility, because automated response becomes possible, and that is a big step forward.

Consent settings and the admin consent workflow keep risky apps out

Prevention is still better than cleaning up afterwards. User consent settings in Entra ID let you restrict which apps end users are allowed to consent to (docs). In almost every production tenant I work with, user consent is turned off for apps that need more than basic profile information. Everything else goes through the admin consent workflow. Users can request access to an app, and an admin reviews the request and explicitly approves it. That drastically lowers the chance of malicious or overprivileged apps getting a foothold. Reviewing consent requests and past app consents on a regular basis is a habit worth building. In my experience, the more transparent the process, the less shadow IT shows up.

Practical tip: To find apps with broad permissions they hardly use, go to the Microsoft Defender portal → Cloud apps → App governance → "Microsoft Entra ID" tab, filter by privilege level "High" and look at the data usage details. Apps that are allowed a lot but move very little data are the first candidates for reduced permissions or for disabling.

App governance costs extra but earns its place

App governance doesn't come for free. You need Defender for Cloud Apps Plan 2 or a Microsoft 365 E5 license per covered user. For larger organizations the investment pays for itself quickly once you weigh it against the risk of uncontrolled apps. Smaller organizations should at least make full use of user consent restrictions and tight app policies, even if they miss out on the advanced automation and threat detection.

For me, app governance has become a core tool for securing the "app layer" in Entra ID. Microsoft's toolbox lacked this kind of visibility, targeted policies and fast response for far too long. As attacks get more sophisticated, app governance belongs at the center of every tenant's security strategy.