An Entra ID group's members are not just users: a member can be a user, a device, another group, a service principal, or a contact. Every analysis of group structure depends on classifying these correctly, because only group members create nesting.
The five member types#
Each type behaves differently in access and licensing:
- Users: receive access and inherit group-based licenses.
- Devices: participate in device-based policy, never in licensing.
- Groups: create nesting, extending everything transitively.
- Service principals: application identities, increasingly common in groups.
- Contacts: mail objects with no sign-in, relevant to distribution scenarios.
Why mistyping corrupts analysis#
Tools that infer type from incomplete data get nesting wrong. A classic failure is treating any member without a user attribute as a nested group, which converts every device into a phantom nesting edge and makes the hierarchy look deeper and more tangled than it is. Correct analysis requires asking the directory for each member's actual type.
VisualizerEngine
Member typing in VisualizerEngine
Members are typed correctly during sync: users, devices, nested groups, service principals, and contacts are distinguished, so a device is never mistaken for a nested group and the hierarchy you analyze is the hierarchy that exists.