# User consent settings are restricted
Without restricted user consent settings, threat actors can exploit permissive application consent configurations to gain unauthorized access to sensitive…
Source: https://maester.dev/docs/tests/ZTA.21776
:::note[Maester checks this too]
[EIDSCA.AP08](/docs/tests/EIDSCA.AP08) (Default Authorization Settings - User consent assignments match the restricted or Microsoft recommended baseline.) checks the same setting. Running both reports it twice.
:::
## Overview
Without restricted user consent settings, threat actors can exploit permissive application consent configurations to gain unauthorized access to sensitive organizational data. When user consent is unrestricted, attackers can:
- Use social engineering and illicit consent grant attacks to trick users into approving malicious applications.
- Impersonate legitimate services to request broad permissions, such as access to email, files, calendars, and other critical business data.
- Obtain legitimate OAuth tokens that bypass perimeter security controls, making access appear normal to security monitoring systems.
- Establish persistent access to organizational resources, conduct reconnaissance across Microsoft 365 services, move laterally through connected systems, and potentially escalate privileges.
Unrestricted user consent also limits an organization's ability to enforce centralized governance over application access, making it difficult to maintain visibility into which non-Microsoft applications have access to sensitive data. This gap creates compliance risks where unauthorized applications might violate data protection regulations or organizational security policies.
## Remediation
- [Configure restricted user consent settings](https://learn.microsoft.com/entra/identity/enterprise-apps/configure-user-consent?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) to prevent illicit consent grants by disabling user consent or limiting it to verified publishers with low-risk permissions only.
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | High |
| Effort to fix | Medium |
| Impact on users | High |
| Pillar | Identity |
| Category | Application management |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | App consent and permissions |
| Area | Applications and workload identities |
| ATT&CK | [T1528](/docs/tests?mitre=T1528) Steal Application Access Token, [T1566.002](/docs/tests?mitre=T1566.002) Spearphishing Link |
| Licence | Free |
| Tenant | Workforce, External |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.