GDAP, B2B guest, cross-tenant sync or tenant governance: which delegated access model scales for an MSSP?
Reviewed by ContraForce team · Updated 2026-09-04
> Each model has a different documented boundary. GDAP reaches Defender data but not Microsoft Sentinel data. A Microsoft Entra account can belong to a maximum of 500 tenants as a member or guest. Cross-tenant synchronization is intended for use within one organization. Tenant governance relationships are in public preview and are built on GDAP.
Last verified: 2026-09-04. Every figure below is quoted from Microsoft documentation and linked at the foot of the page.What are the four models, and what is each actually for?
Granular Delegated Admin Privileges (GDAP) is the CSP partner model. It grants Microsoft Entra directory roles in a customer tenant, time-bound and scoped. Microsoft Entra B2B guest access invites an account from one directory into another as a guest. It is the general-purpose external collaboration model, not a partner-specific one. Cross-tenant synchronization provisions users automatically from one tenant into another. Microsoft states that "for privacy reasons, cross-tenant synchronization is intended for use within an organization" — it is a multi-tenant-organization feature rather than a service-provider one, though the documentation says it can be used across organizations with additional considerations rather than prohibiting it. Tenant governance relationships are newer. Microsoft describes a governance relationship as establishing "a directional connection between two Microsoft Entra tenants", and states that the cross-tenant delegated administration in it "uses granular delegated admin privileges (GDAP) technology". Note the status: Microsoft announced them as public preview in March 2026. They are not generally available, which matters for anything load-bearing.Where does each model stop?
Microsoft documents each ceiling, but scatters them across separate pages, and several widely-repeated figures are wrong.
| Model | Documented boundary | The detail that gets misquoted |
|---|---|---|
| GDAP | Reaches Defender data only; not supported for Microsoft Sentinel data | Microsoft says "at this time", so treat it as current state, not architecture |
| B2B guest | A single account can belong to a maximum of 500 tenants | The 500 counts membership and guest, not 500 external tenants on top of a home tenant |
| B2B invitations | Tiered by licence and tenant age | The commonly quoted "100 per day" applies only to unpaid tenants over 30 days old; paid tenants over 30 days are capped by Entra service quotas, for which no figure is published |
| Cross-tenant access settings | No limit on partner organisations | Microsoft states plainly there are no limits here; the old 25 KB policy-object cap is removed after migration to the new storage model |
| Multitenant organization | 100 tenants by default | Raisable by support request, and it does not apply to cross-tenant synchronization by itself |
| Tenant governance | Public preview | Built on GDAP, so it inherits GDAP's boundaries rather than escaping them |
Microsoft also documents no process for raising the 500-tenant membership cap, and documents no error behaviour at that boundary — so what fails first, invitation, redemption or sign-in, is not something the public record settles.
Can GDAP and Privileged Identity Management be combined?
GDAP and Privileged Identity Management do combine, and this is the point most often stated backwards. Microsoft documents that "partners can implement Privileged Identity Management (PIM) on a GDAP security group in the partner's tenant". The technician activates an eligible group membership in the partner tenant before signing in to the customer tenant.
What does not exist is per-customer PIM activation from the governing side, or one activation that applies across a book of customers. Privileged Identity Management is scoped to a single Microsoft Entra organisation, so an analyst working fifty customers activates in the partner tenant once, and the customer-side elevation model remains whatever each customer runs.
PIM in the partner tenant also carries a licensing dependency: Microsoft Entra ID Governance or Microsoft Entra ID P2 licences are required to use it.
What does automating any of this cost in API terms?
Guest onboarding at scale runs into Microsoft Graph throttling before it runs into the tenant caps. The `/invitations` endpoint is limited to 150 requests per 5 seconds per tenant across all applications, and that is a single shared budget rather than a per-application allowance.
That is generous enough for onboarding and tight enough that a bulk re-invitation across a large estate needs pacing rather than a loop.
Which one should a service provider actually build on?
No model here carries analyst access across a customer estate without per-tenant work, which is the honest answer this comparison produces. GDAP is the right primary model for Defender and Microsoft 365 administration and does not reach Sentinel. B2B carries Sentinel access and is capped per account. Cross-tenant synchronization is aimed at a single organisation. Tenant governance is preview and inherits GDAP underneath.
So the choice is usually GDAP for administration plus B2B for Sentinel plus Azure Lighthouse for cross-tenant Sentinel queries, maintained per customer, three times over.
How do you avoid modelling analyst permissions in every tenant?
Every model above is per tenant by construction. The alternative is an operating layer that holds its own identity and role model, so an analyst is granted a role once and it resolves against every connected customer environment. ContraForce works that way: analysts, roles and approval gates live in the platform, and the connection into each customer tenant is a scoped Microsoft Entra enterprise application consented per module rather than a per-analyst delegated identity.
That does not replace delegated access, which still has to exist for the platform to reach the tenant. It removes the need to rebuild the analyst permission model inside each one, and it means a Microsoft-side change to the access model lands in one place instead of in every customer's role assignments.
Sources
- Microsoft Entra service limits and restrictions
- Microsoft Entra B2B fundamentals
- Cross-tenant access settings overview
- Microsoft Graph throttling limits
- Microsoft Defender multitenant management requirements
What does automating any of this cost in API terms?
Guest onboarding at scale runs into Microsoft Graph throttling before it runs into the tenant caps. The /invitations endpoint is limited to 150 requests per 5 seconds per tenant across all applications, and that is a single shared budget rather than a per-application allowance.
Continue the evaluation
Sources and review method
Product capabilities were reviewed against the page-specific primary sources below on 2026-09-04. Performance claims require the population and limitations stated in the linked methodology.
- NIST SP 800-61 Revision 3: Incident Response Recommendations and Considerations (verified 2026-09-04)
- ContraForce measurement methodology (verified 2026-09-04)
Related microsoft resources
- MSSP analyst access across GDAP tenants after Unified RBAC auto-enablement, What changes when Defender Unified RBAC activates automatically, and why GDAP does not carry Sentinel access.
- Cross-tenant Sentinel playbooks and the Defender portal, Rule-triggered cross-tenant playbooks work; manual runs on alerts and entities are not supported in the Defender portal.