Entra ID Nested Privileged Groups, Role-Assignable Groups, and Guests in Security Groups

What Are Role-Assignable Groups and Nested Privileged Groups in Entra ID

Entra id nested privileged groups role assignable: that compound search covers one of the least audited corners of Microsoft Entra ID access control — nested privilege via role-assignable groups, and a guest riding into a security group through membership rather than invitation, together forming a silent path toward Global Administrator that most tenants have never mapped.

A role-assignable group is a security group with the isAssignableToRole property set to true (or "Microsoft Entra roles can be assigned to this group" set to Yes in the portal). Assigning a Microsoft Entra role to a group instead of to individual users lets an organization manage role membership through group membership changes rather than repeated role-assignment API calls. Per Microsoft's documentation, creating role-assignable groups requires Microsoft Entra ID P1 or P2, the isAssignableToRole property is immutable once the group is created, a role-assignable group cannot use dynamic membership, and a tenant can have a maximum of 500 role-assignable groups. Microsoft also "protects" the owners of role-assignable groups specifically to reduce elevation-of-privilege risk on the group object itself.

Nested privileged groups describes a group being a member of another group that carries privileged Entra roles or resource access — the same "path to Domain Admin" logic that exists in on-prem Active Directory (see dangerous group nesting in Active Directory), applied to the cloud directory. Microsoft explicitly blocks the most obvious version of this: a group cannot be an active member of a role-assignable group. What Microsoft does allow — and what most tenants have not accounted for — is a group being an eligible member of a role-assignable group through Privileged Identity Management (PIM) for Groups.

Finally, guests in security groups is a distinct problem from guest invitation governance. This article is not about who can invite a guest (see Azure Guest Accounts: The Forgotten Attack Surface for that angle) — it is about a guest account ending up as a member of a security group that carries access or role eligibility, through nesting or a dynamic membership rule, without anyone explicitly deciding to grant that guest anything.

Entra ID Nested Privileged Groups Role Assignable: The Escalation Chain

Step 1 — A non-privileged group gets nested as an eligible member

PIM for Groups lets an administrator configure eligible assignments in two directions: either users are actively added to a group and the group itself is made eligible for a role, or a role is actively assigned to a group and users are made eligible for membership in that group — and, per Microsoft's own documentation on PIM for Groups, a group itself can also be configured as an eligible member of another group, including a role-assignable one. Because the active membership restriction on role-assignable groups only blocks direct, standing membership, a lower-privilege group can be configured as an eligible member of a role-assignable group without violating that restriction.

Step 2 — No approval workflow is enforced on activation

PIM for Groups supports the same policy controls as PIM for Entra roles: requiring approval, enforcing MFA on activation, requiring a business justification, and capping the maximum activation duration. When these controls are not configured — which is the default posture in many tenants that adopted PIM for Groups without hardening it — any member of the lower-tier group can self-activate their eligible membership in the privileged group and inherit whatever role that group carries (Global Administrator, Privileged Role Administrator, Application Administrator, and so on — see Azure Privileged Access: Too Many Global Admins on why standing and easily-reached Global Administrator access is already a common finding).

Step 3 — A guest rides along through the same group

The nested group in Step 1 rarely started life as a "privileged" group — it is often a project team, an app-access group, or a group with a broad dynamic membership rule. If a guest account was added to that group (directly, or because the group's dynamic rule was written more broadly than intended — for example matching on attributes that don't reliably exclude userType eq Guest; see the memberOf dynamic-group rule operator retirement for how these rules are already shifting), the guest inherits the same eligible path into the role-assignable group as any member user. Nobody explicitly reviewed "should this guest be eligible for Global Administrator" — the group nesting made that decision implicitly.

Guest account
  -> member of "Project-Falcon" security group (dynamic or manual membership)
      -> "Project-Falcon" is an eligible member of "Tier0-Admins" (role-assignable group)
          -> "Tier0-Admins" is actively assigned the Global Administrator role
              -> guest self-activates eligible membership (no approval required)
                  -> guest now holds Global Administrator for the activation window

The Compass Security EntraFalcon assessment tooling documents the same underlying weakness from an offensive-assessment angle: it flags any group that is neither role-assignable, synced from on-premises, nor placed inside a Restricted Management Administrative Unit as an "unprotected" privileged group (finding ID GRP-005 in their reporting), because none of those three properties are guaranteed to be true for a group that only becomes privileged transitively through nesting.

Detection

Detection here means finding role-assignable groups, finding what is eligible-nested inside them, and finding guests inside the group tree that feeds them — none of which shows up as a single alert by default.

# Microsoft Graph — enumerate role-assignable groups
GET https://graph.microsoft.com/v1.0/groups?$filter=isAssignableToRole eq true&$select=id,displayName,membershipRuleProcessingState

# Microsoft Graph — guests transitively inside a specific group
GET https://graph.microsoft.com/v1.0/groups/{group-id}/transitiveMembers/microsoft.graph.user?$filter=userType eq 'Guest'

// Sentinel / Log Analytics — group membership changes feeding a watch-list of privileged group IDs
AuditLogs
| where OperationName in ("Add member to group", "Add owner to group")
| where TargetResources[0].id in (privilegedGroupIds)
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].displayName)

Remediation

1. Inventory every role-assignable group with the isAssignableToRole eq true Graph query above — do not rely on tenant memory of "the groups we created for this." Assign an owner to each and remove owners who no longer need the access, since Microsoft's own guidance flags ungoverned ownership as the primary elevation risk on these objects.
2. Require approval and MFA on activation for any PIM for Groups eligible assignment that terminates in a role-assignable group, and set a bounded maximum activation duration instead of leaving it open-ended.
3. Ban group nesting into role-assignable groups where it isn't operationally required. Microsoft's own guidance recommends limiting or avoiding nested groups for role elevation paths because each nesting level adds group owners who can indirectly manage who reaches the role, whether they intended to or not.
4. Audit dynamic membership rules that feed any group in a privileged chain, and make guest exclusion explicit (userType -ne "Guest") rather than assumed — a role-assignable group itself can't use dynamic membership, but the groups nested under it can, and that's exactly where a broad rule does the damage.
5. Run access reviews on role-assignable group membership and on eligible-membership chains, not just on role assignments directly — a quarterly review scoped only to "who holds Global Administrator" will not catch a guest sitting two nesting levels below it.
6. Remove guests from security groups they were never meant to join. If a guest's presence in a group can only be explained by "the dynamic rule caught them" or "someone added them to the wrong group," treat that as an incident to close, not a config detail to note for later.

These checks fold into a broader review — see how to audit Microsoft Entra ID security for where group and PIM hygiene sit relative to Conditional Access, MFA, and app permissions.

How EtcSec Detects This

EtcSec's Azure/Entra ID audit checks for exactly this chain: Nested Groups with Privileged Access (AZ_GROUP_NESTED_PRIVILEGED) flags groups that reach a role-assignable group through eligible or transitive nesting, Role-Assignable Groups (AZ_GROUP_ROLE_ASSIGNABLE) inventories every isAssignableToRole group and its ownership/approval posture, and Guest Users in Security Groups (AZ_GROUP_GUEST_IN_SECURITY) surfaces guest accounts sitting inside security groups regardless of whether they were invited directly or picked up membership through nesting or a dynamic rule. Related checks — Admin Role Assigned to Group (PA_GROUP_ASSIGNED_ADMIN) and Privileged Groups Without Change Monitoring (AZ_GROUP_PRIVILEGED_CHANGES) — extend the same audit to role-to-group assignments and to whether membership changes on those groups are actually being logged and reviewed.