Access packages in Entra ID Governance: granting and removing access in a way you can prove

In most organisations, access rights grow faster than anyone removes them. A new employee receives a copy of a colleague’s rights, a project site stays open after the project ends, and a partner account from three years ago can still sign in. Nobody notices until an auditor asks who approved a particular access and whether it is still needed.

This article explains how access packages in Microsoft Entra ID work, how they interact with access reviews, Lifecycle Workflows and Privileged Identity Management (PIM), and which licence each function needs. It is written for companies with 50 or more employees. All statements reflect the status as of October 2026.

Why do access rights keep growing?

Access is usually requested by email or ticket and granted by IT directly on a group or application. Removal depends on someone remembering. People who change departments keep their old rights, and guests stay in the tenant after the collaboration ends.

For the board, this is a question of evidence. ISO/IEC 27001:2022 requires in control A.5.18 that access rights are provided, reviewed, adjusted and removed according to a defined policy. NIS2 requires risk management measures that include access control policies. Whoever signs off on information security has to show that access is approved, limited in time and reviewed regularly.

What is an access package?

An access package is a bundle of the resources a person needs for a task or role, together with the rules that govern access to it. It is part of entitlement management in Microsoft Entra ID Governance. An access package can contain:

• membership of security groups, Microsoft 365 groups and Teams
• assignments to enterprise applications, including SaaS applications with single sign-on
• membership of SharePoint Online sites
• Microsoft Entra roles (preview as of October 2026, Entra ID Governance licence required)

Other resources can be covered through groups: a group in a package can carry an Azure role assignment or a group-based licence.

Access packages sit in catalogs, which are also the unit of delegation. A department can own its catalog and define its own packages without becoming an administrator, but it can only add resources it owns.

How do policies control who gets access?

Each access package has one or more policies that define who may request it, who approves and how long access lasts:

• Requestors: specific users or groups in your directory, or users from connected partner organisations.
• Approval: none, or one to three stages. Approvers can be the requestor’s manager, named people or groups, or sponsors for partner users, with fallback approvers if no manager is found. Requests that are not decided in time are denied automatically, and nobody can approve their own request.
• Expiry: on a fixed date, after a number of days or hours, or never. If extensions are allowed, users are notified 14 days and one day before expiry, and an extension can require a new approval.
• Separation of duties: packages can be marked as incompatible, so nobody holds two conflicting packages at once.

Users request access through the My Access portal. Request, justification, approval and assignment are recorded, which is the evidence auditors ask for.

How do access packages work with access reviews?

Expiry removes access that nobody renews. Access reviews cover access that is meant to last longer. A policy can require a recurring review of all assignments, monthly, quarterly, every six months or annually, by the users themselves, their manager or named reviewers. If results are applied automatically, denied access is removed at the end of the review. A separate setting decides what happens when reviewers do not respond: no change, removal, approval or the system’s recommendation based on sign-in activity.

Packages without an expiry date need a regular review at a minimum, and for packages that include external users, quarterly is a sensible default.

How do Lifecycle Workflows cover joiners, movers and leavers?

Lifecycle Workflows automate tasks along the employment lifecycle and use access packages as building blocks:

• Joiner: a task requests the standard packages for the new employee’s role.
• Mover: the template for a change of job profile triggers on attribute changes such as a new department. By default, it schedules removal of all existing package assignments after 15 days and requests the packages for the new role.
• Leaver: tasks remove all package assignments and cancel pending requests.

The workflows depend on accurate attributes in Entra ID, typically supplied by an HR system. If department or manager are wrong, the workflows act on wrong data. Lifecycle Workflows require a Microsoft Entra ID Governance licence.

Where does Privileged Identity Management fit in?

Access packages handle everyday access. PIM handles administrative roles: a person is eligible for a role and activates it only when needed, for a limited time and, if required, with approval. With an Entra ID Governance licence, an access package can grant eligible membership of a PIM-managed group instead of permanent membership. Access reviews of PIM for Groups, in preview as of October 2026, can recertify these assignments.

How are guests and external partners handled?

Partner organisations are set up as connected organisations. Their users request a package through a direct link to the My Access portal and receive a guest account once approved. When a guest’s last package assignment ends, the account is blocked from signing in by default and removed after 30 days; both settings can be changed. This keeps guest accounts from piling up, provided guests come in through access packages and not through direct invitations.

Which licence do you need?

The details are on the Microsoft Learn page Microsoft Entra ID Governance licensing fundamentals. As of October 2026:

• Microsoft Entra ID P2 (standalone or in Microsoft 365 E5): access packages with groups, Teams, applications and SharePoint sites, multi-stage approval, expiry, separation of duties, lifecycle of external users, the established access review functions and PIM.
• Microsoft Entra ID Governance (add-on to Entra ID P1 or P2, also included in the Microsoft Entra Suite and Microsoft 365 E7): additionally Lifecycle Workflows, automatic assignment based on attributes, managers requesting on behalf of their employees, Entra roles and eligible PIM group memberships in access packages, custom extensions and reviews of whole catalogs.

No new identity governance functions will be added to Entra ID P2. Licences do not have to be assigned to individual users, but there must be enough to cover all member users in scope. Governance of guests is billed per monthly active user through an Azure subscription.

How do you introduce access packages in five steps?

1. Clarify ownership. For each group, application and site in scope, record who decides about access.
2. Start small. Pick a handful of frequent requests, such as a department application, a project site or partner access, and build packages for these first.
3. Define policies. Requestors, approvers with fallback, expiry and, for longer-lived access, a recurring review. Document the rules so they can be shown in an audit.
4. Move existing access. Transfer direct memberships into package assignments and remove the direct paths, otherwise two ways to get access remain and only one is controlled.
5. Connect the lifecycle. Once HR attributes are reliable, link packages to Lifecycle Workflows and report review results to management regularly.

What are the typical mistakes?

• One package per group. This produces hundreds of packages and no clarity. A package should reflect a task or a role.
• “Never” as expiry, without reviews. The package then documents how access was granted, not whether it is still needed.
• Missing manager attributes. Requests stall or go to fallback approvers who cannot judge them.
• Reviews without automatic application. Reviewers decide, but nothing changes in the tenant.
• Reviewing groups synchronised from Active Directory. Entra ID cannot change their membership, so review results are not applied there. The same applies to access granted through nested groups.

What does this look like in practice?

In a public authority with 40,000 users, we combined access packages with access reviews that recertify groups, roles and access packages, Lifecycle Workflows for joiners, movers and leavers, and a PIM role model with just-in-time activation and approval for Entra roles and groups. The case study on identity governance for a state police authority describes the full mandate.

The next step

An architecture review shows where access in your tenant grows without control and which licence your target model needs. How we approach identity and access architecture is described on our Security Architecture page.

Book an introductory call

Frequently Asked Questions

Is Entra ID P2 enough, or do we need Microsoft Entra ID Governance?

For access packages with groups, applications and SharePoint sites, approval, expiry and access reviews, Entra ID P2 is sufficient as of October 2026. Lifecycle Workflows, automatic assignment based on attributes and Entra roles in access packages require Microsoft Entra ID Governance.

What is the difference between an access package and a group?

A group grants access. An access package adds the rules around it: who may request it, who approves, when it expires and when it is reviewed. One package can include several groups, applications and sites.