The shape of a directory is decided before the first policy is written, and it ages badly when it is improvised. How many tenants you run, how you group people, and what you protect from your own administrators are foundational choices that everything else is built on top of, and they are far cheaper to make deliberately at the start than to retrofit once the directory is full.
This is the third article in the Entra ID series. The previous one traced where identities come from. This one is about the container that holds them and the structure you impose on it.
One tenant, usually
The first structural question is how many tenants to run, and Microsoft’s guidance is clear and, in my experience, correct: prefer a single tenant and delegate administration within it. Most separation people reach for a second tenant to achieve can be done inside one, and a single tenant is where collaboration and productivity actually work. Multiple tenants are justified by a short list of genuine drivers: settings that must differ at the tenant level and cannot coexist, a risk tolerance so low that even authorized members of the organization must be walled off, and the hard technical fact that some Microsoft services bind their lifecycle to the tenant, so a second instance of them requires a second tenant. Absent one of those, a second tenant is usually a decision to maintain two of everything for the rest of its life.
When you genuinely do run several, Entra gives the arrangement a defined boundary rather than leaving it ad hoc. A multitenant organization draws a border around the tenants your organization owns, up to a hundred active tenants, and governs each pair with cross-tenant access settings. It is meant to be paired with cross-tenant synchronization, which automates creating, updating, and removing the B2B accounts that represent your own people across those tenants, including removing them when someone leaves. Two properties of that synchronization are worth stating plainly because they shape what it can do: it is one-directional, pushing from a source tenant outward, and for groups it moves only static security groups. It is a provisioning engine for a federation of tenants you control, not a merge of them.
Groups are the load-bearing structure
Almost every access decision in the tenant is ultimately expressed against a group, which makes groups the load-bearing structure of the whole directory and worth designing rather than accreting. The pattern I hold to separates two jobs that groups are asked to do. Population groups describe who a person is, built from reliable attributes and using dynamic membership so that they maintain themselves as people move. Entitlement groups describe what a person may reach, and they are what actually grant access. Keeping those two roles in separate objects is what makes access reviewable at all, because a group that simultaneously defines a population and confers a permission cannot be honestly audited: you can no longer tell whether someone is a member because of who they are or because of what they were given.
Dynamic membership groups, to use the current name, are the right default for population wherever the underlying attributes are trustworthy, because self-maintaining membership removes an entire category of stale-access error. The counterweight is scale: a tenant is capped at fifteen thousand dynamic membership groups, counted together with dynamic administrative units and entitlement automatic-assignment policies, and very large dynamic estates take longer to process, sometimes materially so. Dynamic membership is a tool for reliability, not something to apply to everything reflexively.
The sharpest reason to keep population and entitlement apart is what happens when a group grants a role. A role-assignable group is created through an immutable property set at creation, cannot use dynamic membership at all, and for a specific reason: automated population could inject an unwanted account straight into a privileged role. Microsoft draws the threat model out explicitly, noting that if a group is assigned a role, anyone who can manage dynamic membership rules could indirectly manage that role. So role-assignable groups must be assigned membership, their creation requires at least a Privileged Role Administrator, they cannot be nested, and changing the credentials of their members demands an elevated role of its own. Treat them as privileged objects in their own right, because that is exactly what they are, and a tenant is limited to five hundred of them, which is a number you should never come close to needing.
Protecting the core from your own admins
Administrative units partition the directory so that a role can be scoped to a slice of it rather than the whole, and their most valuable use in the current year is protective rather than merely organizational. A restricted management administrative unit, generally available since July 2025, locks the objects inside it so that tenant-level administrators, Global Administrators included, cannot modify them unless they hold a role explicitly scoped to that unit. This is the containment boundary I recommended for break-glass and tier-zero objects in the anchor article, made concrete: a place to put the accounts that must survive a compromised administrator, where being a Global Administrator is not enough to touch them.
It is a genuine boundary, so it comes with genuine trade-offs you should understand before you commit, because the setting is fixed at creation and cannot be changed afterward. Objects inside a restricted management unit cannot be managed by the governance features, so no Privileged Identity Management, no entitlement management, no access reviews, and no lifecycle workflows reach into it. And the protection is symmetric in a way that bites if you are careless: a Global Administrator placed inside such a unit cannot have their password reset by any other administrator, which is precisely the protection you wanted and also a way to lock yourself out if you put the wrong object there. Use it deliberately, for the small set of objects that truly warrant it, and a tenant allows up to a hundred of these units.
A place to put the accounts that must survive a compromised administrator, where being a Global Administrator is not enough to touch them.
The limits that quietly shape the design
A few directory limits are worth knowing early, because they turn abstract advice about avoiding sprawl into concrete design constraints. Group membership feeds the sign-in token, and the token caps the number of groups it will carry: a hundred and fifty for SAML assertions, two hundred for JWT, nested groups included. Cross that line and Entra does not simply truncate the list, it drops group claims from the token entirely and substitutes a pointer to Microsoft Graph, which breaks any application that expected to read groups from the token. The mitigation is to emit only the groups actually assigned to the application rather than all of them, and the deeper lesson is that piling every user into a handful of enormous groups has a failure mode with a specific number attached to it. A related limit bites even before the token is issued: Entra only applies group-based filtering while a user is a member of a thousand groups or fewer, so past that point the group data an application depends on can quietly arrive incomplete. These are not edge cases in large estates; they are the reason the population-and-entitlement discipline pays off, because sprawling mega-groups walk you toward both limits at once.
Names and domains
Two smaller foundations deserve a mention because they are easy to set well at the start and awkward to fix later. A naming convention for identity objects is worth adopting even though Entra only enforces one automatically for Microsoft 365 groups, through configurable prefixes and suffixes and blocked words. For security and identity groups the discipline is convention rather than platform-enforced, which means it lives or dies on whether you actually hold to it, so decide the scheme before the objects exist. And the tenant’s verified domains are part of the identifier for nearly everything, since a domain name is woven into user names, group addresses, and application identifiers. The initial name ending in onmicrosoft.com is also the primary domain until you change it, and changing the primary later does not rename existing users, so getting the primary right early avoids a directory full of addresses in a domain you would rather not have chosen.
None of this is glamorous, and that is the point. The tenant count, the group model, the protected core, and the naming scheme are the substrate. Get them right and the identity work that follows, the credentials, the risk signals, the privilege, the governed access, all has somewhere solid to stand. The next article turns to how people actually prove who they are, and how the authentication estate is moving past the password.
Entra ID
‹ Previous: [E 2] Identities and How They Get There
Next: [E 4] Authentication Methods and the Road to Passwordless ›
