EIDAPP-020: Group Owner Consent to Applications Blocked
- Platform
- Entra ID / M365
- Category
- Consent
- Severity
- Medium
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
When group-specific (group owner) consent is enabled, owners of Microsoft 365 groups and Teams can authorize applications to access data owned by their group without administrator review. Attackers exploit this through illicit consent grant phishing aimed at group and team owners to obtain persistent, scoped access to organizational data. SCuBA requires that group owners not be allowed to consent to applications, forcing all such consent through the admin approval workflow. In Entra ID this is governed by the EnableGroupSpecificConsent setting in the directory (group) settings; it must be false. Note that Microsoft has deprecated the admin-center toggle for this control, but the underlying directory setting remains the authoritative signal.
Recommended value
EnableGroupSpecificConsent set to false in the directory (group) settings — group owners cannot consent to applications
Remediation
Ensure group owners cannot consent to applications, satisfying SCuBA MS.AAD.5.4. Set the directory (group) setting 'EnableGroupSpecificConsent' to false (Group.Unified settings template). Route all application consent for group-owned data through the admin consent workflow so that a reviewer approves access. Where the legacy admin-center toggle is no longer present, confirm the directory setting value directly via the group settings configuration.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| no-data | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6, AC-3
- CIS M365 Benchmark
- 5.1.6.1
- MITRE ATT&CK
- T1528