Can Privileged Identity Management be activated once across multiple tenants?

Reviewed by ContraForce team · Updated 2026-09-04

> Privileged Identity Management is scoped to a single Microsoft Entra organization, so no documented activation spans several customer tenants at once. A partner can place a GDAP security group in its own tenant under PIM, and the technician activates that eligible membership before signing in to a customer tenant. An activated Azure Lighthouse role lasts 30 minutes to 8 hours.

What is actually supported?

The supported pattern runs in the partner tenant, not the customer's. Microsoft documents partners implementing Privileged Identity Management on a GDAP security group in the partner's tenant, and the delegated administrator activating that eligible group membership before signing in to the governed tenant.

For Azure Lighthouse, an activated eligible role applies to the delegated scope for a preconfigured period, with a documented minimum of 30 minutes and maximum of 8 hours.

So just-in-time elevation is available to a service provider. What is not available is one activation that spans customers.

Why is this a security control rather than a convenience?

Standing access across a hundred customer tenants is the largest privilege footprint a service provider has, and it is the one an attacker would most want. Just-in-time elevation shrinks the window in which that footprint exists.

The per-organization scope means the control has to be implemented once in the partner tenant and then relied upon for every customer, which is workable. What it does not give is per-customer granularity from a single activation: a technician activating to work on one customer holds the delegated capability that group carries, across the tenants that group is delegated into, for the duration of the window.

Bounding the window is therefore doing most of the work. A maximum of 8 hours is a full shift; a 30-minute minimum exists for a reason.

How do you scope an analyst to one customer at a time?

The constraint above is that the elevation unit is a group in one directory, and the access that group carries is whatever it has been delegated across the estate.

ContraForce holds analysts, roles, and approval gates in the platform, so scope is expressed per workspace rather than per directory group, and an analyst can be granted access to one customer's environment without that grant being expressed as a delegated identity in every tenant. Approval gates apply to the action rather than to the session, which is a different control from time-bounding elevation and composes with it.

Sources

• Privileged Identity Management for partners with GDAP
• Azure Lighthouse and Privileged Identity Management
• What is Privileged Identity Management?