Implementation Scenarios for Multi-Tenant Environments
An MSP engineer with Global Admin access to 40 customer tenants. One compromised account. Forty simultaneous incidents. This was not a theoretical risk under the legacy Delegated Admin Privileges model it was the standard operating configuration for years. Microsoft’s own incident response teams have cited this pattern as a recurring factor in supply chain attacks.
PIM in a multi-tenant environment is the architectural answer to that problem. The challenge is that most implementations stop at the single-tenant basics, and the moment you introduce cross-tenant access, partner delegation, or enterprise holding structures, the decisions compound quickly. This post covers the three distinct multi-tenant scenarios, how PIM behaves differently in each, and where the implementation breaks in practice.
Microsoft Entra Privileged Identity Management (PIM) is an Entra ID service that replaces permanent role assignments with time-bound, approval-gated, audited activations. Instead of a user holding the Exchange Administrator role permanently, they are eligible for it. When they need it, they activate, providing a justification, completing MFA, and optionally waiting for an approver. The role activates for a defined window, then expires automatically.
In a single-tenant environment, PIM operates within one directory. Every eligible user, every approver, every policy, and every audit log lives in the same place. The configuration surface is bounded.
Multi-tenant environments break this containment. Users may live in one tenant and need roles in another. Approval workflows may need to span organizational boundaries. MFA completed in one tenant may or may not be recognized in another. Licenses enabling PIM features may be required in the tenant where the user authenticates, the tenant where the role lives, or both, depending on the model. Getting these decisions wrong early produces access models that are either insecure (too permissive), broken (users cannot activate roles at all), or expensive (licenses purchased in the wrong places).
Most documentation treats multi-tenant PIM as a single problem. It is not. The architecture, tooling, and licensing differ significantly depending on why you have multiple tenants in the first place.
Enterprise multi-tenant covers holding companies, post-M&A environments, and production/sandbox separations. Users live in a home (source) tenant, resources live in one or more resource tenants. The access pattern is internal employees needing JIT access to resources they do not own. The right tooling is cross-tenant synchronization combined with PIM for Groups in the resource tenant.
Partner/MSP multi-tenant covers a service provider managing N customer tenants from their own managing tenant. Users are internal to the partner organization; the resources belong entirely to customers. The access pattern is external technicians needing scoped, time-bound access without becoming permanent objects in customer directories. The right tooling is GDAP combined with PIM for Groups in the partner tenant.
Azure Lighthouse covers pure Azure resource management across tenants, typically for MSPs or enterprise platform teams managing subscriptions belonging to other tenants. No M365 administration, no Entra role management in the managed tenant. The access pattern is centralized operations teams needing elevated Azure RBAC access across multiple subscriptions without creating any identity objects in managed tenants. The right tooling is Lighthouse eligible authorizations defined in ARM templates, with PIM running entirely in the managing tenant.
| Enterprise (Cross-Tenant Sync) | Partner/MSP (GDAP) | Azure Lighthouse | |
|---|---|---|---|
| User objects in managed tenant | Yes (B2B guests or members) | No | No |
| Where PIM policy lives | Resource tenant | Partner (managing) tenant | Managing tenant |
| P2 license required in | Resource tenant (per eligible user) | Partner tenant only | Managing tenant only |
| Azure resources | Yes | Yes (via GDAP) | Yes |
| M365 / Entra roles | Yes | Yes | No |
| Max delegation duration | Unlimited (governed by access reviews) | 2 years per GDAP relationship | Defined in ARM template |
| Audit logs visible to managed tenant | Yes | Yes (partner sign-ins visible) | Yes (Azure activity logs) |
Getting this categorization right before touching any configuration saves significant rework.
PIM for Groups is a feature that enables just-in-time membership or ownership of a Microsoft Entra security group or Microsoft 365 group. Unlike PIM for Roles (which grants a specific Entra or Azure role directly), PIM for Groups grants group membership, and through that membership, all resources the group is associated with.
The instinct in most JIT implementations is to use PIM for Roles directly: make a user eligible for Contributor or Exchange Administrator, require activation. That works in single-tenant scenarios. In multi-tenant environments, PIM for Groups is almost always the better primitive.
A single eligible group membership can simultaneously grant access to multiple linked resources: an Entra role, an Azure resource role, an application permission, and an Intune scope. For a technician handling an incident across a customer environment, activating one group assignment is the difference between a usable JIT workflow and a five-step elevation process that nobody follows under pressure.
PIM for Groups also provides a clean separation between identity governance (who is eligible for what) and resource access (what that eligibility grants). When a customer’s environment changes, you update the group’s resource assignments. The eligible assignments for your team members do not change.
Known limitations of PIM for Groups that affect multi-tenant designs:
These are not edge cases. They are constraints that affect every environment with hybrid identity or automation-heavy access patterns. Design your group taxonomy around these constraints before building eligible assignments.
Granular Delegated Admin Privileges (GDAP) is Microsoft’s replacement for the legacy Delegated Admin Privileges (DAP) model. Under DAP, MSPs held permanent Global Admin and Helpdesk Admin access to every customer tenant, with no time limit and no granularity. Under GDAP, a partner requests specific Microsoft Entra roles in the customer tenant with customer consent and a defined duration. The maximum GDAP relationship duration is two years. Permanent GDAP relationships are explicitly not supported by design.
The architecture that combines GDAP with PIM for Groups works as follows: the MSP creates security groups in their managing tenant, each representing a role or function tier (Tier 1 support, Exchange administration, Intune management). These groups are mapped to GDAP role assignments in the customer tenant. PIM for Groups in the managing tenant controls which engineers can activate membership in those groups, and for how long. The customer tenant never stores the partner’s user objects or role assignments in IAM, access is projected from the partner tenant.
The critical licensing point for GDAP + PIM: P2 licenses are required only in the partner (managing) tenant, for engineers holding eligible group memberships and for approvers. Customer tenants do not require P2 licenses for the partner access model to function. This is the most commonly misunderstood aspect of GDAP + PIM licensing and frequently leads to unnecessary per-customer P2 procurement.
A documented but poorly surfaced limitation: If a partner group is assigned the Security Reader or Global Reader role via GDAP, and the customer tenant has PIM enabled, the partner user encounters a “No Access” error when navigating to Entra Roles and Administrators in the customer tenant. The workaround requires the Global Administrator role. This behavior affects read-only monitoring configurations and needs to be factored in when designing Tier 1 access models around read-only GDAP roles.
GDAP relationship expiry is an operational risk that is commonly underestimated. When a GDAP relationship expires, all role assignments scoped to that relationship are removed immediately, with no grace period. The partner loses the ability to activate PIM-eligible roles for that customer until the relationship is re-established and re-approved by the customer. The auto-extend setting adds six months per cycle but requires active monitoring to confirm it applied correctly. For MSPs managing dozens of customer relationships with staggered expiry dates, GDAP renewal must be treated as a formal operational process with ownership and alerting, not a calendar reminder.
Azure Lighthouse is architecturally different from GDAP and B2B in one important way: no user objects or role assignments are created in the managed tenant. From the customer’s perspective, partner access appears as a projection from the managing tenant. The customer can see audit logs of what was done, but there are no guest accounts in their directory and no role assignments visible in their IAM blade.
PIM integration with Lighthouse is configured through eligible authorizations in the ARM onboarding template. When onboarding a customer subscription, the managing tenant defines which security groups receive which Azure roles, whether those authorizations are permanent or eligible, the maximum activation duration, and who the approvers are. The entire JIT policy lives in the managing tenant.
This model covers Azure resource management. It does not cover M365 administration, Entra role management in the customer tenant, or Intune. Running Lighthouse alongside GDAP for the same customer is a valid and common configuration: Lighthouse for Azure subscriptions, GDAP for M365 and Entra.
Two Lighthouse constraints that regularly catch engineers by surprise:
P2 licensing for Lighthouse JIT is required only in the managing tenant, for users with eligible authorizations and their approvers. This is the most cost-efficient model for pure Azure management at scale.
When a B2B guest user activates a PIM role in a resource tenant, the Conditional Access policies of the resource tenant apply, including MFA requirements. By default, resource tenants do not trust MFA completed in the user’s home tenant. The guest must register MFA separately in the resource tenant.
For a partner engineer with eligible access to 40 customer tenants, this means 40 separate MFA registrations, 40 entries in Authenticator, each requiring individual re-registration when a device is replaced. In practice, engineers either avoid using eligible access or accumulate unmanageable MFA registrations that become a security problem when account recovery is needed.
The solution is MFA Trust in Cross-Tenant Access Settings. Enabling inbound MFA trust for a specific partner organization in the resource tenant causes the resource tenant to accept MFA claims fulfilled in the user’s home tenant. The engineer authenticates once in their home tenant and that authentication is honored across resource tenants that have configured trust.
Three things to be aware of when configuring MFA trust across tenants:
| Scenario | P2 needed in | Per what | Customer tenant P2 needed? |
|---|---|---|---|
| Enterprise cross-tenant sync + PIM for Groups | Resource tenant | Each eligible user + approvers | N/A (same org) |
| Cross-tenant sync (source tenant) | Source tenant | Each synchronized user (P1 minimum) | N/A |
| GDAP + PIM for Groups (MSP model) | Partner tenant | Each eligible engineer + approvers | No |
| Azure Lighthouse + eligible authorizations | Managing tenant | Each eligible user + approvers | No |
| Customer’s own PIM eligible assignments | Customer tenant | Customer’s own eligible users | Yes (own users) |
One edge case that catches organizations running all three models simultaneously: if an engineer in the managing tenant holds eligible assignments through both Lighthouse and GDAP, the P2 license is consumed once in the managing tenant. There is no per-customer-tenant P2 stacking. MSPs who initially estimate PIM licensing as a per-customer cost significantly overestimate the actual license requirement.
Microsoft Entra ID P2 and the Entra ID Governance license both cover PIM. The Entra Suite includes both. If your organization already purchases Entra ID Governance for access reviews or entitlement management, PIM is included at no additional cost.
PIM API v2 (beta) end-of-life: October 28, 2026. Any PowerShell scripts, Logic Apps, or custom tooling that calls the PIM Iteration 2 beta API endpoints for Azure resources, Entra roles, or Groups will stop working on that date, with no data returned and no clear failure message. Organizations that built role activation automation, approval workflows, or eligibility assignment scripts before roughly 2023 need to audit and migrate to the Graph API Iteration 3 (GA) endpoints. The migration is not technically complex, but finding every place where old PIM API calls are embedded in multi-tenant automation pipelines takes time. Review this now rather than during an incident window in late 2026.
Token propagation delay after role activation. PIM activates a role assignment within seconds, but the user’s current browser session does not automatically reflect the new assignment. The classic failure: an engineer activates a role in PIM, immediately navigates to a resource or tries to invite a B2B guest, and receives an access denied error despite the activation showing as successful. The role is active. The token has not refreshed. Signing out and back in resolves it. This should be explicitly documented in operational runbooks.
Group nesting in PIM for Groups. Microsoft explicitly recommends against nesting a group within a PIM for Groups-enabled group. Nested group members inherit access when the parent group is activated, which can grant unintended permissions to a broader set of users than intended. Activation behavior with nested groups produces non-obvious audit log entries and makes access reviews difficult to interpret. Use flat group structures with clearly scoped eligible assignments.
GDAP relationship renewal as a formal process. An expired GDAP relationship removes all scoped role assignments immediately, with no grace period. The auto-extend setting helps but must itself be monitored. For MSPs managing dozens of customer relationships with staggered expiry dates, GDAP renewal needs ownership, alerting, and a defined renewal lead time, not a calendar entry.
B2B guest versus member user type affects PIM behavior. Users synchronized into a resource tenant via cross-tenant synchronization are provisioned as B2B guests by default. Access reviews, entitlement management policies, and some Conditional Access scoping behave differently for guests versus members. Changing the userType after provisioning requires Graph API calls or reconfiguring attribute mappings in the cross-tenant sync job. Decide on the userType strategy before provisioning begins.
Yes. A B2B guest user can be assigned eligible roles in a resource tenant and can activate them through the PIM portal. The activation is subject to the resource tenant’s Conditional Access policies, including MFA requirements. By default, the guest must register MFA in the resource tenant separately from their home tenant, unless the resource tenant has configured inbound MFA trust in Cross-Tenant Access Settings.
No. Azure Lighthouse manages Azure resource roles (RBAC) only. It cannot delegate Entra ID roles or manage Microsoft 365 workloads such as Exchange, SharePoint, or Intune in the customer tenant. For M365 administration, GDAP is required.
No. Service principals cannot receive eligible assignments in PIM for Entra roles, Azure roles, or PIM for Groups. They can only receive time-limited active assignments. If your automation requires JIT-style access for workload identities, the available mechanism is a time-limited active assignment, not an eligible assignment with activation.
Eligible role assignments are removed. Permanently active assignments are unaffected. The PIM service and Graph API interfaces become unavailable for managing privileged access. Any ongoing access reviews of Entra roles end. This applies when a P2 or Entra ID Governance license expires in the tenant where the eligible assignments exist.
No. For the partner access model (GDAP + PIM for Groups in the partner tenant), P2 licenses are required only in the partner’s managing tenant. Customer tenants do not require P2 for partner engineers to use PIM when accessing customer resources through GDAP.
The maximum activation duration is configurable per role or group, up to a maximum of 24 hours per activation. Users can request any duration up to the configured maximum at activation time. This is separate from the eligible assignment duration, which can be set with a specific end date or left without expiration, subject to access reviews.
Yes. Running Lighthouse alongside GDAP for the same customer is a common and supported configuration. Lighthouse handles Azure subscription access; GDAP handles M365 and Entra role administration. The P2 license requirement remains in the managing/partner tenant for both.
If you manage Azure resources for customers and do not use Azure Lighthouse with eligible authorizations, you are using a more complex and less auditable model than necessary. Lighthouse keeps customer tenant directories clean, centralizes PIM policy in one place, and requires P2 licenses only in your managing tenant. The only reason not to use Lighthouse for Azure is if you need to delegate roles with dataActions permissions (storage, Key Vault, SQL data access), which Lighthouse explicitly does not support.
If you manage M365 and Entra workloads for customers, GDAP is required. Combine it with PIM for Groups in your managing tenant, map your team’s eligible assignments to GDAP security groups, and configure outbound MFA trust so engineers do not accumulate per-tenant MFA registrations. Define your security group taxonomy by function tier, keep groups flat, and track GDAP expiry dates as a formal process with ownership.
If you are an enterprise with multiple tenants from M&A, regulatory separation, or environment isolation, cross-tenant synchronization from the source tenant combined with PIM for Groups in each resource tenant is the right architecture. Configure MFA trust in each resource tenant’s inbound Cross-Tenant Access Settings. Decide on the B2B guest versus member user type before provisioning begins.
In all three scenarios, access reviews are not optional. Eligible assignments accumulate over time as people change roles, leave organizations, or move between projects. An eligible assignment that is technically correct but operationally stale is still a risk. Schedule quarterly access reviews for all eligible PIM assignments across every tenant in scope.
JIT access through PIM is not a feature you enable; it is an architecture you design. In single-tenant environments, the design space is small enough to iterate toward a working configuration. In multi-tenant environments, choices about which model to use, where licenses are needed, and how MFA trust is configured have consequences that are difficult to reverse.
The three models (enterprise cross-tenant sync, GDAP for MSPs, and Azure Lighthouse) are not interchangeable. Each solves a specific access pattern. Using the wrong one creates unnecessary complexity and operational risk.
The PIM API v2 (beta) retirement on October 28, 2026 is a concrete deadline that many organizations with legacy automation are not tracking. Audit any PIM automation built before 2023.
Licensing for multi-tenant PIM almost always costs less than organizations initially estimate. P2 is required where eligible assignments live, not where resources live. For MSP and Lighthouse models, that means the managing tenant only.
