Entra entitlement management access packages: start with a governed pilot

What Are Entra Entitlement Management Access Packages?

Entra entitlement management access packages turn a defined business task into a governed access request. A useful first package answers practical questions: which resources does this task need, who owns the decision, who may request access, and when should the assignment end? Start with a project whose resource owners can explain those answers and help test them.

Microsoft describes a package as a bundle of resource access governed by policies, held in a catalog. Groups, enterprise applications, and SharePoint Online sites are supported resources. Policies define eligibility, approval, and assignment duration. Catalogs provide a boundary for delegation. Packages can serve employees or external users. These concepts come from the Microsoft Learn entitlement management overview.

A missing package is a configuration observation to investigate. It does not establish that your organization has no access governance. You may already have a documented request service, resource-owner approval, and reliable removal procedures. Assess that process against the business need before deciding whether entitlement management would improve it.

How It Works: Scope the Governed Pilot

Consider a project team that needs a specific application role and access to project documents. This is an illustrative planning scenario, not a measured tenant finding. Write down the intended users, resources, permission levels, approver, and end condition before opening the wizard. Ask each resource owner to confirm that the proposed access is sufficient for the task and no broader than necessary.

Keep the pilot narrow enough that you can explain every included permission. Avoid bundling unrelated access simply because those resources appear in the same department. Record the person responsible for maintaining the package and the person responsible for each resource. Those responsibilities may belong to different people; the handoff matters when a resource changes or a project ends.

The overview explicitly positions packages alongside other assignment mechanisms. They fit time-limited tasks, approval-driven access, and collaboration scenarios; they do not replace every existing assignment method. Compare your pilot with ordinary group membership and the existing service request process. Choose the mechanism that lets the owner approve the right access and demonstrate its removal. Microsoft Learn: when to use access packages.

Dynamic membership and governed access also answer different operational questions. Attribute-based selection can identify a population, while a package policy addresses how that population receives a particular entitlement. Our memberOf operator retirement article discusses dynamic membership and entitlement management auto-assignment dependencies. Use it to review existing assignment logic before designing a request-based pilot, without assuming a group-rule migration supplies approval or expiration evidence.

Check Licensing and Administrative Prerequisites

The Learn overview's license requirements name Microsoft Entra ID Governance or Microsoft Entra Suite for organizational users and state that some capabilities can operate with Microsoft Entra ID P2. Treat this as a feature-specific licensing check, rather than a universal instruction to purchase a particular subscription.

The Governance licensing fundamentals table lists user self-service requests, groups, applications, SharePoint sites, manager or specific approvers, and assignment expiration under P2 as well as Governance and Suite. Auto-assignment policies and user-profile sponsors as approvers require Governance or Suite in that table. Governance products also have prerequisite subscriptions; guest governance has separate billing considerations. Verify the intended capabilities and eligible population against the current Learn documentation before enabling the pilot. Do not infer entitlement from the mere presence of a license somewhere in the tenant.

Keep your first test focused on human users and ordinary project resources. If you later add advanced features, revisit licensing and delegated permissions rather than carrying forward the pilot's assumptions. Record the licensing decision beside the package design so the next owner can understand which choices were deliberate.

Detection: Establish Whether Packages Are Absent

In the Microsoft Entra admin center, inspect ID Governance > Entitlement management > Access package, the path documented in the creation guide. Confirm the directory and your visibility before interpreting an empty view. Save the observation date, observer, and scope with the inventory.

For an API inventory, Microsoft documents the following request in List accessPackages:

GET https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/accessPackages

The API returns packages the caller can read across catalogs. The permissions table lists EntitlementManagement.Read.All as the least privileged OAuth permission for delegated and application access; delegated callers also need a supported role. For app-only callers, Microsoft also supports assigning an appropriate role instead of that application permission; Catalog reader is a less privileged option. Catalog-specific access can restrict what the caller sees. A successful empty response therefore supports a tenant-wide absence conclusion only when the collection scope covers the tenant's catalogs. Complete the enumeration, including any continuation link returned, before recording an inventory as complete.

The Graph accessPackage resource documentation describes the package's catalog, assignment policies, and resource-role relationships. Listing package objects is an existence check; separately inspecting those relationships is necessary to assess whether a package represents the intended access.

The request above is a documented inspection method, not a query executed against a customer tenant for this article. Retain the actual status, collection scope, and response from your authorized audit. An authentication error, authorization error, interrupted run, or unverified scope belongs in the evidence as a collection limitation. None supports writing “no packages configured.”

Remediation: Create the Package and Prove Its Lifecycle

1. Select the Catalog and Resource Roles

Follow the Learn creation workflow: select New access package, enter its name and description on Basics, and choose its catalog. Identity Governance Administrator, catalog owner, or access package manager can create packages within their authorized scope. Access package managers use resources already in the catalog; they cannot add resources to it. On Resource roles, select the intended resources and roles.

Choose the catalog deliberately and name its accountable owner in your pilot record. Use a description that lets a requester recognize the business task. Have the resource owners review the selected roles before continuing. A group owner role is materially different from membership, and an application administrator role may be unnecessary for ordinary project work. Review the actual permission, not just the resource's display name.

2. Define Requesters and Approvers

On Requests, configure the initial policy's eligible users and approval settings. Require approval for the pilot, choose the designated approver, and require request justification. If using the manager option, configure a fallback for missing manager information. Under Who can request access, select Self for this user-requested pilot. These controls are documented in the creation guide's approval settings.

Prefer a clearly defined pilot population over a broad request scope. Ask the approver what information they need to make a decision and whether they can recognize an inappropriate request. Test with an eligible user and an out-of-scope user. Record the expected decisions before the test so you can distinguish a policy defect from a misunderstood requirement.

For external collaboration, also review guest Conditional Access and external collaboration settings. That article addresses guest sign-in protection, invitations, visibility, and lifecycle controls. Use it to frame the external population's surrounding controls; package approval alone does not document that broader review.

3. Configure Expiration Before Creating the Package

On Lifecycle, select an assignment expiration by date or duration and decide whether extensions are allowed and require approval. Review the configuration on Review + create, then select Create to create the package and initial policy. These are the documented creation steps.

Choose the end condition from the task's business timeline. For the pilot, use a test assignment that can reach its scheduled expiry during your verification window. Agree that timing with the resource owner. Document how legitimate extensions will be handled and who will decide them. Avoid leaving a permanent assignment merely because testing expiration takes more coordination.

4. Verify Delivered Access, Then Expired Access

Microsoft's assignment management guide documents Assignments, individual assignment details, and the Delivering and Expired status filters. Delivery errors can be investigated through the corresponding entry on Requests. Use those views to collect evidence of the test assignment's actual state.

Submit the pilot request through its configured approval route. Record the requester, selected policy, decision, assignment identifier, and intended end time. Verify that the test user receives the intended resource role and can perform the allowed task. Also test a meaningful operation the user should not be allowed to perform. A successful sign-in by itself says little about whether the assigned role is appropriate.

After the scheduled expiry, capture the expired assignment and check the resource access again. Compare membership, application assignment, and the user's ability to perform the task with the earlier evidence. If access remains, investigate other grants before claiming the package failed or that expiry removed all effective access. The same user may have a separate entitlement that your pilot was never meant to remove.

Keep both observations in the pilot record. “Package created” is a setup milestone; “approved access delivered, then its assignment expired and the intended resource access was withdrawn” is the verification outcome you are trying to establish. This article does not claim that such a test has already passed in any tenant.

How EtcSec Detects This

EtcSec's etc-collector detector AZ_ENTITLEMENT_MANAGEMENT evaluates collected package existence through AzureAccessPackagesProbed and AzureAccessPackagesCount. The inspected Detect() has these branches:

The finding's Count: 1 is the tenant-level finding count, not a count of affected users or missing policies. A nil result does not validate resource selection, approvers, request scope, licensing, expiration, or removal. The detector checks existence, not policy quality. An absence finding also does not prove that every alternative governance process is missing.

Use the result to open the appropriate investigation: collection coverage for Info, a business and licensing assessment for Medium, and a separate lifecycle review when packages already exist. Retain the pilot's delivery and expiry evidence alongside the audit so the next review can distinguish a cleared existence finding from demonstrated access governance.