Intermediate โฑ 75 min ๐Ÿ“‹ 10 Steps

Monitor & Control OAuth Apps with App Governance

Enable App Governance in Defender for Cloud Apps, monitor OAuth-enabled apps accessing Microsoft 365 data, create app policies for overprivileged and suspicious apps, investigate app threats, and enforce app compliance across your tenant.

๐Ÿ“‹ Overview

About This Lab

App Governance extends Microsoft Defender for Cloud Apps with deep visibility into OAuth applications registered in your Microsoft Entra ID tenant. It continuously monitors which apps access Microsoft 365 data (Exchange, SharePoint, OneDrive, Teams), how much data they consume, what permissions they hold, and whether their behavior is anomalous. It detects overprivileged apps, apps from unverified publishers, anomalous data access patterns, and suspicious credential changes. providing the security controls needed to prevent OAuth-based supply-chain attacks and illicit consent grants.

๐Ÿข Enterprise Use Case

A company discovers 340 OAuth apps with access to their Microsoft 365 data. Of those, 47 have excessive permissions (Mail.ReadWrite, Files.ReadWrite.All) that far exceed their stated purpose. 12 are from unverified publishers with no publisher attestation. 3 apps show anomalous data access. one HR survey tool downloaded 15 GB of SharePoint data overnight. The security team needs comprehensive visibility into all OAuth apps, risk assessment based on permissions and behavior, automated policies to block risky consent, and a remediation workflow to revoke access from compromised or overprivileged applications.

๐ŸŽฏ What You Will Learn

  1. Enable App Governance in Defender for Cloud Apps and verify data collection
  2. Navigate the App Governance dashboard and understand key metrics
  3. Investigate OAuth app permissions and identify overprivileged applications
  4. Review app data access patterns and detect anomalous data usage
  5. Create app compliance policies to block unverified and high-privilege apps
  6. Create threat detection policies for anomalous app behavior
  7. Investigate and triage App Governance alerts
  8. Remediate risky apps by disabling, revoking consent, and blocking future access
  9. Configure app consent policies and admin consent workflows in Entra ID
  10. Establish ongoing app governance operations and monitoring

๐Ÿ”‘ Why This Matters

OAuth app attacks bypass traditional perimeter defenses entirely. Attackers use illicit consent grants and malicious app registrations to gain persistent access to email, files, and Teams. without needing user credentials. Once an OAuth app has delegated permissions, it can access data silently in the background, even after the user changes their password or enables MFA. High-profile attacks like the Storm-0558 campaign and Midnight Blizzard’s abuse of OAuth apps demonstrate that app-based attacks are a primary method used by nation-state and financially motivated threat actors. Without App Governance, most organizations have zero visibility into what their OAuth apps are actually doing.

โš™๏ธ Prerequisites

  • Microsoft Defender for Cloud Apps license. E5 Security, M365 E5, or standalone MDCA
  • App Governance add-on. included with M365 E5 or available as add-on
  • Global Administrator or Security Administrator. for initial App Governance setup
  • Cloud App Security Admin role. for ongoing policy management
  • Microsoft Graph PowerShell SDK. for API-based investigation and remediation
  • At least one OAuth app in your tenant. for testing (any third-party app with Microsoft 365 permissions)
๐Ÿ’ก Pro Tip: App Governance data collection takes 24–48 hours to populate fully after enablement. Start this lab by enabling the feature, then return the next day to explore the dashboard with real data.

Step 1 ยท Enable App Governance

App Governance is a feature within Microsoft Defender for Cloud Apps. You must enable it to begin monitoring OAuth apps in your tenant.

Portal Instructions

  1. Navigate to Microsoft Defender portal > Cloud apps > App governance
  2. If this is your first time, click Enable App Governance
  3. Accept the terms and wait for the feature to initialize (can take up to 10 minutes)
  4. Once enabled, verify you see the App Governance dashboard with app counts
  5. Navigate to Settings > Cloud apps > App governance to review configuration options

Verify with PowerShell

# WHAT: Connect to Microsoft Graph and enumerate all OAuth apps in the tenant
# WHY: Establishes baseline visibility into your app estate before exploring
#      App Governance dashboard data
# PERMISSIONS REQUIRED:
#   Application.Read.All - read all app registrations and service principals
#   Directory.Read.All   - read directory objects for publisher verification
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

# List all app registrations (apps registered IN this tenant)
# These are developer-created apps with client IDs, secrets, and redirect URIs
$apps = Get-MgApplication -All
Write-Host "Total app registrations: $($apps.Count)" -ForegroundColor Cyan

# List service principals (enterprise apps that have been consented to)
# servicePrincipalType eq 'Application' = third-party and first-party apps
# This is the count that matters for App Governance - these apps have actual permissions
$servicePrincipals = Get-MgServicePrincipal -All -Filter "servicePrincipalType eq 'Application'"
Write-Host "Enterprise apps: $($servicePrincipals.Count)" -ForegroundColor Cyan

# List OAuth2 permission grants (delegated permissions consented by users or admins)
# Each grant represents a user or admin consenting an app to access their data
# Scope field contains the actual permissions (e.g., "Mail.Read User.Read")
$grants = Get-MgOAuth2PermissionGrant -All
Write-Host "OAuth permission grants: $($grants.Count)" -ForegroundColor Yellow
๐Ÿ’ก Pro Tip: After enabling App Governance, wait at least 24 hours before evaluating the dashboard data. The initial data collection scans all existing OAuth apps, their permissions, data access history, and publisher details. First-day data may be incomplete.

Step 2 ยท Review the App Governance Dashboard

The App Governance dashboard provides a comprehensive overview of all OAuth apps in your tenant, their privilege levels, data usage patterns, and publisher verification status.

Dashboard Metrics

  1. Total apps. all OAuth apps with permissions to your Microsoft 365 tenant
  2. Highly privileged apps. apps with broad permissions (Mail.ReadWrite.All, Files.ReadWrite.All, etc.)
  3. Apps with high data usage. apps consuming or transferring significant volumes of data
  4. Unverified publishers. apps from publishers who haven’t completed Microsoft’s verification process
  5. Apps with alerts. apps that triggered threat or compliance alerts
  6. App trends. new apps added, apps disabled, permission changes over time

Filter and Explore

  1. Navigate to Cloud apps > App governance > Apps
  2. Filter by Privilege level: High. focus on apps with the most dangerous permissions
  3. Filter by Publisher verification: Unverified. flag apps from unknown sources
  4. Sort by Data usage. identify apps consuming the most organizational data
  5. Click on any app to view its detailed profile: permissions, data access, users, and activity timeline
โš ๏ธ Important: An app with Mail.ReadWrite permission from an unverified publisher that has been inactive for 6 months is a dormant risk. Attackers can compromise the app’s credentials and silently use its existing permissions. Review and clean up inactive apps regularly.

Step 3 ยท Investigate OAuth App Permissions

Review apps by their permission levels to identify overprivileged applications. apps that have been granted far more access than they need to function.

Permission Risk Levels

  • High privilege. Mail.ReadWrite.All, Files.ReadWrite.All, Directory.ReadWrite.All, User.ReadWrite.All
  • Medium privilege. Mail.Read, Calendars.ReadWrite, Sites.Read.All
  • Low privilege. User.Read, openid, profile, email

Graph API: List Overprivileged Apps

# WHAT: Identify all OAuth apps with high-risk delegated permissions
# WHY: Overprivileged apps are the #1 risk in OAuth security. An app with
#      Mail.ReadWrite.All can read/modify EVERY mailbox in the org.
#      This script finds apps whose permissions exceed their business need.
# PERMISSIONS REQUIRED: Application.Read.All, Directory.Read.All
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

# Define high-risk Microsoft Graph permission scopes
# These permissions grant broad access to organizational data:
#   Mail.ReadWrite / Mail.ReadWrite.All - read and modify email (exfiltration risk)
#   Files.ReadWrite.All   - read/write ALL files in SharePoint/OneDrive
#   Directory.ReadWrite.All - modify directory objects (privilege escalation risk)
#   User.ReadWrite.All    - modify all user accounts
#   Sites.ReadWrite.All   - full access to all SharePoint sites
#   MailboxSettings.ReadWrite - modify mailbox settings (forwarding rule creation)
$highRiskPermissions = @(
    "Mail.ReadWrite",
    "Mail.ReadWrite.All",
    "Files.ReadWrite.All",
    "Directory.ReadWrite.All",
    "User.ReadWrite.All",
    "Sites.ReadWrite.All",
    "MailboxSettings.ReadWrite"
)

# Get all service principals (enterprise apps with consent grants)
$servicePrincipals = Get-MgServicePrincipal -All -Filter "servicePrincipalType eq 'Application'"

foreach ($sp in $servicePrincipals) {
    # Get delegated permission grants (user-consented or admin-consented scopes)
    # These are permissions acting on behalf of a signed-in user
    $grants = Get-MgServicePrincipalOAuth2PermissionGrant -ServicePrincipalId $sp.Id -All
    $grantedScopes = ($grants | ForEach-Object { $_.Scope -split " " }) | Sort-Object -Unique

    # Check if any granted scopes match our high-risk list
    $riskyScopes = $grantedScopes | Where-Object { $_ -in $highRiskPermissions }

    if ($riskyScopes.Count -gt 0) {
        Write-Host "`n[HIGH RISK] $($sp.DisplayName)" -ForegroundColor Red
        Write-Host "  App ID: $($sp.AppId)"
        # PublisherName - the organization that published the app
        Write-Host "  Publisher: $($sp.PublisherName)"
        # VerifiedPublisher - Microsoft's publisher verification program
        # Apps from unverified publishers with high permissions = highest risk
        Write-Host "  Verified: $($sp.VerifiedPublisher.DisplayName -ne $null)"
        Write-Host "  Risky Permissions: $($riskyScopes -join ', ')" -ForegroundColor Yellow
    }
}

# Also check APPLICATION permissions (app-only / daemon - no user context)
# CRITICAL: App permissions act WITHOUT a user, accessing ALL users' data
# e.g., Mail.ReadWrite.All as app permission = can read EVERY mailbox silently
$appRoleAssignments = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All
foreach ($role in $appRoleAssignments) {
    Write-Host "  App Role: $($role.AppRoleId) -> $($role.ResourceDisplayName)"
}
๐Ÿ’ก Pro Tip: Pay special attention to application permissions (app-only) vs delegated permissions. Application permissions grant the app access to all users’ data without user interaction. e.g., Mail.ReadWrite.All as an application permission lets the app read every mailbox in the organization.

Step 4 ยท Review App Data Access Patterns

App Governance tracks which Microsoft 365 services each app accesses (Exchange, SharePoint, OneDrive, Teams), how much data it reads or writes, and whether patterns are normal or anomalous.

Portal Instructions

  1. Navigate to Cloud apps > App governance > Apps
  2. Click on an app to open its detail page
  3. Review the Data usage tab:
    • Data accessed. total volume read from Microsoft 365 services
    • Services accessed. which M365 workloads the app interacts with
    • Users affected. how many user accounts the app accesses
    • Activity trend. daily data access volume over time
  4. Look for anomalies: sudden spikes in data volume, access at unusual hours, or access to services unrelated to the app’s purpose

Identify Anomalous Data Access

# Query Microsoft Graph audit logs for app activity
Connect-MgGraph -Scopes "AuditLog.Read.All"

# Get recent sign-in activity for service principals (apps)
$appSignIns = Get-MgAuditLogSignIn -Filter "signInEventTypes/any(t: t eq 'servicePrincipal')" `
    -Top 100 -OrderBy "createdDateTime desc"

$appSignIns | Select-Object AppDisplayName, ResourceDisplayName, 
    CreatedDateTime, IPAddress, Status | Format-Table

# Look for apps accessing Graph API at unusual hours
$appSignIns | Where-Object {
    $hour = ([datetime]$_.CreatedDateTime).Hour
    $hour -lt 6 -or $hour -gt 22  # Outside business hours
} | Group-Object AppDisplayName | Select-Object Name, Count | Sort-Object Count -Descending

# Check for apps with high-frequency API calls
$appSignIns | Group-Object AppDisplayName | 
    Select-Object Name, Count | 
    Sort-Object Count -Descending | 
    Format-Table
โš ๏ธ Important: A project management app that suddenly starts downloading gigabytes of SharePoint data at 3 AM is a red flag. Legitimate apps have predictable data access patterns. Any sudden change in volume, timing, or target service warrants investigation.

Step 5 ยท Create App Compliance Policy

App policies define governance rules for OAuth apps in your tenant. Create compliance policies that alert on or automatically block apps that violate your organization’s security requirements.

Policy 1: Block Unverified Publishers with High Privileges

  1. Navigate to Cloud apps > App governance > Policies
  2. Click Create policy
  3. Name: Block unverified high-privilege apps
  4. Conditions:
    • Publisher verification status: Unverified
    • Permission level: High
  5. Action: Disable app (or Alert only initially)
  6. Severity: High
  7. Click Create

Policy 2: Alert on Inactive High-Privilege Apps

  1. Name: Alert on inactive privileged apps
  2. Conditions:
    • Permission level: High
    • Last used: More than 90 days ago
  3. Action: Generate alert
  4. Rationale: Inactive apps with high permissions are dormant risks. if compromised, they provide silent access

PowerShell: Enforce App Policies

# Disable apps from unverified publishers with high-risk permissions
Connect-MgGraph -Scopes "Application.ReadWrite.All"

$servicePrincipals = Get-MgServicePrincipal -All -Filter "servicePrincipalType eq 'Application'"

foreach ($sp in $servicePrincipals) {
    # Check if publisher is unverified and app has high-risk grants
    if ($sp.VerifiedPublisher.DisplayName -eq $null) {
        $grants = Get-MgServicePrincipalOAuth2PermissionGrant -ServicePrincipalId $sp.Id -All
        $scopes = ($grants | ForEach-Object { $_.Scope -split " " }) | Sort-Object -Unique
        $hasHighRisk = $scopes | Where-Object { $_ -match "ReadWrite\.All|Mail\.ReadWrite" }

        if ($hasHighRisk) {
            Write-Host "[ACTION] Disabling: $($sp.DisplayName)" -ForegroundColor Red
            Update-MgServicePrincipal -ServicePrincipalId $sp.Id `
                -AccountEnabled:$false
        }
    }
}

# List all disabled apps for audit
Get-MgServicePrincipal -All -Filter "accountEnabled eq false" | 
    Select-Object DisplayName, AppId, PublisherName | Format-Table
๐Ÿ’ก Pro Tip: Start with Alert only policies for the first 2 weeks. Review the alerts to identify false positives (legitimate apps that happen to be unverified). Whitelist those apps, then switch the policy to Disable app mode for enforcement.

Step 6 ยท Create Threat Detection Policy

Threat detection policies alert you to suspicious app behavior that may indicate a compromised app or malicious OAuth attack.

Policy 1: Anomalous Data Access Spike

  1. Navigate to Cloud apps > App governance > Policies
  2. Click Create policy > Threat detection
  3. Name: Anomalous app data access spike
  4. Conditions:
    • Data access volume: Significant increase compared to baseline
    • Time period: Last 24 hours
  5. Action: Generate alert
  6. Severity: High

Policy 2: Suspicious OAuth Consent Patterns

  1. Name: Suspicious consent grant pattern
  2. Conditions:
    • New app registration with: High-privilege permissions
    • Publisher: Unverified
    • Consent granted by: Multiple users in short timeframe
  3. Action: Generate alert + disable app
  4. Rationale: Illicit consent grant attacks often involve a phishing campaign that tricks multiple users into consenting to a malicious app simultaneously

Policy 3: App Credential Changes

  1. Name: Alert on app credential modification
  2. Conditions: New credential added to existing app (new certificate or client secret)
  3. Action: Generate alert
  4. Rationale: Adding a new credential to a legitimate app is a common persistence technique. attackers add their own secret to maintain access
โš ๏ธ Important: Illicit consent grant is one of the most effective attacks against Microsoft 365 tenants. A user clicks a phishing link, consents to a malicious app, and the attacker gains API-level access to their mailbox and files. This persists through password changes and MFA resets.

Step 7 ยท Investigate an App Governance Alert

When App Governance generates an alert, follow a structured investigation workflow to determine if the app is malicious, compromised, or a false positive.

Alert Triage Workflow

  1. Review the alert. navigate to Cloud apps > App governance > Alerts
  2. Check the app profile:
    • Publisher name and verification status
    • When the app was registered
    • Who consented to the app
    • What permissions it holds
  3. Review data access timeline. check for volume spikes or unusual target services
  4. Check consent history. was consent granted via phishing, admin consent, or user consent?
  5. Cross-reference with Entra ID sign-in logs. check for risky sign-ins from the consenting user
  6. Verify with the app owner. contact the team that requested the app to confirm legitimacy
  7. Decide: contain, monitor, or dismiss

Investigation Script

# Investigate a specific app by App ID
$appId = "YOUR_SUSPICIOUS_APP_ID"

Connect-MgGraph -Scopes "Application.Read.All","AuditLog.Read.All","Directory.Read.All"

# Get app registration details
$app = Get-MgApplication -Filter "appId eq '$appId'"
Write-Host "App Name: $($app.DisplayName)" -ForegroundColor Cyan
Write-Host "Created: $($app.CreatedDateTime)"
Write-Host "Sign-in Audience: $($app.SignInAudience)"

# Get service principal
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'"
Write-Host "Publisher: $($sp.PublisherName)"
Write-Host "Verified Publisher: $($sp.VerifiedPublisher.DisplayName)"
Write-Host "Account Enabled: $($sp.AccountEnabled)"

# List all permission grants
$grants = Get-MgServicePrincipalOAuth2PermissionGrant -ServicePrincipalId $sp.Id -All
Write-Host "`n--- Delegated Permissions ---" -ForegroundColor Yellow
foreach ($grant in $grants) {
    $resource = Get-MgServicePrincipal -ServicePrincipalId $grant.ResourceId
    Write-Host "  Resource: $($resource.DisplayName)"
    Write-Host "  Scopes: $($grant.Scope)"
    Write-Host "  Consent Type: $($grant.ConsentType)"
    Write-Host "  Granted To: $($grant.PrincipalId)"
}

# List app role assignments (application permissions)
$appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All
Write-Host "`n--- Application Permissions ---" -ForegroundColor Yellow
foreach ($role in $appRoles) {
    Write-Host "  Resource: $($role.ResourceDisplayName)"
    Write-Host "  Role ID: $($role.AppRoleId)"
    Write-Host "  Created: $($role.CreatedDateTime)"
}

# Check for recently added credentials (persistence indicator)
Write-Host "`n--- Credentials (Secrets & Certificates) ---" -ForegroundColor Yellow
foreach ($cred in $app.PasswordCredentials) {
    Write-Host "  Secret: $($cred.DisplayName) | Created: $($cred.StartDateTime) | Expires: $($cred.EndDateTime)"
}
foreach ($cert in $app.KeyCredentials) {
    Write-Host "  Certificate: $($cert.DisplayName) | Created: $($cert.StartDateTime) | Expires: $($cert.EndDateTime)"
}
๐Ÿ’ก Pro Tip: A key investigation signal is the consent history. If 10 users consented to the same app within an hour and the app was registered the same day, that’s a strong indicator of an illicit consent grant phishing campaign. Cross-reference with email logs to find the phishing message.

Step 8 ยท Remediate Risky Apps

When you confirm an app is malicious, compromised, or overprivileged beyond repair, take decisive remediation actions: disable the app, revoke all consent grants, and block future consent.

Remediation Actions

  1. Disable the service principal. immediately stops all API access
  2. Revoke all OAuth permission grants. removes delegated permissions
  3. Remove app role assignments. removes application permissions
  4. Delete the service principal. permanently removes the app from the tenant (for malicious apps)
  5. Review affected users. check if the app exfiltrated data from specific mailboxes

PowerShell: Full Remediation

# Full remediation workflow for a confirmed malicious app
$appId = "MALICIOUS_APP_ID"

Connect-MgGraph -Scopes "Application.ReadWrite.All","DelegatedPermissionGrant.ReadWrite.All",
    "AppRoleAssignment.ReadWrite.All"

# Step 1: Get the service principal
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'"
Write-Host "Remediating: $($sp.DisplayName) ($appId)" -ForegroundColor Red

# Step 2: Disable the app immediately
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AccountEnabled:$false
Write-Host "[DONE] App disabled" -ForegroundColor Green

# Step 3: Revoke all delegated permission grants
$grants = Get-MgServicePrincipalOAuth2PermissionGrant -ServicePrincipalId $sp.Id -All
foreach ($grant in $grants) {
    Remove-MgOAuth2PermissionGrant -OAuth2PermissionGrantId $grant.Id
    Write-Host "[DONE] Revoked grant: $($grant.Scope)" -ForegroundColor Green
}

# Step 4: Remove all application permission (app role) assignments
$appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id -All
foreach ($role in $appRoles) {
    Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id `
        -AppRoleAssignmentId $role.Id
    Write-Host "[DONE] Removed app role: $($role.ResourceDisplayName)" -ForegroundColor Green
}

# Step 5: (Optional) Delete the service principal entirely
# Remove-MgServicePrincipal -ServicePrincipalId $sp.Id
# Write-Host "[DONE] Service principal deleted" -ForegroundColor Green

Write-Host "`nRemediation complete. App is disabled and all permissions revoked." -ForegroundColor Cyan
โš ๏ธ Important: Before deleting a service principal, verify this isn’t a legitimate business app. Deletion is permanent. For suspected apps, disable first, investigate for 48 hours, then delete if confirmed malicious. Document all actions in your incident ticket.

Step 9 ยท Configure App Consent Policies

Prevent future OAuth app risks by controlling how users and admins consent to apps in your Entra ID tenant. Consent policies are the upstream control that stops risky apps before they get permissions.

Configure in Entra ID

  1. Navigate to Entra ID > Enterprise applications > Consent and permissions > User consent settings
  2. Set user consent policy:
    • Do not allow user consent (most restrictive. all consent requires admin approval)
    • Allow user consent for apps from verified publishers, for selected permissions (recommended)
    • Allow user consent for all apps (least restrictive. not recommended)
  3. Navigate to Admin consent requests > enable Users can request admin consent
  4. Set reviewers: Security team or IT admins who will approve/deny app requests
  5. Set expiration: admin consent requests expire after a defined period if not reviewed

Configure Publisher Verification Requirements

# Configure consent policy via Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Get current authorization policy
$policy = Get-MgPolicyAuthorizationPolicy

# Block user consent entirely (require admin consent for all apps)
Update-MgPolicyAuthorizationPolicy `
    -DefaultUserRolePermissions @{
        PermissionGrantPoliciesAssigned = @()  # Empty = no user consent allowed
    }
Write-Host "User consent disabled. All apps require admin approval." -ForegroundColor Green

# Alternative: Allow consent only for verified publishers with low-risk permissions
Update-MgPolicyAuthorizationPolicy `
    -DefaultUserRolePermissions @{
        PermissionGrantPoliciesAssigned = @(
            "managePermissionGrantsForSelf.microsoft-user-default-low"
        )
    }
Write-Host "User consent limited to verified publishers with low-risk permissions." -ForegroundColor Cyan

# Enable admin consent workflow
# Navigate to: Entra ID > Enterprise apps > Admin consent requests > Settings
# Enable: Users can request admin consent to apps they are unable to consent to
# Add reviewers: your security team distribution group
๐Ÿ’ก Pro Tip: The recommended setting for most enterprises is “Allow user consent for apps from verified publishers, for selected permissions.” This balances productivity (users can adopt low-risk verified apps) with security (high-privilege and unverified apps require admin review).

Step 10 ยท Clean Up & Next Steps

Review what you’ve configured and plan ongoing app governance operations.

What You Accomplished

  1. App Governance. Enabled and configured data collection for your tenant
  2. Dashboard. Reviewed app inventory, privilege levels, and publisher verification
  3. Permissions. Investigated overprivileged apps and identified high-risk grants
  4. Data Access. Analyzed data usage patterns and detected anomalies
  5. Compliance Policies. Created policies to govern unverified and inactive apps
  6. Threat Detection. Built policies for anomalous behavior and illicit consent
  7. Alerts. Practiced the alert investigation and triage workflow
  8. Remediation. Disabled apps, revoked consent, and removed permissions
  9. Consent Policies. Hardened user consent settings in Entra ID

Ongoing App Governance Cadence

# Recommended app governance operations cadence
# Daily:   Review App Governance alerts, triage new consent requests
# Weekly:  Review newly registered apps, check for unverified publishers
# Monthly: Audit inactive high-privilege apps, review data access trends
# Quarterly: Full app inventory review, consent policy assessment

# Quick daily audit: list new apps registered in last 24 hours
Connect-MgGraph -Scopes "Application.Read.All"

$yesterday = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddTHH:mm:ssZ")
$newApps = Get-MgApplication -Filter "createdDateTime ge $yesterday"

Write-Host "New app registrations in last 24h: $($newApps.Count)" -ForegroundColor Cyan
$newApps | Select-Object DisplayName, AppId, CreatedDateTime, 
    @{N="SignInAudience";E={$_.SignInAudience}} | Format-Table

# List apps with expiring secrets (credential rotation needed)
$apps = Get-MgApplication -All
$expiringApps = $apps | Where-Object {
    $_.PasswordCredentials | Where-Object { 
        $_.EndDateTime -lt (Get-Date).AddDays(30) -and $_.EndDateTime -gt (Get-Date) 
    }
}
Write-Host "Apps with secrets expiring in 30 days: $($expiringApps.Count)" -ForegroundColor Yellow

Next Steps

  • Next Lab: Configure App Governance Threat Detection
  • Explore Defender for Cloud Apps Lab 01 for broader CASB capabilities
  • Configure Microsoft Sentinel to ingest App Governance alerts for cross-signal correlation
  • Build Conditional Access policies that block sign-ins from risky apps
  • Integrate App Governance alerts with your SOAR platform for automated response
  • Create a Security Copilot prompt book for OAuth app investigation
  • Establish an app approval board that reviews high-privilege app requests before admin consent is granted
๐Ÿ’ก Pro Tip: Track four key metrics monthly: total OAuth apps with high privileges (target: decreasing), unverified publisher percentage (target: <10%), mean time to investigate app alerts (target: <4 hours), and apps disabled/removed per quarter. These metrics demonstrate effective app governance to auditors and compliance teams.

๐Ÿ“š Documentation Resources

ResourceDescription
App Governance overviewProduct overview and feature documentation
Get started with App GovernanceEnable and configure App Governance
App Governance policiesCreate compliance and threat detection policies
Detect and remediate app threatsInvestigate and respond to app-based threats
Configure user consent settingsControl how users consent to OAuth apps
Admin consent workflowSet up admin approval for app consent requests
Publisher verificationUnderstand app publisher verification in Entra ID
App consent grant investigation playbookMicrosoft incident response guidance for illicit consent attacks
← All Labs Next Lab →