Groups and privilege escalation: when a group owner becomes an administrator
Assigning privileges to groups rather than individuals is good practice. It does, however, shift the security question: what matters is no longer only who holds the role, but who can change the group's membership. That is where many escalation paths hide.
Role-assignable groups
To assign an Entra ID role to a group, the group must be created with the isAssignableToRole property, which cannot be changed afterwards. These groups get specific protections: only Global Administrators and Privileged Role Administrators can create them and manage their membership, they cannot be dynamic and they do not accept nested groups.
One major exception remains: group owners can manage membership. A user with no role at all who is made owner of a group that carries Global Administrator can add themselves to it.
Get-MgGroup -Filter "isAssignableToRole eq true" -All -ConsistencyLevel eventual -CountVariable n |
ForEach-Object { $_.DisplayName; Get-MgGroupOwner -GroupId $_.Id | Select-Object -ExpandProperty Id }
Ordinary groups, a frequent blind spot
Groups that are not role-assignable get none of these protections. Their membership can be changed by their owners, by Groups or User Administrators, and by any application holding the right Graph permission. Yet these groups are often used to grant highly sensitive access:
- an Owner or Contributor role on an Azure subscription;
- access to an application that itself holds high privileges;
- exclusion from a Conditional Access policy that requires MFA;
- eligibility for a role through PIM for Groups.
In such cases, a helpdesk administrator who can manage the group effectively holds the privilege it grants.
Groups synchronised from AD
A group synchronised from Active Directory is managed on-premises. Anyone who can change its membership in AD, an Account Operator or an administrator delegated on an organisational unit, therefore also controls the cloud rights assigned to it. This is one of the most common paths from an AD compromise to a cloud takeover.
Principle. A group must be protected at least as well as the privilege it grants. A group that leads to a tier 0 role must be managed exclusively by tier 0 identities, and in the cloud only.
PIM for Groups: useful, not sufficient
Making membership eligible through PIM adds activation, justification and limited duration. But if a permanent owner can change members or settings, the control can be bypassed. Make ownership eligible too, or remove unnecessary owners.
What an audit checks
- The owners of every role-assignable group.
- Unprotected groups carrying Azure permissions, sensitive application access or Conditional Access exclusions.
- Groups synchronised from AD that grant cloud privileges.
- Applications with write permissions on groups or group membership.