# Application admin rights are constrained to specific Private Access apps
An Application Administrator role scoped at the tenant level can manage every app registration and enterprise application.
Source: https://maester.dev/docs/tests/ZTA.25384
## Overview
An Application Administrator role scoped at the tenant level can manage every app registration and enterprise application. If a threat actor compromises an Application Administrator with tenant-wide scope, they can add credentials to any service principal, consent to malicious APIs, modify or create applications that enable data exfiltration, and disable or tamper with Private Access apps. Scoping the role to only required Private Access enterprise apps enforces least privilege and limits the blast radius.
If you don't scope Application Administrator assignments to specific apps:
- A compromised Application Administrator can manage every app registration and enterprise application in your tenant.
- Threat actors can add credentials to any service principal, enabling persistence and lateral movement.
- There's no blast radius containment; a single compromised identity can affect all applications.
## Remediation
- [Assign Application Administrator roles scoped to specific app registrations](https://learn.microsoft.com/entra/identity/role-based-access-control/custom-enterprise-app-permissions?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) instead of tenant-wide.
- [Assign Microsoft Entra roles](https://learn.microsoft.com/entra/identity/role-based-access-control/manage-roles-portal?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci) with the least privilege necessary to perform required tasks.
- [Use Privileged Identity Management to manage just-in-time role activation](https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci).
- [Manage Microsoft Entra role assignments in the admin center](https://learn.microsoft.com/entra/identity/role-based-access-control/manage-roles-portal?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci).
## 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 | Low |
| Impact on users | Low |
| Pillar | Network |
| Category | Role management |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Roles and administrators |
| Area | Privileged access |
| ATT&CK | [T1098.001](/docs/tests?mitre=T1098.001) Additional Cloud Credentials, [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts |
| Licence | Entra_Premium_Private_Access, Entra_Premium_Internet_Access, P1 |
| Tenant | Workforce |
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`.