12.1 Catalogs & Access Packages
Key Takeaways
- Entitlement management is Microsoft Entra ID Governance’s self-service access package model that packages groups, applications, and SharePoint sites into requestable entitlements with policies for who can request, approval, duration, and reviews.
- A catalog is a boundary for resources and access packages; catalog roles (owners, access package managers, catalog readers) separate resource ownership from day-to-day package administration.
- Access packages bundle resources—security/Microsoft 365 groups, enterprise applications (with app roles), and SharePoint Online sites—into a single joiner experience instead of ad-hoc permanent group adds.
- Assignment policies control requestor scope (for employees, specific connected organizations, or all users), approval stages, expiration/extension, and optional access-review linkage for ongoing attestation.
- Plan entitlements from business roles and least privilege: design packages around projects or job functions, time-box external access, and avoid one mega-package that over-grants every resource.
Why entitlement management sits in Domain 4
Domain 4 of SC-300—Plan and automate identity governance (about 20–25%)—tests how you deliver least-privilege, time-bound, reviewable access at scale. Entitlement management is the Entra ID Governance feature that turns “add this guest to five groups and three apps forever” into access packages with policies for who may request, who approves, how long access lasts, and when access is reviewed or removed.
What entitlement management solves
Without governance, organizations accumulate permanent group memberships, orphaned guests, and “temporary” SharePoint access that never ends. Entitlement management addresses:
| Pain | Entitlement management response |
|---|---|
| Multi-resource onboarding for a project | One access package with groups, apps, and sites |
| Manual ticket chaos for partner access | Self-service requests with defined requestor scope |
| Shadow permanent privileges | Expiration, extension rules, and access reviews |
| Inconsistent approvers | Policy-driven single- or multi-stage approval |
| Unclear ownership of resources | Catalogs with delegated catalog/package roles |
| External collaboration sprawl | Packages tied to connected organizations and guest lifecycle |
Licensing (exam-level): Entitlement management is an Microsoft Entra ID Governance capability (historically associated with Identity Governance / Entra ID P2 + governance features). SC-300 stems that require access packages, catalogs, or automatic guest removal assume governance licensing is available—do not answer with “free Entra only” features when the scenario clearly needs packages.
Plan entitlements before you click Create
Exam and real-world designs fail when admins create packages without a model. Plan first:
- Inventory business scenarios — new hire baseline, finance project, vendor portal, M&A partner workspace, contractor temporary access.
- Map least-privilege resources — which groups, app roles, and SharePoint sites each scenario truly needs.
- Separate internal vs external packages — employees and guests often need different requestor scopes, approvers, durations, and ToU.
- Decide time bounds — permanent employee role packages vs 30/90-day partner packages with extension requests.
- Name catalogs and packages for operators — “Contoso Partner – ContosoFabrikam Project X,” not “Package1.”
- Define owners — who owns the catalog, who manages packages, who approves requests, who reviews access.
- Link reviews — which packages must re-attest membership periodically (especially guests and high-value apps).
| Planning question | Design implication |
|---|---|
| Is this a standing job function or a project? | Job function may allow longer assignments; projects should expire |
| Are requestors employees, specific partners, or anyone? | Assignment policy requestor scope |
| Is dual approval required (manager + resource owner)? | Multi-stage approval |
| Must legal acceptance happen first? | Terms of Use on the package and/or Conditional Access |
| Should leftovers auto-clean guests? | Lifecycle settings when last package expires (section 12.3) |
Anti-pattern: one tenant-wide package containing every group and app. That defeats least privilege and makes every approval an all-or-nothing decision.
Catalogs: the container boundary
A catalog is a container for resources and access packages. Think of it as a governed workspace for a business unit, partner program, or application portfolio—not as a security group itself.
Why catalogs matter
- Resource scope: Only resources added to the catalog can be included in that catalog’s access packages.
- Delegation: Catalog owners and access package managers can operate inside the catalog without becoming tenant-wide Identity Governance Administrators for every change.
- Separation: Finance, R&D, and external partner programs can have distinct catalogs, owners, and packages.
Catalog roles (conceptual)
| Role / capability | Typical use |
|---|---|
| Catalog owner | Full control of the catalog: resources, packages, delegated managers |
| Access package manager | Create and manage access packages and policies in the catalog without owning every resource decision |
| Catalog reader | Visibility for auditors or support without change rights |
| Tenant Identity Governance Administrator (or equivalent privileged role) | Broad governance configuration across catalogs |
SC-300 cue: “Delegate package creation for the Marketing catalog without granting Global Administrator” → use catalog-scoped roles, not Global Admin.
Create and configure a catalog
Typical configuration steps (portal or Microsoft Graph):
- Create the catalog with a clear name and description.
- Optionally mark whether the catalog is enabled for external users / collaboration scenarios as your design requires.
- Add resources the packages will need:
- Groups (security groups and/or Microsoft 365 groups / Teams-backed groups as supported)
- Applications (enterprise applications; select app roles where applicable)
- SharePoint Online sites
- Assign catalog owners and access package managers.
- Create access packages inside the catalog (next).
Resources must exist in Entra / M365 first. Entitlement management assigns users to those resources when a package assignment becomes active; it does not invent SharePoint sites or apps from nothing.
Access packages: the entitlement unit
An access package is the user-facing and policy-facing unit: “Request Vendor – Contoso Finance Read and receive these resources after approval.”
Resources inside a package
| Resource type | What assignment does | Exam notes |
|---|---|---|
| Groups | Adds the user as a member (and can drive licensing, Teams, RBAC via group) | Prefer role-aligned groups, not ad-hoc personal groups |
| Applications | Assigns the user to the enterprise app, often with a specific app role | Pick the least-privileged app role |
| SharePoint sites | Grants the configured site membership/role for the package | Coordinate with site sharing settings |
A single package can mix resource types so a contractor redeems one request instead of three tickets.
Package design patterns
| Pattern | Contents (example) | Duration bias |
|---|---|---|
| New hire baseline | All-company M365 group, baseline apps | Longer / employee lifecycle |
| Department role | Dept security group + LOB app role | Tied to job; review on mover events |
| Project workspace | Project M365 group/Team + project site + app | Short, with extension |
| External partner | Partner security group + limited app role + shared site | Short; strict approvers; ToU |
| Privileged-adjacent | Groups that feed privileged access | Prefer PIM for true privileged roles; packages for standing membership only when designed carefully |
Important boundary: Entitlement management is excellent for groups, apps, and sites. Privileged directory roles (Global Administrator, Privileged Role Administrator) belong primarily under Privileged Identity Management (PIM) with eligible activation—not as casual access-package permanent grants. Exam stems that say “temporary Global Admin” point to PIM, not a standard employee access package.
Assignment policies: who, how, how long
An access package can have one or more assignment policies (sometimes discussed as “policies for requesting access”). Policies define the request experience and lifecycle of assignments.
Requestor scope
| Scope idea | Meaning |
|---|---|
| For users in your directory (specific groups or all members as configured) | Internal employees / selected cohorts may request |
| For users not in your directory / connected organizations | External users from configured partner orgs (or broader external settings where allowed) |
| For specific connected organizations only | Partner A and Partner B can request; random internet users cannot |
| Direct administrator assignments only (no self-service) | Admins assign packages without a public request flow |
Exam cue: “Only Contoso and Fabrikam partner users may request Vendor Portal access” → package policy scoped to those connected organizations, not “all users in the world.”
Approval settings
Policies can require:
- No approval (auto-approve) — low risk, highly automated baselines only when justified.
- Single-stage approval — one approver or approver group (manager, resource owner, sponsor).
- Multi-stage approval — for example manager then application owner (detail in section 12.2).
- Fallback / alternate approvers — so requests do not stall when a primary is away.
- Justification text required from the requestor.
Approvers can be specific users, groups, requestor’s manager, or other policy-supported sponsor patterns depending on configuration.
Expiration, extensions, and access reviews linkage
| Policy element | Effect |
|---|---|
| Assignment expiration | Access ends after N days/hours or on a fixed date |
| Allow users to request extension | Requestor can ask to keep access before expiry |
| Require approval for extension | Extensions are not automatic free forever access |
| Access reviews on the package / assignments | Periodic attestation that users still need the package |
| Enable email notifications | Requestors and approvers stay informed |
Access reviews linkage is a frequent SC-300 pairing: entitlement management grants time-bounded package access; access reviews re-certify that the assignment should continue. You can configure reviews as part of package policy patterns so guest-heavy packages do not silently become permanent.
When an assignment expires or is denied on review, the user is removed from the package resources (groups/apps/sites) according to the governance engine—this is the operational win over “someone forgot to remove the security group member.”
Create and configure flow (end-to-end)
A complete SC-300 configuration story looks like:
- Plan packages and least-privilege resources.
- Create catalog → add groups, apps, SharePoint sites.
- Delegate catalog owners / package managers.
- Create access package → select resources and app roles.
- Add assignment policy → requestor scope, approval, duration, extension, review settings, optional ToU (next section).
- Publish / enable so eligible users can discover the package in My Access (myaccess portal experience).
- Test with a pilot user: request → approve → verify group/app/site membership → expire or remove → verify removal.
- Monitor requests, assignments, and audit logs; refine approvers and durations.
Admin assignment vs self-service
Not every assignment is a user click. Identity admins can directly assign a user to an access package (with a policy that allows admin assignment). Use direct assignment for HR-driven joiners, emergency project adds, or populations that should not self-request. Still prefer package assignment over raw permanent multi-group edits so expiration and reviews apply.
Common exam traps
- Confusing catalog (container) with access package (requestable entitlement).
- Forgetting resources must be in the catalog before a package can include them.
- Designing external packages without connected organization / requestor scope controls.
- Using packages to grant standing Global Administrator instead of PIM.
- Infinite duration with no reviews for high-risk guest packages.
- Expecting entitlement management to replace Conditional Access—packages grant membership; CA still enforces sign-in requirements.
Summary of section 12.1
A partner project needs contractors to receive membership in a security group, an enterprise app role, and a SharePoint site after manager approval for 60 days. Which Entra ID Governance approach best fits?
What is the primary purpose of a catalog in entitlement management?
An access package must be requestable only by users from two approved partner tenants, not by arbitrary external email domains. Which policy element is most important?
Which resource types can an access package commonly include for SC-300 entitlement scenarios?