Entitlement Management access packages

Microsoft Entra Entitlement Management lets you bundle access to apps, groups, SharePoint sites, and Teams into access packages that users can request through a self-service catalog. Each package has policies — who can request, who approves, how long access lasts, recertification — making complex access requests manageable at scale.

Access packages are one of the four capabilities in Entra ID Governance, alongside access reviews and Lifecycle Workflows; for external users they build on B2B guest access and cross-tenant access settings.

What goes into an access package

An access package combines:

• Microsoft Entra ID groups — security groups, Microsoft 365 Groups.
• Microsoft 365 apps — Teams (via group), SharePoint sites (via group).
• Enterprise applications — SaaS apps integrated with Entra ID via SSO.
• Multiple roles within an app (where the app supports it).

A package isn't a permission set per se; it's a bundle of group memberships and app-role assignments that gets granted when the request is approved.

Use cases

Onboarding by role

Create an access package per role — "Sales Representative," "Software Engineer," "HR Business Partner." When a new hire is requested into the role, the access package grants them everything they need: relevant groups, Teams, SharePoint sites, Salesforce, JIRA, ServiceNow, etc.

For HR-system-driven provisioning, the access package is requested automatically as part of the joiner workflow.

Project-based access

For project staffing — "Project Phoenix Team Member" — the access package grants access to the project's resources, with automatic expiration at project end. No more orphaned access after the project closes.

External partner access

For ongoing partnerships — "Acme Corp Vendor Partner" — the access package handles the joining of partner organisation users as B2B guests, with appropriate group memberships and resource access.

Compliance recertification

Access packages with periodic access reviews force recertification — every 6 months, the user's manager confirms they still need this access. Catches the slow drift problem.

Configuration

In Entra admin center → Identity Governance → Entitlement management → Access packages:

1. Create the package with name and description.
2. Add resources — groups, apps, SharePoint sites.
3. Configure policies:
   • Who can request — specific users, groups, anyone in the directory, external users.
   • Approver(s) — manager, named approver, self (auto-approved).
   • Required questions — justification fields the requester must fill.
   • Duration — permanent, fixed days, time-bound.
   • Access reviews — schedule and reviewers.
4. Publish to the catalog — users see it in myaccess.microsoft.com.
5. Approve or auto-approve requests as they come in.

The user experience

Users go to myaccess.microsoft.com and see a catalog of available packages. Pick one, fill in the justification, submit. Approver gets a notification, approves or denies. Access is granted within minutes; emails confirm what was granted.

For most non-IT users, this is dramatically better than "email IT for access to X."

Operational considerations

• Catalog organisation — group access packages into catalogs for navigation (one per department, one per type).
• Naming — descriptive names. "Sales — Standard Access Package" vs "AccPkg2".
• Owners — every access package has an owner accountable for maintenance.
• Audit — every grant, approval, and revocation is logged.
• Recertification — access reviews are essential; don't grant indefinite access without review.

When access packages aren't the right tool

• One-off ad-hoc requests — too much overhead vs just adding the user to a group.
• Privileged admin role assignment — use PIM instead.
• Very simple flat directories — minimal benefit over direct group assignment.

Licensing

Entitlement Management requires Microsoft Entra ID Governance licensing, sold separately from base Entra ID (often included with Microsoft 365 E5).

For organisations with significant access-management complexity — many roles, many apps, many users, partner relationships — access packages are how this becomes maintainable. The investment in designing the right package taxonomy pays back continuously.

Package taxonomy: the design decision that scales or doesn't

The single design decision that separates catalogues that work at 100+ packages from ones that collapse under their own weight is the shape of the taxonomy. Two viable patterns:

• Role-based packages, one per job family. Sales Associate — Standard, Sales Associate — Manager, Software Engineer — Backend. New joiners request the package matching their role; the package bundles everything a person in that role needs. This scales when roles are stable and the HRIS knows them.
• Capability-based packages, composed at request time. Access to Salesforce, Access to JIRA — Developer, Access to Finance SharePoint. Users request the specific capability they need. This scales when roles change often and everyone's access mix is bespoke.

Do not mix the two. A catalogue with both role packages and capability packages ends up granting overlapping access, and access reviews become impossible to interpret.

Owner and catalog structure

Two axes matter more than the marketing implies:

• Catalog per business owner — Sales catalog owned by the Sales operations team, HR catalog owned by HR ops. The catalog owner grants delegated management of the packages inside; central IT is not a bottleneck for adding a new SharePoint site to a Sales package.
• Package owner is a role, not a person — a group like AC-Owners-SalesCatalog with 3–5 named members. Sole-person ownership is the top reason a package quietly rots when the owner leaves.

Common wrong turns

• Making every access request an access package. Some requests are genuinely one-off. If a package would be requested by one person, ever, use direct group assignment.
• Skipping access reviews. A package with permanent access and no review is a group with more ceremony. The review is the point.
• Assuming the requester writes good justifications. Free-text justification questions turn into access needed. Use dropdowns for the answers a compliance auditor will actually ask about (project name, manager, end date estimate).
• Approving without reading. A manager clicking approve on 40 requests in a batch is a control that does not work. Use groups of approvers and require multi-stage approval for sensitive packages.
• Ignoring the myaccess.microsoft.com experience. Users experience the catalog through that portal; if the package names, descriptions, and questions are cryptic, users bounce out and email IT instead.

Signals worth watching

• Requests rejected, by package — high rejection rate means the package is available to too broad an audience, or the description does not set expectations.
• Time-to-approval, by approver — chronically slow approvers are where access requests get abandoned.
• Access reviews with 100% approve — either the review is a rubber stamp, or the package really is right for everyone; investigate which.
• Packages with zero requests in 90 days — retire or repurpose. A stale catalog dilutes the useful parts.