App Governance in Defender for Cloud Apps: Your OAuth App Security Command Centre

Alright, class. Take your seats.

We've covered Shadow IT discovery. We've drilled deep into policies. You've learned how to detect, block, and govern cloud apps in your environment. But here's the problem: you're still only watching half the battlefield.

While you were busy sanctioning apps and tuning policies, your users were clicking "Allow" on OAuth consent prompts. Lots of them. That harmless-looking "Calendar Helper" app? It just got full access to every email in your tenant. That productivity tool someone in Marketing installed? It's been quietly downloading files from SharePoint for three months. And that app with the suspiciously generic name and a logo that looks almost like Microsoft's? Yeah, that's exfiltrating data to a server in a country you can't pronounce.

Welcome to the world of OAuth app abuse, the attack vector that bypasses your MFA, laughs at your conditional access policies, and doesn't care how many Secure Score points you have. This is where App Governance in Microsoft Defender for Cloud Apps comes in.

If you've been following along with our Defender for Cloud Apps series (and if you haven't, go read the introduction to MDCA discovery and the deep dive into policies), you already understand how MDCA gives you visibility into cloud apps and lets you control them with policies. App Governance takes that concept and laser-focuses it on OAuth enabled apps, the apps that users can install with a single click, granting them permissions that would make a Global Admin jealous.

OAuth Apps Are the New Favourite Attack Vector

OAuth apps are everywhere, and most of them are invisible to traditional security controls.​

When an attacker compromises a user account, what's the first thing they do? They could steal data directly, but that's risky; MFA challenges, impossible travel alerts, and conditional access policies will start screaming. Instead, they do something far more elegant: they register a malicious OAuth app, grant it permissions to access the user's data, and then the app becomes the persistent backdoor.​

Here's why this is terrifying:

OAuth apps survive credential resets. You detected the compromised account, forced a password reset, and revoked all sessions. Great! Except for the malicious OAuth app the attacker registered still has full access to that user's mailbox, OneDrive, and Teams chats.​

OAuth apps bypass MFA. The app was granted permissions by the user (or an admin). It doesn't need to authenticate again. It just uses its token and merrily accesses your data.​

OAuth apps are hard to spot. They blend in with the 50+ legitimate OAuth apps your users have already authorized. Unless you're actively hunting, that "Microsoft Office Helper" app (registered three days ago by a tenant in Eastern Europe) looks totally normal.​

Real-world example: The Midnight Blizzard attack used OAuth apps to pivot across tenants and maintain persistence even after Microsoft detected and blocked the initial compromise. This isn't theoretical. This is happening right now.​

App Governance is Microsoft's answer to this problem. It's a dedicated set of capabilities within Defender for Cloud Apps designed specifically to give you visibility, detection, and automated response for OAuth apps across Microsoft 365, Google Workspace, and Salesforce.​​

App Governance Features at a Glance

App Governance delivers four core capabilities:​

Insights: A unified dashboard showing all OAuth apps registered in your Microsoft Entra ID, Google Workspace, or Salesforce tenants. You see every app, what permissions it has, who consented to it, how much data it's accessing, and whether it's doing anything suspicious.

Governance: Proactive and reactive policies that detect risky app behaviours and automatically take action, disabling apps, revoking permissions, notifying admins, or alerting users.

Detection: Machine learning-powered anomaly detection that alerts you when apps exhibit suspicious behaviour, mass email sending, unusual data access, suspicious OAuth scopes, credential updates followed by anomalous activity, and more.​

Remediation: Automated and manual controls that let you disable apps.

If you've read my previous post on MDCA policies, you'll recognise the pattern: detect, alert, govern. App Governance applies that same philosophy specifically to OAuth apps, with detections tuned to the unique threats they present.

Enabling App Governance (It's Not On by Default)

Here's the part that surprises most admins: App Governance is included in your Defender for Cloud Apps license, but it's not enabled by default.​

That's right. You're paying for it. It's sitting there, ready to protect you. And it's turned off (gg Microsoft)

Prerequisites

Before you enable App Governance, make sure you have:​

• A valid Defender for Cloud Apps license (standalone or bundled with Microsoft 365 E5)
• One of the following roles:
  • Global Administrator
  • Security Administrator
  • Compliance Administrator
  • Compliance Data Administrator
  • Cloud App Security Administrator

Enabling App Governance

1. Navigate to the Microsoft Defender portal (security.microsoft.com).
2. Go to Settings > Cloud Apps > App governance.
3. Click Turn on app governance.
4. Wait up to 10 hours for the backend to provision and start collecting data.​

Important: App Governance alerts won't flow to Microsoft Defender XDR or show up in the app governance dashboard until you've provisioned both Defender for Cloud Apps and Microsoft Defender XDR by accessing their respective portals at least once.​

Once enabled, App Governance starts collecting data from Microsoft Entra ID and Defender for Cloud Apps, building a profile of every OAuth app in your environment.​

Your OAuth App Command Centre

After App Governance has had time to collect data, navigate to Microsoft Defender XDR > Cloud Apps > App governance > Overview.​

This is your command centre. Here's what you're looking at:

Tenant Summary

At-a-glance counts of key app and incident categories:

• Total apps registered in your tenant
• Overprivileged apps (apps with permissions they haven't used in the last 90 days)
• Highly privileged apps (apps with powerful permissions like Mail.ReadWrite, Files.ReadWrite.All, or Directory.ReadWrite.All)
• Active incidents (ongoing app governance alerts)​

Apps That Accessed Data Across Microsoft 365 Services

A breakdown showing how many apps accessed data in SharePoint, OneDrive, Exchange Online, and Teams in the last 30 days, including how many of those apps accessed sensitivity-labelled data.​

This is gold for compliance teams. If you've got 99 apps accessing OneDrive and 27 of them are touching "Confidential" labelled files, you need to know which apps those are and whether they should have that access.

Sensitivity Labels Accessed

A count of apps that accessed labelled data, sorted by sensitivity label (e.g., "Confidential," "Highly Confidential," "Internal Only").​

If 90 apps accessed "Confidential" data across your environment, you better believe some of those apps are suspicious.

Predefined Policies

A count of active and total predefined policies. These are Microsoft's out-of-the-box detection policies (more on these in a moment).​

App Categories

The top apps sorted by risk categories:

• Highly privileged: Apps with powerful permissions based on Microsoft's machine learning and threat intelligence
• Overprivileged: Apps with permissions they haven't used in 90+ days
• Unverified publisher: Apps from publishers who haven't completed Microsoft certification
• App-only permissions: Apps that can run without a signed-in user (these are especially dangerous)
• New apps: Apps registered in the last seven days​

Click on any category to drill down into the apps. This is where the investigative work starts.

Investigating Apps: From Overview to Deep Dive

On the App governance page, you'll see multiple tabs: Microsoft 365, Google apps, and Salesforce apps (if you've connected those services).​

Let's focus on Microsoft 365 apps, since that's where most organisations will spend their time.

The App List

The app list shows every OAuth app registered in your Microsoft Entra ID tenant, with columns for:​

You can filter and sort by any of these columns. Want to see all unverified publisher apps with high privileges? Filter for it. Want to find apps that haven't been used in months but still have access to sensitive data? Sort by "Last modified" and cross-reference with "Permission usage."

Drilling Into an App

Click on any app to open its details panel.​

Summary Tab: Shows app usage over the past 30 days, and permissions assigned. You also see the app ID, first consent date, and a link to View in Microsoft Entra ID for full registration details.

Data Usage Tab: A graph showing data accessed over time for Exchange, SharePoint, OneDrive, and Teams via Microsoft Graph and EWS APIs. You can filter by priority accounts to see if high-value users are being targeted.​

Users Tab: A list of users who consented to the app, whether they're priority accounts, and how much data they've uploaded/downloaded. If an app is admin-consented, the "Total consented users" is all users in the tenant.​

Permissions Tab: A detailed list of Graph API and legacy permissions granted to the app, including consent type, privilege level, and whether the permission is in use. This is where you spot overprivileged apps.​

Sensitivity Labels Tab: Shows how frequently the app accessed items with specific sensitivity labels on Microsoft 365 (e.g., "Confidential," "Internal").​

At the bottom of the pane, you'll see a Disable app button (or Enable app if it's already disabled). Use this to immediately cut off an app's access to your tenant.​

Predefined Policies: Microsoft's Built-In Threat Detections

App Governance includes a set of predefined policies that detect anomalous and malicious OAuth app behaviours. These policies are enabled by default (though Microsoft disabled a few in April 2025 due to high false-positive rates).​

To view predefined policies, go to Microsoft Defender XDR > App governance > Policies and filter for Source: Predefined.​

What Predefined Policies Detect

Here are some of the key predefined policies (categorised by MITRE ATT&CK tactics):​

Initial Access:

• App redirects to a phishing URL by exploiting an OAuth redirection vulnerability
• OAuth app with suspicious Reply URL
• The app created recently has a low consent rate
• App with bad URL reputation
• Encoded app name with suspicious consent scopes
• New app with mail permissions has a low consent pattern
• New app with a low consent rate accessing numerous emails​

Persistence:

• App made anomalous Graph calls to Exchange workload post certificate update
• App with suspicious OAuth scope made graph calls to read email and created an inbox rule
• App accessed from an unusual location post certificate update
• App metadata associated with a known phishing campaign
• Suspicious OAuth app email activity through Graph API​

Privilege Escalation:

• OAuth app with suspicious metadata has Exchange permission​

Defense Evasion:

• App impersonating a Microsoft logo
• App is associated with a typosquatted domain​

Credential Access:

• Application initiating multiple failed KeyVault read activity with no success​

Collection:

• App made unusual email search activities
• App made anomalous Graph calls to read email
• App creates an inbox rule and makes unusual email searches
• App made numerous searches and edits in OneDrive
• Privileged app performed unusual activities in Teams​

Exfiltration:

• OAuth app using unusual user agent
• App with an unusual user agent accessed email data through Exchange Web Services​

Each policy is powered by machine learning and behavioural analytics. When triggered, the policy creates an alert in the Microsoft Defender XDR alerts queue with the Detection source set to "App Governance".​

Tuning Predefined Policies

By default, predefined policies only generate alerts. But you can configure them to automatically disable the app when triggered.​

Profo's Wisdom: Be very careful with automatic disablement. If a policy has a high false-positive rate (like "Unusual activity from an app with priority account consent"), you'll disable legitimate apps and create a support ticket nightmare. Start with alerts, tune the policy by excluding known-good apps, and then consider enabling automatic actions.

To configure a policy:​

1. Go to App governance > Policies.
2. Select the predefined policy.
3. In the policy details pane, check the Disable app box under Policy action.
4. Click Save.

Creating Custom App Policies: Building Your Own Detections

Predefined policies are great, but every organisation has unique risks. That's where custom app policies come in.​

To create a custom app policy:​

1. Go to Microsoft Defender XDR > App governance > Policies > Azure AD (or Google apps / Salesforce apps).
2. Click Create New Policy.
3. Choose a policy template category (e.g., "New uncertified app," "Suspicious app behaviour," "Compliance") or select Custom.

Example Custom Policy: Disable High-Privilege Apps without a verified publisher

Scenario: You want to identify applications that lack a verified publisher; these could be custom ones created by your development or IT team, posing a security risk.

Policy configuration:

• Condition 1: App without verified publishers
• Condition 2: Privilege level = High
• Condition 3: Priority account consent = Yes
• Action: Disable app + Notify admin

This is app hygiene in action, proactively cleaning up your OAuth app attack surface.​

Remediation Actions: Taking Control of Risky Apps

When you identify a risky or malicious OAuth app, you have several remediation options:​

Disable the app: Immediately revokes the app's ability to access resources in your tenant. Users will see an error if they try to use the app. This is the nuclear option; use it for confirmed malicious apps.​

Revoke app permissions: Removes all permissions granted to the app under "Enterprise Applications" in Microsoft Entra ID. This is available for Google Workspace and Salesforce apps.​

Ban the app: Mark the app as banned in Defender for Cloud Apps. This prevents future installations and can trigger alerts if users attempt to authorise it again.​

Integration with Defender XDR and Sentinel

App Governance alerts flow directly into the Microsoft Defender XDR alerts queue, where they can be correlated with alerts from Defender for Endpoint, Defender for Identity, and Defender for Office 365.​​

App Hygiene: Keeping Your OAuth App Landscape Clean

One of the most underrated features of App Governance is app hygiene, the ability to identify and clean up stale, unused, or misconfigured apps.​

Here's the workflow:

1. Identify stale apps: Go to App governance > Microsoft 365 apps and filter for apps where "Last modified" is older than 90 days or "Permission usage" shows unused permissions.​
2. Review app permissions: For each stale app, check the Permissions tab. If the app has Mail.ReadWrite.All or Files.ReadWrite.All but hasn't used those permissions in 90 days, it's overprivileged.​
3. Disable or revoke: Disable the app or revoke the unused permissions.​
4. Create a hygiene policy: Automate this process with a custom policy that alerts (or auto-disables) apps meeting your stale/overprivileged criteria.​

Profo's Wisdom: App hygiene isn't glamorous, but it's one of the most effective ways to reduce your attack surface. Every unused, overprivileged app is a potential backdoor waiting to be exploited. Clean it up.

Managing Google Workspace and Salesforce OAuth Apps

If you've connected Google Workspace or Salesforce to Defender for Cloud Apps, App Governance extends to those platforms as well.​

On the Google apps or Salesforce apps tabs, you'll see:

• Authorized by: Number of users who authorised the app
• Permission level: High, Medium, or Low
• Last authorized: Most recent consent date (Salesforce only)
• Actions: Mark the app as approved or banned​

Click Show details to see:

• Full permissions list (Google only)
• Community use (common, uncommon, rare)
• App activities log
• Last used date (Salesforce only)​

You can revoke app permissions or notify users directly from the app governance interface.​

Bringing It All Together: A Real-World Workflow

Let's walk through a realistic scenario.

Alert: You receive an App Governance alert: "New app with low consent rate accessing numerous emails."

Investigation:

1. Navigate to App governance > Microsoft 365 apps.
2. Find the app in the list. It was registered three days ago, has an unverified publisher, and has been consented to by only five users, but it's accessed 5,000 emails in the last 24 hours.
3. Click on the app to open the details pane.
4. Data Usage Tab: Massive spike in Exchange data access.
5. Users Tab: All five users are in the Finance department.
6. Permissions Tab: The app has Mail.ReadWrite, Mail.Send, and Contacts.Read.
7. Summary Tab: The app's Reply URL points to a recently registered domain with a suspicious TLD.

Verdict: This is a malicious OAuth app. Likely part of a phishing campaign targeting Finance.

Remediation:

1. Click Disable app to immediately cut off access.
2. Navigate to Microsoft Defender XDR > Alerts and classify the alert as a True Positive.
3. Go to Entra ID > Enterprise applications, find the app, and delete its service principal.
4. Reset passwords for all five affected users.
5. Run an investigation in Advanced Hunting to check if the app exfiltrated sensitive data.
6. Create a custom policy to alert on any future apps with similar characteristics (unverified publisher + low consent rate + high email access).

This is the App Governance workflow in action: detect, investigate, remediate, prevent recurrence.

Best Practices for App Governance

1. Enable it. Seriously. It's included in your license and not turned on by default. Go enable it right now.​
2. Review your app inventory monthly. Set a calendar reminder. Filter for high-privilege apps, unverified publishers, and stale apps.​
3. Tune predefined policies. Don't just accept the defaults. Exclude known-good apps, adjust thresholds, and enable automatic actions only after you're confident in the policy's accuracy.​
4. Create custom policies for your unique risks. If your organisation handles PCI data, create a policy that alerts when apps with Files.ReadWrite.All access SharePoint sites containing cardholder data.​
5. Investigate alerts promptly. App Governance alerts are high-fidelity. If it's alerting, there's a reason. Don't dismiss them without investigation.​
6. Disable stale apps. If an app hasn't been used in 90 days and has powerful permissions, disable it. You can always re-enable it if someone complains.​
7. Educate your users. Most OAuth app compromise happens because users click "Allow" without reading the permissions. Train them to recognise suspicious consent prompts.​

Lastly, a Profo's Wisdom outside of App Governance, for the love of everything secure. Disable this option "Users can register application". Having this option set as on by default is one of the biggest jokes from Microsoft I've seen in my career.

App Governance is the missing piece of your Defender for Cloud Apps strategy. You've got visibility into Shadow IT. You've got policies to govern cloud apps. Now you've got a dedicated command centre for OAuth app security, the attack vector that's becoming the preferred method for persistent access and data exfiltration.

Enable it. Review your app inventory. Tune your policies. Investigate your alerts. And for the love of all that is secure, disable those stale, overprivileged apps before an attacker finds them first.

OAuth apps aren't going away. Neither are the attackers exploiting them. But with App Governance, you're finally armed with the visibility and controls to fight back.

Class dismissed.