How to Implement Multi-Stage Approval for High-Privileged Entra Roles Using Entitlement Management and PIM

When customers start using Microsoft Entra Privileged Identity Management (PIM), one of the first questions that comes up is:

“Can I enforce more than one approval before someone activates a Global Admin or another highly privileged Entra role?”

It is a fair question.

Native PIM for Microsoft Entra roles gives us excellent controls such as just-in-time activation, MFA enforcement, approval, justification, notifications, and auditability. But when it comes to approval workflow depth, many organizations quickly notice a limitation: they want multi-stage approval, not just a single approval checkpoint for privileged role activation.

This is especially common in regulated environments where access to roles like:

• Global Administrator
• Privileged Role Administrator
• Conditional Access Administrator
• Security Administrator

must pass through more than one control gate, such as:

• Requestor’s Manager
• IT Security / CISO
• Identity or Platform Admin team

The good news is that Microsoft Entra can support this requirement , not directly inside PIM role activation itself, but by combining Entitlement Management and PIM for Groups in the right way.

The Core Idea

Instead of assigning a privileged Entra role directly to a user, you:

1. Create a role-assignable group
2. Assign the privileged Entra role to that group
3. Bring that group under PIM for Groups
4. Use Entitlement Management to grant users eligible membership to that PIM-managed group
5. Configure the access package with multi-stage approval
6. After approval, the user becomes eligible for the group
7. The user then goes to PIM and activates the group membership with MFA and PIM controls
8. Because the group is already assigned to the privileged Entra role, the user receives the privileged access only during the activation window

This gives you a practical two-layer control model:

• Layer 1: Multi-stage business/security approval through Entitlement Management
• Layer 2: Just-in-time activation with MFA and PIM controls through PIM for Groups

That combination is the real magic.

Why This Pattern Matters

This design solves a common governance gap.

PIM is excellent at controlling how privileged access is activated, but some organizations need a stronger process before the user even becomes eligible to activate. Entitlement Management fills that gap because it supports multi-stage approvals, approver justification, requestor justification, lifecycle controls, and expiration. 

So instead of relying on one approval event at the moment of elevation, you separate the process into two checkpoints:

Checkpoint 1: Should this person be allowed to request privileged access eligibility at all?

Handled by Entitlement Management with 2-stage or 3-stage approval. 

Checkpoint 2: Now that the user is eligible, can they activate right now?

Handled by PIM for Groups with MFA, activation duration, approval settings, and notifications.

This is much closer to how security teams think in the real world.

Important Reality Check Before You Implement

There is one critical point to understand.

Microsoft has updated their guidance around Entra roles in access packages. Microsoft now says that Entitlement Management will only allow access packages to contain Entra roles that don’t have privileged permissions, and that roles with privileged permissions should be managed through PIM.

That means the better and safer pattern is not:

• Access Package → directly assign Global Admin

Instead, the recommended design is:

• Access Package → grant eligible membership to a PIM-managed group
• Group → assigned to the privileged Entra role
• User → activates group membership through PIM

This aligns with current Microsoft direction. 

Multi Stage Approval Flow

1. A user requests access to a privileged access package from My Access
2. Stage 1 approver reviews it, for example the user’s manager
3. Stage 2 approver reviews it, for example Security / CISO
4. Optionally Stage 3 approver reviews it, for example Identity team lead
5. Once approved, the user gets eligible membership to a privileged group
6. That group is already assigned to a privileged Entra role
7. The user opens PIM and activates the group membership
8. PIM enforces MFA and activation duration
9. During that activation window, the user receives the effective Entra privileged role
10. When PIM activation ends, privileged access is removed automatically
11. When Access Package Expires Privileged Group Membership will be completely removed

Logical Design

Prerequisites

Before implementing this design, ensure you clearly understand all dependencies.

Microsoft Entra Licensing

A minimum of Microsoft Entra ID P2 license is required to use Privileged Identity Management (PIM) and Entitlement Management.

Alternatively, you can leverage Microsoft Entra ID P1 combined with the Entra Identity Governance add-on to achieve full governance capabilities.

You can also opt for the Microsoft Entra Suite, which includes all Entra ID features and is expected to be part of the Microsoft 365 E7 offering starting May 2026.

Role-assignable group

If a group will hold a Microsoft Entra role, it must be created as a role-assignable group by setting the group as eligible for Entra role assignment at creation time. This setting is immutable, and you cannot convert an existing group later.

Appropriate admin roles

To create and manage role-assignable groups and privileged access group settings, the implementing admin typically needs at least Privileged Role Administrator or another appropriate privileged role depending on the task.

PIM for Groups enabled for the target group

The group must be brought under PIM for Groups management before you can use eligible group membership via access packages. Once a group is managed by PIM, Please note that it cannot simply be taken back out of management. 

Once a group is managed, it can't be taken out of management. This prevents another resource administrator from removing PIM settings. If a group is deleted from Microsoft Entra ID, it can take up to 24 hours for the group to be removed from the PIM for Groups option.

Step-by-Step Practical Implementation

Step 1 Create a Role-Assignable Group

Create a new security group in Microsoft Entra ID.

While creating the group, make sure to enable “Microsoft Entra roles can be assigned to the group” = Yes.

⚠️ This setting is permanent and cannot be modified after the group is created.

As a best practice, use a clear and consistent naming convention that reflects the purpose of the group. For example:

• GRP-ELIG-GlobalAdmin
• GRP-ELIG-PrivRoleAdmin
• GRP-ELIG-SecAdmin

Step 2 Bring the Group Under PIM for Groups

Once the group is created, navigate to the Privileged Identity Management (PIM) section for the group and click “Enable PIM for this group.”

Read more about PIM for Group in my Blog Exploring Microsoft Entra ID Privileged Identity Management (PIM) Part-3/3 (Groups & Access Review)

Once a group is managed by PIM, it remains under that management model unless the group is deleted.

At this point, the group becomes your Privileged Access Group.

Step 3 Assign the Privileged Entra Role to the Group

Assign the required Entra role to the newly created group, for example:

• Global Administrator
• Privileged Role Administrator
• Security Administrator

Microsoft Entra ID supports assigning Entra roles to role-assignable groups so that users can receive the role indirectly through group membership.

This is the backbone of the design.

Open the group, go to Assigned roles, and click Add assignments.

In this example, I will assign the Global Administrator role to the group.

Now we need to configure the role assignment settings for the group.

In my case, I will set the assignment type to Eligible and keep the eligible duration as Permanent. This is because, as mentioned earlier, users who become members of the group should activate the role only when required.

If your requirement is to have the role activated automatically once the access package is approved, you can choose the assignment type as Active.

In this example, the user must explicitly activate the role after their access package is approved.

After assigning the role, you will see the Global Administrator role listed under Eligible role assignments for the selected group.

You can also configure Entra role settings to control how long a role remains active after activation, along with additional activation requirements.

I’ve covered these configurations in detail in my blog: Exploring Microsoft Entra ID Privileged Identity Management (PIM) Part-1/3 (Microsoft Entra Roles).

Step 4 Create Dynamic Group for Access Package Assignments

Now let’s create a Microsoft Entra ID dynamic group based on user attributes to automatically assign the access package to members, without requiring any manual admin effort to add users to the group linked to the access package.

In my lab, I’m using a dynamic group, but you can choose either static or dynamic based on your requirement. For full automation, I strongly recommend dynamic groups. This ensures that whenever a user’s attribute (such as department or job role) changes, the group membership is automatically updated, and the access package is assigned or removed accordingly ,eliminating the need for manual updates.

In this example, I will use the user’s Job Title attribute for dynamic membership selection.

To achieve this, go to Microsoft Entra ID and create a new Security Group.

While creating the group:

• Set Membership type to Dynamic User

• Then define and add the dynamic membership rule (query) based on your required user attributes.

Now we are ready with creating the Group for assigning access package

Step 5 Create an Access Package

Now this is a crucial step in our multi-stage Entra role approval flow , creating an Access Package and configuring multi-stage approval, package expiration, and lifecycle settings.

Create a dedicated access package with a meaningful name, for example:

• M365 Administrator Access Package
• AP – Global Admin Eligibility Request

Choose a naming convention that clearly reflects the purpose of the access package.

To create an access package in the Microsoft Entra ID Admin Center, navigate to the Identity Governance section and open Entitlement Management.

Then:

• Click on Access Packages
• Select New Access Package to create a new one.

Provide a Name and Description for your access package.

If you have already created a specific catalog, you can select it. Otherwise, you can use the default General catalog. In my case, since this is a lab/test setup, I will proceed with the General catalog.

Understanding Catalogs in Microsoft Entra Entitlement Management

A catalog is a container used to group related resources (such as groups, applications, Roles and sites ) along with access packages. It helps organize and delegate access management effectively.

Key points about catalogs:

• Container for Access Packages : Every access package must be created within a catalog.

• Organization & Security Boundaries : Catalogs provide clear separation, allowing different teams or departments to manage their own resources securely.

• Delegation of Management : Administrators can assign catalog owners or managers, enabling business users (non-IT) to manage access policies.

• External Access Control : Catalogs can be configured to allow or restrict access requests from external users.

• Built-in Catalog : A default “General” catalog is available if no custom catalog is created.

• Supported Resource Types: A catalog can include:

• Microsoft Entra security groups
• Microsoft 365 groups
• Enterprise applications
• SharePoint Online sites
• Microsoft Entra roles (Preview)
• Custom data resources (Preview)

Using catalogs properly helps you build a scalable and well-governed access management model.

Once you click Next, the Resource roles section will appear. Here, you can select the resources to include in your access package, as highlighted earlier.

In our case, we will select the Entra role–assigned group we created earlier, i.e., Global-Administrator-Group.

Once you select the desired group, choose the role type as Member.

We are not selecting Eligible here because the purpose of this membership is to allow users to activate the Entra role. The role itself is already configured as Eligible for this group.

The next section is Configure access package request settings.

Here’s how to configure it:

• Who can get access

Select “For users, services, and agent identities in your directory”, since this access package is intended for internal admin users.

• Assignment scope

Choose “Specific users and groups”, then select the dynamic group we created earlier. This ensures automatic assignment based on user attributes.

• Who can request access

Select “Self”, allowing users to request access themselves.
By default, Admin is also selected. If needed, you can enable Manager so that a user’s manager can request access on their behalf.

Under Requests, we have additional configurations—this is where we define the approval workflow, which is a key part of our setup.

Configure Approval Settings

• Set Require approval to Yes
• Set Require requestor justification to Yes

Approval Stages

• Choose Number of stages = 2 (maximum supported is 3)

Stage 1 Approval

• Approver: Select Manager
• Fallback approver: Configure an alternative approver in case the manager is unavailable
• Decision time: Set to 1 day (range: 1–14 days)
• Require approver justification: Yes

Stage 2 Approval

• Approver: Select Specific approvers
• Add relevant users such as IT Manager, CISO, or other stakeholders
• You can configure multiple approvers if required
• Decision time: Set to 1 day (range: 1–14 days)
• Require approver justification: Yes

This completes the multi-stage approval configuration for the access package.

That is a very important behavior to understand:

• Multiple people inside the same stage do not all need to approve
• But each stage must complete before the request moves forward 

Additionally, you can configure email notifications, where you have the option to disable assignment-related emails if required.

If Microsoft Entra Verified ID is enabled in your tenant, you can also require users to verify their identity before requesting access. This can include facial verification and government-issued ID validation, providing a higher level of assurance, especially useful for remote users requesting access to highly privileged roles.

Next is configuring Requestor information, which is completely optional.

In my case, I’ve added a custom question to capture the requester’s ITSM ticket number before they submit the access request. This helps approvers cross-verify the request, especially when there is no direct ITSM integration in place.

You can use this section to collect any relevant information using different formats such as:

• Short text
• Long text
• Multiple choice

You can also mark each question as required or optional based on your needs.

Once configured, click Next to proceed to the Lifecycle settings of the access package.

In the Lifecycle settings, configure the expiration for access package assignments.

Since this is for Entra role assignments, I will set the assignment expiration to 8 hours.
All other settings can be left as default.

Then click Next to proceed to configure any custom extensions, if required.

A strong design is:

• Access package assignment eligibility valid for a limited time
• User must renew through the same business/security approval process
• Activation remains JIT through PIM

This keeps standing privileged eligibility from becoming permanent by accident.

Since we don’t have any custom extensions to configure for this multi-stage setup, we will simply skip this step

Finally, review the access package configuration and click Create to complete the setup.

Once the access package is created, you can review and modify its settings as needed from the Entitlement Management section under Access Packages.

If you navigate to the Policies section, you can modify the access package policy that was configured during the package creation.

Entra Access Package User Request Experience

Now let’s explore the end-user journey.

The user signs in with their Microsoft Entra ID account, navigates to https://myaccess.microsoft.com , and then selects Access Packages to begin the request process. If you are not seeing anything in Suggested Access Package click on View All to see all Access Package available to you.

Now the user will see the available access package. After reviewing the name and description, then you can click Request to proceed.

Once you click Request, you will be prompted with the request details.

Here, you can see:

• Requesting for: Myself
• An option to copy the access package link
• The Resources tab to review what is included in the access package

After validating the details, click Continue to proceed with the access package request.

Once you click Continue, you will be prompted to provide additional details:

• Answer the custom question configured in the access package (e.g., ITSM ticket number)
• Provide a business justification for the request

After entering the required information, click Submit Request to proceed.

After submitting the request, you can track its progress in the Request History tab.

Here, you’ll be able to see the current status of your request and where it stands in the approval process.

Now you can see that the access package request will not add the user to the Entra role–assigned security group until the entire approval process is fully completed.

Entra Access Package Approval Experience

Now let’s look at the approval experience for the access package.

Stage-1 Approval

In this example, the user’s manager signs in and navigates to the My Access portal. On the overview dashboard, they will see a pending request awaiting their action.

From there, the manager can click Approve or Deny to proceed with the next step.

Once the manager opens the request, they can view the access request details, including:

• Request details
• Access package details
• Approval history

Based on this information, the manager can decide to Approve or Deny, provide a reason, and then submit their decision.

Approval history

Manager Approving the Request

Once approved, the approver can track the approval status and the next stage in the process by navigating to the Approvals section in the My Access portal.

Stage-2 Approval

Now we are at Stage 2 of the approval process.

Once the second approver signs in to the My Access portal, they will see the request in a pending state, since the first approver has already completed their part.

Similar to the first approver, the second approver needs to follow the same steps , review the request details and then approve or deny the request accordingly.

At each stage, approvers will receive email notifications whenever a request is submitted and requires their approval.

Now the second approver can view the previous approval status and details. After completing the review, they can proceed with their approval or denial decision.

The second approver reviews the request and proceeds to approve it, providing the required justification before submitting.

Approval Completed from the Second approver

If an admin navigates to the Microsoft Entra ID portal → Identity Governance → Entitlement Management → Access Packages, and selects the specific access package, they can open the Assignments section.

Here, the admin can:

• View active assignments and their status
• Assign the access package to users directly
• Remove assignments if needed
• Revoke access as an administrator at any time

If an admin navigates to the Requests section, they can view complete request details, including the approval status and history.

They also have the option to delete requests if required.

Entra Access Package Role Activation Experience

Now that all approval stages are completed, the user can see the access package in their Access Packages tab as Active, along with the start date and end date.

In the Actions tab, they will also have an Extend option (if enabled by the admin), allowing them to request an extension when the access package is nearing expiration.

The user will also receive an email notification confirming that they have been granted access to the access package, typically with a message like: “You have received access to [Access Package Name].”

Now, if the user navigates to their Entra roles page , either through the Microsoft Entra portal (Privileged Identity Management) or via the Azure portal by searching for Privileged Identity Management ,they can go to My roles.

Here, the Entra role assigned through group membership will be visible under Eligible role assignments.

The user can click Activate and proceed with Entra PIM role activation by specifying the activation duration.

In our case, the Global Administrator role is assigned as Eligible through the group(Using Access Package). The role activation settings are configured with a maximum duration of 4 hours, which is less than the access package assignment duration.

Note: If the access package assignment duration exceeds the “Expire eligible assignments after” setting configured in the PIM-managed group, it can create a mismatch between Entitlement Management and Privileged Identity Management (PIM).

As a result, users may lose their eligible role access in PIM while Entitlement Management still shows the assignment as active, leading to inconsistent access behavior.

During activation, the user is required to provide justification and complete MFA. No additional approval is enabled at this stage.

The role is now successfully activated.

The user will also receive an email notification confirming that the role has been successfully activated.

Now we can see that the user has the Global Administrator role listed under Active assignments, with the end time set exactly 4 hours from the activation time, as per the configured role settings.

Now, if we validate the group from which the assignment was granted, we can navigate to the My Groups page and verify the group membership assignments.

What This Gives You in Practice

This pattern gives customers several real advantages.

1) True multi-stage governance before privilege eligibility

Entitlement Management supports 2-stage and 3-stage approval, which PIM role activation alone does not provide.

2) JIT activation still remains in PIM

Privileged access is not permanently active. The user still has to activate when needed.

3) Better separation of duties

Managers can approve business need, security can approve risk acceptance, and identity admins can retain technical control.

4) Cleaner audit story

You now have two auditable events:

• Access package request and approval trail
• PIM activation trail

5) Safer alignment with Microsoft direction

Privileged roles are still controlled through PIM rather than directly through access packages.

Key Design Considerations and Limitations

No design is perfect, and this blog should be honest about that.

It is a two-step user experience

The user must:

• first request package access
• then separately activate in PIM

That means this is more secure, but not as simple as direct activation.

PIM approval is still single-stage

Even for groups, Microsoft recommends selecting two or more approvers, but the request is resolved by the first approver who acts, and the approval window is 24 hours.

You must create a new group correctly from the beginning

Role-assignable group status cannot be added later to an existing group.

Role-assignable groups have guardrails

They must be Assigned membership, not dynamic, and there is a tenant maximum of 500 role-assignable groups.

Don’t confuse package approval with full privilege activation

Approval to the access package only makes the user eligible for the privileged group. The user does not get always-on Global Admin access from that step alone.

That distinction is critical.

Recommended Best Practices

For production environments, I would recommend the following.

Use dedicated privileged groups per role

Do not overload one group with many high-risk roles unless there is a strong governance reason.

Keep package assignment time-bounded

Eligibility should expire and require renewal.

Require justification both at request and activation

This gives better audit context for security investigations. Access Package supports requestor justification in access packages and business justification in approvals.

Use at least two approvers in PIM where approval is enabled

Microsoft recommends selecting two or more approvers for PIM group approval to reduce dependency on one person.

Use access reviews

Especially for privileged groups and long-running eligibility. Entra ID supports access reviews as part of identity governance.

Prefer dedicated admin accounts

This remains a general privileged access best practice and fits well with this model.

When to Use This Pattern

This architecture is ideal when the customer says any of the following:

• “PIM approval is not enough for our regulated environment”
• “Global Admin access must be approved by manager and security”
• “We want role eligibility to go through a formal approval chain”
• “We want JIT access but with stronger governance before activation”
• “We need separation between business approval and technical elevation”

When Not to Use It

This pattern may be too heavy when:

• the customer only has a few admins and low governance maturity
• the team needs very fast break-glass style elevation
• operational urgency matters more than layered approvals
• they are not ready to manage access packages, privileged groups, and lifecycle together

For those environments, native PIM approval may be enough.

Final Thoughts

If your customer is asking for multi-approval for Global Admin or other highly privileged Entra roles, the answer is:

Not directly in native PIM role activation as a true multi-stage workflow.
But yes, you can design it effectively by combining:

• Entitlement Management for multi-stage approval
• PIM for Groups for just-in-time privileged activation
• Role-assignable groups for indirect privileged role assignment

That gives you a layered, auditable, security-first model that is much closer to enterprise governance expectations.

In my view, this is one of the most practical ways to extend Microsoft Entra ID’s native privileged access model without building custom workflows or third-party orchestration.

It respects Microsoft’s current architecture direction, keeps privileged roles under PIM, and gives customers the approval depth many security teams are really asking for.