Back to App

APP-08: Restrict User Application Consent

Overview

User consent allows individuals to grant applications access to organizational data without administrator approval. While convenient, unrestricted consent is a common attack vector for phishing and data exfiltration. This guide walks you through implementing appropriate consent restrictions while maintaining user productivity.

TrueConfig: TrueConfig can configure user consent to "Do not allow user consent" in Entra ID with one click, enforcing the strictest setting automatically.

Prerequisites

Required Roles

  • Global Administrator - Required for consent setting changes
  • Cloud Application Administrator - Can manage consent settings
  • Application Administrator - Can manage consent settings

Required Licenses

  • Microsoft Entra ID (any tier)

Time Estimate

  • Initial Configuration: 20-30 minutes
  • Policy Development: 1-2 hours
  • User Communication: 30 minutes

Step-by-Step Instructions

Step 1: Assess Current Consent Posture

Check Existing Settings

  1. Navigate to Microsoft Entra admin center (https://entra.microsoft.com)
  2. Go to Identity → Applications → Enterprise applications
  3. Click Consent and permissions → User consent settings
  4. Document current settings:
    • User consent for applications
    • Group owner consent for apps
    • Risk-based step-up consent

Audit Recent User Consents

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

# Get recent consent grants
$consents = Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Consent to application'" -Top 100

$consentReport = $consents | ForEach-Object {
    [PSCustomObject]@{
        DateTime = $_.ActivityDateTime
        User = $_.InitiatedBy.User.UserPrincipalName
        AppName = ($_.TargetResources | Where-Object Type -eq "ServicePrincipal").DisplayName
        Permissions = ($_.AdditionalDetails | Where-Object Key -eq "ConsentAction.Permissions").Value
        ConsentType = ($_.AdditionalDetails | Where-Object Key -eq "ConsentType").Value
    }
}

$consentReport | Format-Table
$consentReport | Export-Csv -Path "RecentConsents.csv" -NoTypeInformation

Step 2: Choose Your Consent Strategy

Select the appropriate level based on your security requirements:

StrategyUser ConsentSecurity LevelProductivity Impact
Block AllDisabledHighestUsers need IT for every app
Verified Publishers OnlyVerified + Low RiskHighBalance of security and productivity
Verified + Specific PermissionsVerified + SelectedRecommendedFine-grained control
Allow AllEnabledLowestMaximum flexibility, highest risk

Recommended: Verified Publishers with Selected Permissions

This approach allows users to consent to low-risk permissions from verified publishers while requiring admin approval for sensitive access.

Step 3: Configure User Consent Settings

Option A: Block All User Consent (High Security)

  1. Navigate to Consent and permissions → User consent settings
  2. Under User consent for applications:
    • Select Do not allow user consent
  3. Click Save

Note: This requires enabling the admin consent workflow (Step 5) to avoid blocking all application access.

Option B: Allow Verified Publishers with Low-Risk Permissions (Recommended)

  1. Navigate to Consent and permissions → User consent settings
  2. Under User consent for applications:
    • Select Allow user consent for apps from verified publishers, for selected permissions
  3. Click Save

Option C: Allow Verified Publishers for All Permissions

  1. Navigate to Consent and permissions → User consent settings
  2. Under User consent for applications:
    • Select Allow user consent for apps from verified publishers
  3. Click Save

Step 4: Define Low-Risk Permission Classifications

If you selected Option B, configure which permissions users can grant:

  1. Navigate to Consent and permissions → Permission classifications
  2. Click + Add permissions
  3. Select Microsoft Graph from the API dropdown
  4. Add these low-risk permissions to the "Low" classification:

Recommended Low-Risk Permissions

# OpenID Connect / Authentication
openid
profile
email
offline_access

# Basic User Data (Read-Only)
User.Read
User.ReadBasic.All

# Minimal Calendar Access
Calendars.Read

# Presence Information
Presence.Read

# File Access (User's Own)
Files.Read
  1. Click Add selected permissions
  2. Click Save

Permissions to EXCLUDE from Low-Risk

These should always require admin consent:

  • Mail.Read / Mail.ReadWrite - Access to email
  • Files.ReadWrite.All - Write access to all files
  • User.ReadWrite.All - Modify user data
  • Directory.ReadWrite.All - Directory modifications
  • Sites.ReadWrite.All - SharePoint modifications
  • Any .All scopes
  • Any application permissions

Step 5: Enable Admin Consent Workflow

Allow users to request access to applications that require admin approval:

  1. Navigate to Consent and permissions → Admin consent settings
  2. Set Users can request admin consent to apps they are unable to consent to to Yes
  3. Configure reviewers:
    • Click + Add users or + Add groups
    • Add designated consent reviewers (e.g., IT Security team)
  4. Configure notifications:
    • Selected users will receive email notifications for requests: Yes
    • Selected users will receive request expiration reminders: Yes
  5. Set Consent request expires after (days): 30
  6. Click Save

See APP-04: Configuring Admin Consent Workflow for detailed workflow configuration.

Step 6: Configure Group Owner Consent (Optional)

Control whether group owners can consent to apps accessing group data:

  1. Navigate to Consent and permissions → User consent settings
  2. Under Group owner consent for apps accessing data:
    • Do not allow group owner consent - Recommended for high security
    • Allow group owner consent for all group owners - If groups are self-managed
    • Allow group owner consent for selected group owners - Targeted permission
  3. Click Save

Step 7: Enable Risk-Based Step-Up Consent

Block risky consent attempts automatically:

  1. Navigate to Identity → Protection → Consent policies
  2. Verify Risk-based step-up consent is enabled
  3. This automatically blocks consent to:
    • Apps from unverified publishers requesting high-risk permissions
    • Apps exhibiting suspicious behavior
    • Apps flagged by Microsoft threat intelligence

Step 8: Block Specific Publishers or Applications

Block a Specific Application

  1. Navigate to Enterprise applications → All applications
  2. Find the application to block
  3. Go to Properties
  4. Set Enabled for users to sign-in to No
  5. Click Save

Block by Publisher Domain (PowerShell)

# Note: There's no direct "block publisher" feature, but you can:
# 1. Disable all apps from a specific publisher
# 2. Use Conditional Access to block sign-in

$publisherDomain = "suspicious-publisher.com"

$apps = Get-MgServicePrincipal -All | Where-Object { $_.PublisherName -like "*$publisherDomain*" }

foreach ($app in $apps) {
    Update-MgServicePrincipal -ServicePrincipalId $app.Id -AccountEnabled:$false
    Write-Host "Disabled: $($app.DisplayName)"
}

Step 9: Communicate Changes to Users

Email Template

Subject: Changes to Application Access Policy

Dear [User/Team],

To enhance the security of our Microsoft 365 environment, we are implementing
new controls on application access starting [Date].

What's Changing:
- You can continue to use approved applications without interruption
- For new applications, you may be prompted to request admin approval
- Applications from verified publishers with basic permissions will work as before

What You Need to Do:
- If you need a new application, submit a request through the approval workflow
- You'll receive a notification when your request is approved or denied
- Most requests are processed within 2-3 business days

How to Request Application Access:
1. When prompted, click "Request approval"
2. Provide a brief business justification
3. Your request will be reviewed by IT Security

Questions?
Contact the IT Help Desk at [contact info]

Thank you for your cooperation in keeping our environment secure.

IT Security Team

Step 10: Monitor and Review Consents

Set Up Consent Alerts

Create alerts for:

  • Admin consents granted
  • High-volume consent requests
  • Consents to previously unseen applications

Weekly Consent Review Report

# Generate weekly consent report

$startDate = (Get-Date).AddDays(-7).ToString("yyyy-MM-dd")
$filter = "activityDisplayName eq 'Consent to application' and activityDateTime ge $startDate"

$weeklyConsents = Get-MgAuditLogDirectoryAudit -Filter $filter -All

$summary = $weeklyConsents | Group-Object {
    ($_.TargetResources | Where-Object Type -eq "ServicePrincipal").DisplayName
} | Select-Object Name, Count | Sort-Object Count -Descending

Write-Host "Weekly Consent Summary"
Write-Host "====================="
$summary | Format-Table -AutoSize

Verification Checklist

After implementing consent restrictions:

  • User consent settings are configured appropriately
  • Low-risk permissions are classified
  • Admin consent workflow is enabled
  • Consent reviewers are assigned
  • Risk-based step-up consent is enabled
  • Group owner consent is configured
  • Known risky applications are blocked
  • Users have been notified of changes
  • Help desk is prepared for consent-related tickets
  • Monitoring is in place for consent events
  • Documentation is updated with consent policy

Troubleshooting

Issue: Users cannot access previously working applications

Cause: Consent restrictions may have blocked re-consent on token expiration.

Solution:

  1. Check if the application requires renewed consent
  2. Grant admin consent if appropriate:
    • Enterprise applications → Select app → Permissions → Grant admin consent
  3. Add the application to the pre-approved list if widely used

Issue: Too many consent requests overwhelming IT

Cause: Users are requesting access to many applications.

Solution:

  1. Identify frequently requested applications
  2. Pre-approve common business applications with admin consent
  3. Create a catalog of approved applications for users to reference
  4. Consider allowing more permissions in the "Low" classification

Issue: Verified publisher check is too restrictive

Cause: Legitimate vendors may not have completed publisher verification.

Solution:

  1. Contact the vendor to request they complete publisher verification
  2. Grant admin consent for specific trusted applications
  3. Document exceptions with business justification
  4. Consider adjusting to allow verified publishers for more permissions

Issue: Users confused about consent workflow

Cause: User communication may have been insufficient.

Solution:

  1. Resend communication about the new process
  2. Create FAQ document or knowledge base article
  3. Brief help desk on common questions
  4. Consider in-person or video training for key teams

Issue: Application requires permissions not in low-risk list

Cause: Application needs more access than user consent allows.

Solution:

  1. User should request admin consent via the workflow
  2. Review the permission request:
    • Is it appropriate for the application's function?
    • Can a less-privileged alternative permission work?
  3. If approved, grant admin consent
  4. Document the decision

Issue: OAuth consent phishing attack detected

Cause: Malicious application attempted to gain unauthorized access.

Solution:

  1. Identify affected users from audit logs
  2. Revoke consent for the malicious application: 
    $appId = "malicious-app-id"
$sp = Get-MgServicePrincipal -Filter "appId eq '$appId'"
Remove-MgServicePrincipal -ServicePrincipalId $sp.Id
  3. Review permissions granted by affected users
  4. Reset affected user passwords if credential compromise suspected
  5. Report the application to Microsoft

Issue: Consent settings not applying to specific users

Cause: User may be exempt due to admin role or PIM activation.

Solution:

  1. Users with Application Administrator or higher can always consent
  2. Check if user has any admin roles assigned
  3. PIM-activated roles may grant consent ability
  4. This is by design - admin roles include consent capability

Issue: Group consent is being abused

Cause: Group owners are consenting to applications that access all group data.

Solution:

  1. Restrict group owner consent settings
  2. Review recent group owner consents in audit logs
  3. Educate group owners on consent security
  4. Consider requiring admin consent for all group-level permissions

Related Resources

Last updated: January 2025