Application Administrator Privilege Escalation in Entra ID: Why It Is a Tier-0 Role
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Microsoft's documentation categorizes Application Administrator as a role that cannot modify security-sensitive settings or other administrators' accounts. Multiple independent security researchers have documented that this framing understates the actual privilege surface. The role's ability to add credentials to service principal objects, modify federated identity configurations, and interact with first-party Microsoft application service principals creates several practical paths to Global Administrator-equivalent access. This is not theoretical -- Datadog published a concrete escalation chain involving Exchange Online that was validated by Microsoft MSRC and patched in August 2025. Understanding these paths is necessary to justify the Tier-0 treatment of this role.
Escalation Path 1: Service Principal Credential Addition
Application Administrator can add credentials (client secrets and certificates) to any service principal in the tenant via the Graph API (POST /servicePrincipals/{id}/addPassword). If the target service principal has a high-privilege role assignment -- for example, a service principal with Global Administrator, Exchange Administrator, or Privileged Authentication Administrator roles -- adding a credential to that SP and authenticating as it provides the escalating user with those role permissions. Attack flow: identify a high-privilege SP in the tenant via Get-MgServicePrincipalAppRoleAssignment. Add a client secret to that SP. Authenticate as the SP using client credentials. Use the resulting token to perform privileged operations. This escalation path requires that a high-privilege SP exists in the tenant. In most enterprise tenants, automation accounts and integration SPs with broad permissions exist and are assigned high-privilege roles. The Application Administrator's ability to add credentials to these SPs is the escalation mechanism.
Escalation Path 2: The Exchange Online SAML Federation Path
Datadog Security Labs published this path in January 2025 (MSRC case, fixed August 2025). The path: an Application Administrator creates a new federated domain on an Exchange Online service principal object. Exchange Online (app ID 00000002-0000-0ff1-ce00-000000000000) has a ServicePrincipal object in the tenant. Using the Application Administrator role, an attacker adds a SAML identity provider configuration to this SP. The attacker then issues a SAML token from their controlled IdP claiming to be an Exchange Online admin. Exchange Online validates the SAML token and grants the attacker global admin-level access to Exchange. Microsoft deployed a partial fix (AADSTS7000121 error) in August 2025 blocking service principal credential modifications on specific Exchange Online app objects. However, the broader class of SAML manipulation via Application Administrator for other first-party applications may still have unexplored paths. Treat this as a class of vulnerability, not a single fixed issue.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Escalation Path 3: Admin Consent Grant Manipulation
Application Administrator can grant admin consent for OAuth permission requests on behalf of the organization. This means an Application Administrator can approve a request from any application (including a newly registered one under their control) for high-privilege Microsoft Graph permissions: Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Policy.ReadWrite.ConditionalAccess, and others. With a self-registered application granted Directory.ReadWrite.All via admin consent, the Application Administrator (or an attacker who has compromised an Application Administrator account) can: create new Global Admin accounts, modify role assignments, change Conditional Access policies, read the full directory. This escalation does not require targeting an existing SP -- the attacker creates their own application with the permissions they want and self-approves the consent. Detection: Entra ID audit log events for admin consent grants (Operation: Consent to application) from Application Administrator accounts, especially for high-privilege Graph permissions.
Detect Application Administrator Abuse
Key detection events in the Entra ID audit log: 'Add service principal credentials' by an Application Administrator (Event: Update service principal, modified property: PasswordCredentials). Alert on every SP credential addition by any account with Application Administrator role -- this is low-volume and should be zero for standard operations outside of documented automation. 'Consent to application' events with high-privilege permissions (DirectoryRead.Write.All, RoleManagement.ReadWrite.Directory) granted by an Application Administrator. These should be zero in steady state outside of deliberate application onboarding projects. 'Create application' events by Application Administrator accounts outside of approved change windows. 'Update service principal' events modifying federated identity credentials or service principal trust settings. In Sentinel: AuditLogs | where OperationName in ('Add service principal credentials', 'Consent to application') | where InitiatedBy.user has 'ApplicationAdmin' role | project TimeGenerated, InitiatedBy, TargetResources, ResultDescription. Alert on every match -- none of these are routine operations that should be generating daily events.
Harden Application Administrator to Tier-0
Based on the documented escalation paths: move all Application Administrator assignments to PIM eligible assignments with phishing-resistant MFA and approval requirements (same as Global Administrator). Do not allow permanent Application Administrator assignments except for break-glass accounts. Reduce the Application Administrator population: identify who currently holds this role and whether each person needs it. Application ownership rights (the ability to manage a specific app registration) can be granted at the object level without granting the tenant-wide Application Administrator role. Use App Registration owners for day-to-day app management -- this limits scope to specific applications rather than all applications in the tenant. Monitor Service Principal credential additions: even after PIM enrollment, alert on every credential addition to any SP via the audit log event. Quarterly: audit all SPs with credentials and role assignments (as covered in the SP hidden credentials guide) -- this catches any credentials added during legitimate PIM activations that were not subsequently removed.
The bottom line
Application Administrator is a published Tier-0-equivalent role with documented escalation paths to Global Administrator via service principal credential manipulation, SAML configuration abuse, and admin consent grants. Treat it exactly as you treat Global Administrator: PIM eligible only, phishing-resistant MFA, approval requirement, and quarterly access review. Monitor every credential addition and consent grant initiated by Application Administrator accounts as a high-priority security alert.
Frequently asked questions
Does Cloud Application Administrator have the same escalation risk as Application Administrator?
Cloud Application Administrator has almost identical permissions to Application Administrator but cannot manage on-premises application proxy configurations. From a cloud escalation standpoint, the two roles have equivalent privilege surfaces for the paths described in this guide. Both can add service principal credentials, grant admin consent, and interact with first-party Microsoft application objects. Both should be treated as Tier-0 and managed under PIM with the same strictness as Application Administrator.
Was the Datadog escalation path fully patched by Microsoft?
Microsoft deployed the AADSTS7000121 error in August 2025 that specifically blocks service principal credential modifications on the Exchange Online application object. This patches the specific path Datadog documented. However, Datadog and Semperis both note that the root cause (Application Administrator's ability to modify service principal trust configurations) is architectural and affects multiple first-party apps, not just Exchange Online. The broader class of escalation via SAML federation configuration on first-party SPs may have unexplored paths. Treating Application Administrator as Tier-0 is the correct posture regardless of whether every specific path is patched.
Can I grant application management rights without using the Application Administrator role?
Yes. Individual App Registration owners can manage their specific application registration (add credentials, configure permissions, modify the app manifest) without having the tenant-wide Application Administrator role. Assign ownership via: in the App Registration > Owners blade, add the developer or team as an owner. This scopes their management rights to that specific application only. For enterprise applications that are not custom registrations (first-party Microsoft apps, third-party SaaS), there is no equivalent scoped ownership -- management requires either Application Administrator or Global Admin. For these cases, use PIM eligible assignments with Conditional Access controls rather than permanent role grants.
How do I know which SPs in my tenant have admin consent for high-privilege Graph permissions?
Get-MgServicePrincipalOauth2PermissionGrant -All | Where-Object { $_.Scope -match 'Directory.ReadWrite|RoleManagement.ReadWrite|Policy.ReadWrite' } | Select-Object ClientId, Scope, PrincipalId, ConsentType. A ConsentType of 'AllPrincipals' indicates organization-wide admin consent (not per-user consent). The ClientId is the service principal AppId that has been granted the permission. Review each result and determine whether the high-privilege consent is justified for the application's stated purpose.
How does the Application Administrator role relate to the concept of a rogue OAuth app attack?
A rogue OAuth app attack (illicit consent grant) is a social engineering attack where a malicious app tricks a user into granting it OAuth permissions. The Application Administrator role is not required for this attack -- any user who consents to a third-party app grants that app their delegated permissions. Application Administrator is required for the more dangerous attack path: adding credentials to existing high-privilege service principals (not creating new consent grants). The two attacks are related but distinct. To block the illicit consent grant attack: disable user consent for third-party apps and require admin approval. To defend against the Application Administrator escalation path: move Application Administrator to PIM, audit credential additions as described in this guide, and apply Conditional Access for Workload Identities to limit where service principal credentials can authenticate from.
How do you audit and continuously monitor for new credentials added to high-privilege service principals in your Entra ID tenant?
Continuous monitoring requires both retroactive auditing and real-time alerting. For retroactive auditing: use the Microsoft Graph API to retrieve all service principals (GET /servicePrincipals) and examine the keyCredentials and passwordCredentials arrays for each, comparing startDateTime against a known-good baseline. PowerShell: Get-MgServicePrincipal -All | Where-Object {$_.AppRoles.Count -gt 0} | Select-Object DisplayName, AppId, @{Name='PasswordCreds';Expression={$_.PasswordCredentials}} | Where-Object {$_.PasswordCreds -ne $null}. For real-time alerting: Entra ID audit logs capture 'Add service principal credentials' and 'Update application -- Certificates and secrets management' events. In Microsoft Sentinel, create a scheduled analytics rule on AuditLogs where OperationName == 'Add service principal credentials' and join to a watchlist of high-privilege service principal AppIds (Global Admin-equivalent SPs, Microsoft Graph-privileged SPs). Alert threshold: any credential addition to a high-privilege SP regardless of source is a high-severity event -- legitimate credential rotation should happen through a managed DevOps pipeline with its own audit trail, not through the Entra portal interactively.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.