Most access in most organizations is granted by hand and never taken back. Someone adds a person to a group because they asked, the reason is forgotten within a quarter, and the membership outlives the need by years. Entitlement management is the answer to that pattern: it turns access into a governed object with a requester, an approver, a reason, and an expiry, so that a grant is a transaction the directory remembers rather than a favor it forgets.
This is the ninth article in the Entra ID series. The previous ones dealt with administrators and their power. This one is about everyone else, about how ordinary access to groups, applications, and sites should be requested, approved, and eventually returned.
Three objects that carry the whole model
The design rests on three things and they are worth naming precisely. An access package is a bundle of the resources a role or project actually needs, membership in some groups, assignment to some applications, access to some sites, gathered into one requestable unit. A catalog is the container that holds packages and the resources they draw on, and it is also the delegation boundary, which is the part people underestimate. A policy is the set of rules bound to a package that decides who may request it, who approves, and how long the resulting assignment lasts before it expires. The move that makes all of this matter is that a person requests the package, not the underlying groups, so access is granted as a coherent thing with a lifecycle rather than as a scatter of individual memberships that no one can later reason about.
The catalog as a delegation boundary deserves emphasis because getting it wrong quietly breaks the whole model. A tenant administrator can put any resource into any catalog, but a delegated catalog owner can only add resources they themselves own. That constraint is the feature, not a limitation: it lets a business unit run its own access packages over its own resources without handing it authority over anyone else’s, which is how entitlement management scales past the central identity team to the people who actually understand what access a given team needs.
Request, approve, expire
The lifecycle a policy describes is where the governance lives. A request can require approval, and the approval can be multi-stage, routed to a manager, to named approvers, or to a designated sponsor, so the decision lands with someone who can actually judge it. An assignment can carry an expiration, after which the access simply ends, and it can be attached to a recurring access review so that access which needs to persist is periodically reconfirmed rather than assumed. The single most important design instruction I give here is to set expiration deliberately on every package, because access that never expires is access that accumulates, and the whole value of the system collapses if grants are permanent by default. Expiry is not a detail; it is the mechanism by which the directory stays honest over time.
Separation of duties is the other policy control worth designing in from the start. You can mark access packages, or the groups behind them, as incompatible with one another, so that a person holding one cannot request a conflicting second, which is how you encode the classic controls that keep the same individual from holding two powers that should never combine. One sharp edge to remember: these incompatibility relationships are one-directional. Declaring that package A is incompatible with package B does not automatically prevent the holder of B from requesting A; you have to set the relationship both ways to make it mutual. It is an easy thing to half-configure and believe you are protected when you are only protected in one direction.
Access that never expires is access that accumulates. Expiry is the mechanism by which the directory stays honest.
Automatic assignment, and the quota it spends
Not all access should wait for a request. For entitlements that follow directly from who a person is, their department, their job, entitlement management offers attribute-based automatic assignment, using the same rule syntax as dynamic groups so that people gain and lose the package as their attributes change. It is the right tool for baseline access that everyone in a role should simply have. There is a design cost that is easy to miss and important to plan for: each automatic-assignment policy silently creates a backing dynamic security group to do its work, and that group draws from the same tenant ceiling of fifteen thousand dynamic-membership objects that dynamic groups and dynamic administrative units also consume. Automatic assignment is not free of that budget; it spends from it, and a large estate that leans heavily on it should count those policies against the same cap it watches for its dynamic groups.
Governing access for people who are not yours
Entitlement management is also the cleanest way to give external partners access, because it wraps the whole guest lifecycle in the same governed structure. A connected organization represents an external party, and its users can request packages just as internal users do; on approval the platform invites them into your directory as a guest and grants the access in one motion. The part that makes this genuinely governed rather than merely convenient is what happens at the other end. A guest brought in this way is tied to their assignments, and when they lose the last one they are blocked and then removed on a schedule, so the access lapsing actually cleans up the account rather than leaving an orphaned guest behind. That automatic cleanup only applies to guests entitlement management invited or that you have explicitly marked as governed; the pre-existing guests scattered through an older tenant remain invisible to it until you bring them under management, which is worth knowing before you assume the system is tidying accounts it was never told about.
This external path does not float free of the tenant’s other controls. It sits on top of the cross-tenant access settings and the collaboration allow and deny lists, which remain the outer guardrails; if those forbid a partner, entitlement management will not override them. The external-identities article later in this series covers those settings in their own right, and the thing to carry from here is that entitlement management is how you govern partner access as a lifecycle, while the cross-tenant settings are the boundary inside which it is permitted to operate at all.
Licensing, and one interaction to remember
Entitlement management belongs to the Entra ID Governance product, sold on its own or inside the Entra Suite, and its licensing is per-seat: you need a license for every member user in scope of the features, counted by who can request rather than who does, with external guests billed instead under a monthly-active-user meter. Some of the basic capability operates under a legacy P2 subscription, but the features that make the system powerful, automatic assignment, custom extensions that call out to a Logic App during a request, and the verifiable-credential checks that let an approver see a proven claim rather than a self-asserted one, sit squarely on the Governance license. Plan for that line, because a design that assumes automatic assignment on a P2-only tenant assumes a capability it does not have.
One interaction is worth carrying forward explicitly. The restricted management administrative units from the previous article are deliberately out of reach of the governance features, entitlement management included, so anything you place inside one cannot be handed out through an access package. That is by design and it is usually what you want, but it means the protected core and the governed-access machinery are mutually exclusive by construction, and you choose per object which of the two regimes it lives under.
Entitlement management grants access as a governed object and expires it on a timer. What it does not do by itself is prove, on a recurring basis, that the access still standing is still warranted, or drive the joins and departures that should create and revoke access in the first place. Those are the jobs of access reviews and lifecycle workflows, and they are where the series goes next.
Entra ID
‹ Previous: [E 8] Roles, Custom Roles, and Delegated Administration
Next: [E 10] Access Reviews and Lifecycle Workflows ›
