Entra ID dynamic groups: when a poorly chosen attribute opens the door
Dynamic groups save a great deal of time: membership automatically follows account attributes. That automation has a flip side. Anyone who can change the attribute can, indirectly, obtain the access granted to the group.
The principle and its consequence
A dynamic group, which requires Entra ID P1, evaluates a rule against user or device attributes, such as user.department -eq "Finance". The group is therefore no more trustworthy than the attribute it relies on. The real question is not "who is a member?" but "who can change this attribute?".
Attributes you should not take at face value
- Attributes synchronised from AD: department, company, extension attributes. Anyone with delegated write access to the object in AD, local helpdesk included, can bring an account into the cloud group.
- Attributes fed by HR synchronisation: reliable as long as the pipeline is controlled, but a data-entry mistake or a compromised service account is enough.
- Guest attributes: a guest's mail address or display name comes partly from their home organisation or the invitation. A rule such as
user.mail -contains "partner"may include accounts you do not control. - Device names: for device rules, the display name can often be chosen by the user who registers the device.
Simple habit. Always add (user.userType -eq "Member") to rules intended for internal staff. Without it, a rule written for employees can sweep in guests whose attributes happen to match.
Risky uses
A dynamic group used to assign licences or build mailing lists is not a major concern. The risk appears when it is used to:
- grant access to sensitive applications or Azure resources;
- exclude users from a Conditional Access policy;
- scope an administrative unit, which widens a delegated administrator's reach;
- deploy permissive Intune configurations.
Dynamic groups cannot hold Entra ID roles, but they can still lead to privilege through these other routes.
Processing delay
Rule evaluation is not instantaneous. When someone leaves, their account may remain in a dynamic group for some time after its attributes change. Leaver processes should not rely solely on updating an attribute: disabling the account and revoking sessions remain essential.
In short
Keep dynamic groups for low-sensitivity access, or base them on attributes whose source is controlled and protected. Never use a dynamic rule for a Conditional Access exclusion. Filter user type explicitly, and inventory who can write, in AD as well as in Entra ID, the attributes your groups depend on.