Groups, Access Reviews, and Group-Based Licensing in Microsoft Entra ID
Fourth in this series on Microsoft Entra ID, covering groups: what the different group types are for, how access reviews keep group membership honest over time, and how group-based licensing removes a whole category of manual admin work.
Group types
Groups exist to simplify permission management: instead of assigning access individually, you assign it to a group, and every member inherits it. A group is also a security boundary, and it's the unit access reviews, audit logs, and bulk operations typically operate on. Membership is either maintained manually, or determined dynamically by a rule — a Dynamic Group — but adding someone to a group by itself grants nothing; permissions have to be explicitly assigned to the group, and the group's membership then dictates who ends up with those permissions. Until something is assigned to it, a group is just an organisational structure.
Security groups are the most common type. They're collections of users (and, in on-premises AD DS terms, computers) that can be assigned permissions to Azure resources, and they require a Microsoft Entra administrator to manage. This is the workhorse type for applying access control efficiently to a group rather than to individuals one at a time.
Dynamic groups determine membership through a query evaluated against user or device properties, rather than manual addition — and because membership is rule-driven, you genuinely can't add members manually to a dynamic group. Membership is recalculated by the rule each time it runs, automatically adding and removing members as their attributes (department, job title, country, and so on) change. This cuts a lot of administrative overhead, but it does mean consistent, accurate account provisioning upstream is crucial — a badly populated attribute can add or drop someone from a group unintentionally.
Microsoft 365 groups exist for collaboration: they provide a shared mailbox, calendar, files, a SharePoint site, and can include external users. They're available to both end users and admins to create.
Mail-enabled security groups serve a dual purpose — they grant access permissions like a regular security group, but also have an associated email address other members can send mail to. One caveat worth flagging: they don't support self-service password reset (SSPR) — see the dedicated SSPR post in this series for what that feature does support.
As an aside, a few Azure RBAC roles came up alongside groups in the course material, worth noting even though they're a separate concept from Entra groups themselves: the Reader role lets you view resources without making changes; Contributor lets you manage all resources; Billing Reader gives read-only access to billing data; Tag Contributor lets you manage resource tags without touching the resources they're attached to; and Cost Management Contributor lets you view costs and manage budgets, without the ability to modify resources — distinct from Billing Reader, which is view-only and can't manage budgets at all.
Access reviews
Access Reviews sit within Microsoft Entra ID Governance and let administrators periodically re-verify that group membership, application access, and privileged role assignments are still appropriate — confirming users still need access they were granted, rather than letting it accumulate indefinitely. This matters most for guest users and administrative roles, where stale access is the highest-risk kind. The feature requires a P2 licence (or Microsoft Entra ID Governance, which includes it — see the licensing tiers post earlier in this series).
Reviews can be scoped to Microsoft 365 groups, Teams, application access, or privileged role assignments, and reviewers — the people responsible for actually verifying access — can be group owners, managers of the reviewed users, or specific users or groups assigned to the task. Reviews can run once or recur on a schedule (semiannually, annually, and so on), and based on how reviewers respond, or fail to respond, the review can automatically remove access or leave it unchanged.
A concrete scenario worth keeping in mind: an employee's access needs typically change as they move through different roles at a company, and should be fully removed when they leave. Access Reviews is the tool for keeping that continuously true rather than relying on someone remembering to clean up. A common real-world use is having a manager — say, of a third-party vendor's developers — get a recurring email notification (monthly, in one example) prompting them to review and approve or deny that team's access; if they don't respond, the system can be configured to automatically revoke the unverified access. This gets you continuous access monitoring without custom code or scripts, which matters if minimising development effort is a constraint.
Group-based licensing
Historically, licences could only be assigned at the individual user level, which made large-scale management painful — adding or removing licences as people joined, left, or moved departments often meant writing a PowerShell script that made individual calls per user. Group-based licensing solves this: you assign one or more product licences to a group, and Microsoft Entra ID keeps every member's licence assignment in sync with membership automatically — new members are assigned the licence, and members who leave lose it, typically within minutes of the membership change.
A few specifics worth keeping straight. For any group with an assigned licence, you need at least one licence for every unique member of that group — so 1,000 unique members across licensed groups means at least 1,000 licences, to meet the licensing agreement. Licences assigned through a group are consumed only by the group's members, not by its owners, and a group with an assigned licence can't be deleted (though individual users can still be removed). A licence assigned via a group can't be revoked from an individual member directly — to remove it, you either take the user out of the group or unassign the licence from the group itself. Group-based licensing enforces this inheritance, and it does not support nested group inheritance — a licence assigned to a parent group doesn't flow down to members of a nested child group.
A handful of other mechanics: licences can be assigned to any security group, whether synced from on-premises via Microsoft Entra Connect, created cloud-only directly in Entra ID, or populated automatically via dynamic group rules. When assigning a product licence to a group, an admin can disable individual service plans within it — useful when an organisation isn't ready to roll out a particular service yet (for example, assigning Microsoft 365 to a department but temporarily disabling Yammer). Group-based licensing is currently managed only through the Microsoft 365 admin center. A user can belong to multiple licensed groups and also have licences assigned directly outside any group — the resulting state is the union of everything assigned, and if the same licence reaches a user through more than one path, it's still only consumed once. Where licences can't be fully processed — not enough available licences in the tenant, or conflicting services assigned simultaneously — admins have visibility into which users were affected, so they can act on it.