// 04.1 / Read
The Role
Danger Map
Global Administrator is not the only path to tenant compromise. Most attacker escalation chains run through roles that do not appear obviously dangerous in the Entra portal. Understanding the actual blast radius of each role is not optional for a defender.
The Core Misconception
The PRIVILEGED label is not applied consistently
Microsoft marks certain roles with a PRIVILEGED label in the Entra portal and documentation. In practice, roles that are effectively tenant takeover primitives are not always labeled this way. The Agent ID Administrator role, patched in April 2026, was documented as privileged but was not displayed as such in the Entra UI. Admins assigned it without the scrutiny they would apply to a Global Administrator assignment. The lesson is that the absence of a PRIVILEGED label is not a safety guarantee. Read what the role can actually do.
Role
What it actually enables
Threat Level
Global Administrator
Unrestricted access to the entire tenant. Can modify any setting, assign any role, access any data. Microsoft recommends fewer than 5 permanent assignments.
Tenant Takeover
Privileged Role Administrator
Can assign any Entra ID role including Global Administrator to any user or principal. Effectively equivalent to Global Administrator for privilege assignment purposes.
Tenant Takeover
Application Administrator
Can add credentials to any app registration and authenticate as that application. If the app holds high-privilege Graph permissions, this is a privilege escalation path to those permissions. Datadog documented the path to Global Admin via first-party apps in 2025, resolved August 2025.
High / Escalation Path
Cloud Application Administrator
Same credential injection capability as Application Administrator for most app registrations. Semperis documented the Device Registration Service escalation path via this role, allowing Global Administrator role assignment.
High / Escalation Path
Authentication Administrator
Can reset passwords and MFA for non-administrator users. An attacker with this role can take over any standard user account silently. Often assigned to helpdesk staff without understanding the full scope.
High / Account Takeover
Privileged Authentication Admin
Can reset credentials and MFA for any user including Global Administrators. One of the most dangerous roles in the tenant. Required to modify credentials of members and owners of role-assignable groups.
Tenant Takeover
Hybrid Identity Administrator
Controls the Azure AD Connect and cloud sync configuration. In hybrid environments, this controls the sync direction and can be used to inject or modify objects synchronizing from on-premises to the cloud.
High / Hybrid Pivot
Security Administrator
Can modify Conditional Access policies. An attacker with this role can disable MFA enforcement, create policy exclusions for their own account, and eliminate detection mechanisms including Identity Protection policies.
High / Defense Bypass
Agent ID Administrator
Prior to April 9 2026 patch, could take ownership of any service principal in the tenant, add credentials, and authenticate as that principal. Now scoped to agent-related objects only. If seen in your tenant with pre-patch activity, audit all service principal ownership changes in AuditLogs.
Patched / Audit Required
// Real World // Vercel via Context.ai 2025
One OAuth grant. One compromised AI tool. Workspace takeover.
An attacker compromised Context.ai, a third-party AI tool that a Vercel employee had connected to their Google Workspace account via an OAuth consent grant. From that single OAuth grant the attacker achieved workspace takeover and accessed internal systems. Internal data subsequently appeared on BreachForums. No malware. No zero-day. No credential phishing. The attacker found a token nobody was watching, connected to a service with access nobody had reviewed, tied to an OAuth grant nobody had audited. This is the OAuth consent grant attack surface in production. Every AI tool your team connects via OAuth is now part of your corporate trust graph.
The Microsoft recommendation on Global Admin count: Fewer than 5 permanent assignments. Fewer than 10 privileged role assignments in total across the tenant. Two break-glass accounts permanently assigned Global Administrator, all other Global Admin access via PIM eligible only. In practice, most enterprise tenants have significantly more than this. Every additional permanent Global Admin is an additional attack surface with the same blast radius as the first one.
Start here
// 04.2 / Read
Dangerous API
Permissions
Graph API application permissions are where the real power sits. A service principal with the right combination of application permissions is a tenant takeover primitive regardless of what directory roles it holds. Most security teams audit roles and miss permissions entirely.
The Detection Gap
Roles vs Permissions are two different audits
Most role assignment audits in Entra ID focus on directory roles: who has Global Administrator, Privileged Role Administrator, and so on. Application permissions held by service principals are a completely separate category that lives in app role assignments, not directory role assignments. A service principal with AppRoleAssignment.ReadWrite.All and no directory role is a tenant takeover primitive. It will not appear in a directory role audit. AzureHound sees it. A standard portal export does not.
Permission
What it enables
Blast Radius
AppRoleAssignment.ReadWrite.All
Grant any app role to any principal. Chain with Application.ReadWrite.All to grant RoleManagement.ReadWrite.All to a backdoor app. Assign Global Administrator from there. No directory role required.
Tenant Takeover
RoleManagement.ReadWrite.All
Assign any Entra directory role to any object. Assign Global Administrator to an attacker account directly. Operates independently of the principal's own directory role.
Tenant Takeover
Directory.ReadWrite.All
Read and write all directory objects. Modify users, groups, service principals, add credentials to any object. Effectively full directory control without a directory role.
Near Tenant Takeover
Application.ReadWrite.All
Modify any app registration. Add credentials to any app registration including those with high Graph permissions. Impersonate that application identity.
High / Escalation Path
Mail.ReadWrite (Application)
Read and write every mailbox in the tenant with no user involved. No sign-in event. Bypasses all user-centric DLP controls. Invisible to email monitoring tuned for user activity.
Full Mailbox Access
Files.ReadWrite.All (Application)
Read and write every file in every user's OneDrive and SharePoint across the entire tenant. A stale service principal with this permission and no owner is a tenant-wide file exfiltration risk.
Full File Access
User.ReadWrite.All (Application)
Read and modify all user accounts. Update passwords, modify profiles, disable accounts. Combined with other permissions this enables account takeover at scale.
High / Account Control
Group.ReadWrite.All (Application)
Add or remove members from any group including role-assignable groups. If a role-assignable group is assigned the Global Administrator role, adding yourself to it is equivalent to assigning yourself Global Administrator.
High / Group Control
The AppRoleAssignment Chain to Global Admin
Step by Step
01
Compromise a service principal with AppRoleAssignment.ReadWrite.All
The principal holds no directory role. Standard role audits will not surface it as privileged. AzureHound identifies it in the first enumeration pass as a high-value target.
No directory role required →
02
Register a backdoor application in the tenant
Create a new app registration. It appears as a legitimate application in the portal. No credentials yet. No permissions yet. Just an empty container.
Takes 30 seconds via Graph API →
03
Grant RoleManagement.ReadWrite.All to the backdoor app
Use the compromised principal's AppRoleAssignment.ReadWrite.All to grant the backdoor app the RoleManagement.ReadWrite.All application permission. This operation appears in AuditLogs under ApplicationManagement, not RoleManagement. Most SIEM rules do not alert on it.
No detection in most environments →
04
Add credentials to the backdoor app and authenticate as it
Add a client secret or certificate to the backdoor app. Authenticate via client credentials flow. The token has RoleManagement.ReadWrite.All as an application permission. No user sign-in event is generated.
Silent authentication →
05
Assign Global Administrator to any account
Call the Graph API roleManagement/directory/roleAssignments endpoint. Assign Global Administrator to any attacker-controlled account. This operation does appear in AuditLogs under Add member to role, which should fire a SIEM alert in a properly configured environment. But at this point the attacker already has the access.
The audit that actually matters: Run a Graph API query against all service principal app role assignments filtered for AppRoleAssignment.ReadWrite.All, RoleManagement.ReadWrite.All, and Directory.ReadWrite.All. Export the result. For every principal in that list, identify the owner, the last sign-in date, and the source IP of recent authentications. If any principal has no owner, has not signed in for more than 30 days, or has authenticated from an unexpected location, treat it as a priority finding. Most tenants have never run this query.
// 04.3 / Read
PIM Configuration
and Abuse
Privileged Identity Management is one of the most effective controls available for limiting standing privilege. It is also one of the most misunderstood. The protection it provides depends entirely on how it is configured, and the gaps in a weak configuration are exploitable.
What PIM Actually Does
Just-in-time access, not standing privilege
PIM converts a permanent role assignment into an eligible role assignment. The user holds no privilege until they activate the role through a workflow that can require MFA, approval, justification, and a time limit. Once the window expires, the privilege disappears. A compromised account that is eligible for Global Administrator but has never activated it holds no more privilege than any other user. The protection collapses when the configuration is weak.
Weak Config 01 // Compass Security April 2026
MFA Checkbox Without Authentication Context
The On Activation Require Azure MFA checkbox is the most commonly misunderstood PIM setting. It appears to enforce MFA at role activation. In practice, if a session has already satisfied MFA, PIM will not prompt again. An attacker with a stolen token whose session already completed MFA can activate PIM roles without any re-authentication challenge. The correct control is an Authentication Context in Conditional Access that explicitly requires reauthentication at activation, not the checkbox.
Weak Config 02
PIM Only for Global Admin
A common pattern is enabling PIM for Global Administrator while leaving Privileged Role Administrator, Application Administrator, and Authentication Administrator permanently assigned. These roles are all escalation paths to Global Administrator. Protecting Global Admin with PIM while leaving its escalation paths permanently assigned creates a false sense of security. PIM should cover all roles with PRIVILEGED label at minimum.
Weak Config 03 // September 2025 Incident
PIM Bypass via Direct Role Assignment
A compromised account with sufficient privilege can assign a permanent role directly outside PIM governance. In a documented September 2025 incident, an attacker who compromised an account with Owner on a subscription used it to directly assign permanent Global Administrator to a service principal. The PIM audit logs showed no activation event because the assignment bypassed PIM entirely. PIM controls eligible assignments. It does not prevent a sufficiently privileged account from making direct permanent assignments.
Weak Config 04 // Compass Security April 2026
Token Refresh After Legitimate Activation
When a legitimate user activates a PIM role, their existing refresh token can be used to obtain a new access token that includes the newly activated privileges. Compass Security documented that an attacker who holds a stolen refresh token can wait for the legitimate user to activate their PIM role, then refresh the token to obtain one that includes those activated privileges. The attacker did not trigger the MFA or approval workflow. The legitimate user did.
Correct PIM Configuration
What a hardened PIM setup looks like
Use Authentication Context in Conditional Access rather than the MFA checkbox. Require approval for all Tier 0 and Tier 1 role activations. Set maximum activation duration to the shortest period that allows the work to be completed, typically 1-4 hours. Enable notifications so all activations are visible to the security team. Require justification for every activation. Scope PIM to all roles with the PRIVILEGED label, not just Global Administrator. Use PIM for Groups to extend just-in-time access to role-assignable groups and to Azure RBAC roles at subscription scope.
The PIM for Groups extension: PIM can govern access to role-assignable groups as well as directory roles. This means just-in-time access can be applied to an entire group that holds a privileged role assignment, rather than managing individual eligible assignments per user. A user becomes eligible to activate membership in the group, which activates the role. When the window expires, they lose group membership and the role simultaneously. This is the recommended pattern for managing access to privileged groups at scale.
// 04.4 / Read
Cross-Tenant
and Guest Abuse
Every trust relationship between tenants is a potential lateral movement path. Guest accounts that look low-risk in isolation can become high-privilege entry points when the trust architecture is not explicitly constrained.
The Trust Architecture Problem
You cannot enforce your MFA policy on a guest
When a B2B guest user accesses your tenant, they authenticate via federation through their home tenant. Your tenant trusts their home tenant's authentication. If their home tenant has weaker MFA requirements, or no MFA at all, an attacker who compromises a guest account in a weaker tenant can satisfy your tenant's MFA requirements by completing a weaker challenge in their home tenant. Most tenants configure inbound trust to honor MFA claims from partner tenants without verifying what that MFA actually was.
Attack Path 01 // BeyondTrust, Active in Wild
Guest Account Subscription Creation
A guest user with billing roles in their home tenant can create a subscription in their own tenant and transfer it into the target tenant, retaining full RBAC Owner rights over that subscription. Owner on a subscription provides significant cloud resource control and is outside standard Entra directory role audits. BeyondTrust confirmed this attack vector is observed actively in B2B environments. Microsoft provides a Subscription Policy to block guest-created subscription transfers. Most tenants have not configured it.
Attack Path 02 // CrowdStrike, Vectra AI
Cross-Tenant Synchronization Abuse
Cross-Tenant Synchronization allows automated user provisioning between tenants. An attacker who compromises a source tenant with an outbound CTS configuration can modify the sync scope to include attacker-controlled user accounts and provision them into partner tenants. They arrive as federated B2B users with whatever access the sync configuration grants. The attack requires Global Administrator, Security Administrator, and Hybrid Identity Administrator in the compromised source tenant.
Attack Path 03
Overprivileged Guest Directory Roles
Guest accounts assigned Entra directory roles are a significant security risk. Their authentication is controlled by the home tenant. A guest assigned Security Administrator or Application Administrator gives the home tenant effectively co-administration capability over the resource tenant. Microsoft documentation explicitly warns against assigning guests to privileged directory roles. Guest accounts should not hold any Entra directory role.
Attack Path 04
Guest Self-Service Sign-Up
When guest self-service sign-up is enabled, external users can create guest accounts without requiring approval from an authorized person. An attacker can create a guest account scoped to specific services, use it for reconnaissance, and maintain persistent access that appears as a legitimate external user. The guest account survives password resets on the external identity because authentication is federated through the home tenant.
// Real World // Cross-Tenant Trust Exploitation
The trust boundary assumption that does not hold
In documented B2B attack scenarios, attackers have leveraged guest account access in a lower-value partner tenant to reach a higher-value target organization. The attack works because the target tenant trusts authentication from the source tenant and the attacker only needs to compromise a user in the source tenant that has guest access to the target. From a red team perspective, guest accounts in a target tenant that are federated from a smaller, less-defended partner organization are one of the highest-value targets in any enumeration pass. From a blue team perspective, these accounts are frequently the ones with the least monitoring and the weakest authentication requirements.
Guest account hygiene baseline: No guest account should hold any Entra directory role. No guest account should have access to sensitive data repositories without explicit justification. Guest default permissions should be set to the most restrictive option in External Identities settings so guests cannot enumerate your directory. Inbound trust should not automatically honor MFA or device compliance claims from partner tenants unless you have explicitly verified their security posture. Run quarterly reviews of all guest accounts and remove those that are no longer required.
// 04.5 / Read
Least Privilege
in Practice
Least privilege is not a one-time configuration. It is an ongoing practice of understanding what access actually exists, whether it is still needed, and whether the scope is as narrow as it can be. Most tenants drift toward over-privilege over time without active governance.
Control 01
Role-Assignable Groups
Role-assignable groups require the isAssignableToRole property set to true at creation. This property is immutable and cannot be set on existing groups. Maximum 500 per tenant. Dynamic membership rules are not allowed, preventing lower-level admins from modifying membership rules to add themselves. Members and owners of role-assignable groups are protected from credential changes by lower-privilege admins. Only Privileged Role Administrators can modify group credentials. This protection is one of the key reasons role-assignable groups are preferred over direct role assignments for managing privileged access at scale.
Control 02
Access Reviews
Entra ID P2 enables scheduled access reviews for role assignments and group memberships. A review requires assigned reviewers to confirm or deny each assignment on a defined schedule. Unreviewed assignments can be automatically removed on expiry. This is the governance mechanism that prevents privilege drift. Without access reviews, role assignments from previous projects, personnel changes, and deprecated automations accumulate indefinitely. The average enterprise has significant privilege sprawl that is invisible without active review.
Control 03
Custom Roles
When a built-in role grants more permissions than a user or service principal actually needs, a custom role should be created with only the specific permissions required. Custom roles require Entra ID P1 licensing for every user with a custom role assignment. They are scoped at the directory or administrative unit level. The trade-off is maintenance overhead versus attack surface reduction. For service principals running automated tasks with a narrow scope, custom roles significantly reduce the blast radius of a credential compromise.
Control 04
Administrative Units
Administrative units allow scoping of built-in roles to a subset of users, groups, or devices. An IT admin who manages users in one regional office can be assigned User Administrator scoped only to that office's administrative unit rather than tenant-wide. This limits the blast radius of a compromised admin account to the scope of their administrative unit rather than the entire tenant. Underused in most environments because it requires upfront planning and maintenance.
The Privilege Audit Sequence
What to run against any tenant you are responsible for
Start with a full export of all Entra directory role assignments filtered for permanent assignments to user accounts other than break-glass accounts. Every permanent Global Admin, Privileged Role Admin, and Authentication Admin that is not a break-glass account is a finding. Next run a Graph API query for all service principal app role assignments filtered for the six highest-risk permissions. For each result: identify the owner, last sign-in date, and credential history. Then enumerate all guest accounts and their permission assignments. Finally review all Conditional Access policy exclusions. Exclusions are where security policies go to die.
The Conditional Access exclusion problem: Every CA policy exclusion is a permanent exception to a security control. Break-glass accounts need exclusions. Service accounts that pre-date CA sometimes need them. Everything else is a risk. In most tenants, CA exclusions accumulate over time as users request exceptions for convenience and those exceptions are never reviewed or removed. Run a quarterly review of all CA exclusions. Any account that is excluded from the MFA policy needs a documented justification and a named owner who is accountable for the risk.
// 04.6 / Reinforce
Flashcards
Click to flip. Review Again flips back. Got It advances.
Card 1 of 12
// Tap to reveal answer
// Answer
Click card to flip
// 04.7 / Reinforce
Spot the
Chain
Three permission configurations. Each one contains a privilege escalation path. Identify the chain and what it enables.
This principal has no directory role. What is the escalation chain and what is the first thing you should do?
What is the attack chain if this account is compromised and what are the two most urgent remediation steps?
This guest holds Security Administrator permanently. Why is this a higher risk than the same role held by an internal user and what should happen immediately?
// 04.8 / Test
Module
Quiz
20 questions. Pass at 15. Role mechanics, permission chains, PIM abuse, cross-tenant attack paths, and least privilege controls.
out of 20
// 04.9 / Timed Assessment
Timed
Assessment
10 questions. 10 minutes. You are conducting a permission audit on a tenant with known issues. Identify the risk, the chain, and the correct remediation. No explanations until the end. Pass at 8.
// Assessment Parameters
Questions
10
Time Limit
10 minutes
Pass
8 / 10
10:00
Remaining