Entra Cross-Tenant Access Licensing: B2B & Multi-Tenant Enterprise Guide 2026

Multi-tenant Microsoft environments — whether from organic growth, acquisitions, or partner ecosystem complexity — generate some of the most consistently underestimated licensing costs in enterprise Microsoft programmes. Cross-Tenant Access Settings (XTAP) in Microsoft Entra ID provide the governance and trust engine that makes multi-tenant collaboration secure, but they require Entra ID P1 in both collaborating tenants. For organisations with dozens of partner relationships or post-acquisition tenants still running separately, this P1 requirement can drive significant incremental licensing cost — or, when poorly understood, create security gaps where P1 governance is assumed but not actually licensed.

Cross-Tenant Access: What the Feature Set Covers

Entra Cross-Tenant Access encompasses three related but distinct capabilities, each with different licensing implications:

1. B2B Collaboration (Entra ID Free)

The foundational external identity feature — guest user invitations, invitation redemption, and access to resource tenant applications. Available with any Entra ID licence. Governance limitations: no fine-grained partner-specific policies, no MFA trust, no device compliance trust. Suitable for low-scale, low-risk external collaboration.

2. Cross-Tenant Access Settings (Entra ID P1)

The policy governance layer. Allows administrators to configure per-partner trust policies: which external tenants are trusted, what authentication claims are accepted from each partner's Entra tenant (MFA completion, compliant device status), and which applications/users are in scope for each policy. This is the Zero Trust-aligned approach to B2B — rather than re-authenticating every guest, you trust the partner's authentication claims for pre-approved partners. Requires P1 in the resource tenant for inbound trust configuration; P1 in the partner's tenant for their conditional access to validate outbound.

3. Cross-Tenant Synchronisation (Entra ID P1)

Automatic user provisioning from one Entra tenant to another, maintaining user attribute synchronisation. Used by organisations with multiple tenants (post-merger entities, geographic tenant splits) to maintain a consistent user directory across tenants without manual provisioning. Requires P1 in the source tenant. The target tenant benefits from P1 for full conditional access governance of synchronised users.

4. B2B Direct Connect (Entra ID P1)

Allows specific external users to access resources (Teams shared channels, specific M365 apps) without becoming guest users. The external user authenticates in their home tenant, and access is granted through cross-tenant trust — no guest account created in the resource directory. Eliminates guest lifecycle overhead. Requires P1 in both participating tenants plus explicit B2B Direct Connect policy configuration.

Capability	Licence Required (Resource Tenant)	Licence Required (Partner/Source Tenant)
Basic B2B guest invitation	Entra ID Free	Any
Cross-Tenant Access Settings (per-partner policies)	Entra ID P1	Entra ID P1
MFA trust from partner tenant	Entra ID P1	Entra ID P1 (for MFA enforcement in partner)
Device compliance trust from partner	Entra ID P1	Entra ID P1 + Intune (in partner)
Cross-Tenant Synchronisation	Entra ID P1	Entra ID P1 (source tenant)
B2B Direct Connect	Entra ID P1	Entra ID P1
Entitlement Management (access packages for guests)	Entra ID P2	Any
Access Reviews (for guest accounts)	Entra ID P2	Any

The Guest User Licensing Model Explained

B2B guest user licensing is governed by the 1:5 ratio rule: each Entra ID P1-licensed user in your tenant entitles you to 5 external B2B guest users without additional Entra ID licence cost. This ratio covers Entra ID-level access (sign-in, conditional access policy application). It does not cover Microsoft 365 service access.

Multi-Tenant Post-Merger Scenarios

The most commercially complex cross-tenant scenario is post-acquisition integration: two organisations with separate Entra tenants that need to collaborate closely while maintaining separate directory boundaries (often for regulatory, contractual, or operational reasons).

Scenario: Acquisition with Retained Subsidiary Tenant

Parent company (5,000 users on E3 — Entra ID P1 included) acquires subsidiary (800 users on M365 Business Premium — Entra ID P1 included). Both have P1. Cross-Tenant Access Settings can be configured to trust each other's MFA and device compliance claims. Users in either tenant can access the other's Teams, SharePoint, and applications without re-entering credentials. Cross-Tenant Synchronisation can provision a shadow directory entry in each tenant for the other's users, enabling proper name display in address books and meeting scheduling. Licensing implication: both tenants already on P1 → zero incremental cost for XTAP implementation.

Scenario: Acquisition with Unlicensed Subsidiary

Parent company (8,000 users, E5) acquires 200-person subsidiary currently on Microsoft 365 Business Basic ($6/user/month — no Entra ID P1). Implementing Cross-Tenant Access Settings requires upgrading the subsidiary to at least P1 ($6/user/month standalone or $12/user/month M365 Business Premium). Incremental cost for P1 upgrade: 200 × $6 = $1,200/month ($14,400/year). Alternative: migrate subsidiary to parent's E5 EA — but this typically costs more per user if subsidiary users have limited needs.

Scenario: Large Partner Ecosystem (50+ Partners)

Enterprise with 50 active supplier and partner relationships needing structured B2B collaboration. Using basic B2B (Free tier): invite-based guest accounts, no per-partner trust policies, MFA re-authentication required for each guest. Using XTAP (P1): 50 partner-specific trust policies, MFA trust accepted from pre-approved partners, B2B Direct Connect for Teams shared channels. The P1 requirement falls on the resource organisation and ideally on partner tenants (though you cannot control partners' licensing). Resource organisation P1 cost: already included in M365 E3+. XTAP implementation is typically free for E3+ organisations — the licensing is already in place.

Cross-Tenant Access and Zero Trust

Cross-Tenant Access Settings are a material Zero Trust control for any organisation with significant external collaboration. The Zero Trust principle of "verify explicitly" applies to external users as well as internal — and XTAP provides the mechanism to establish trust with specific external tenants rather than treating all external users as untrusted guests requiring re-authentication.

Conditional access policies for external users can be configured to: require MFA (met by home tenant or resource tenant), require compliant device (trusted from partner tenant via XTAP device compliance trust), restrict to specific applications, and limit access by location. This creates a differentiated trust model: high-trust partners (MFA + device compliance) get low-friction access; unknown external users receive stricter controls.

EA Negotiation for Multi-Tenant Environments

Multi-tenant organisations have specific EA negotiation levers that single-tenant organisations do not. The two most valuable:

Affiliate coverage: Most large EA structures include affiliate provisions — subsidiary or related entities can be covered under the parent's EA at the same per-user pricing tier. For subsidiaries currently on separate, higher-cost agreements (retail CSP or standalone M365 Business), consolidating under the parent EA typically delivers 15–25% savings on per-user pricing. This also aligns Entra ID P1 coverage across all entities, enabling XTAP without incremental licence cost.

Cross-tenant user count aggregation: When negotiating EA pricing tiers, aggregate user counts across all tenants that will be covered under the agreement. A parent with 5,000 users and a subsidiary with 800 users negotiating as 5,800 users achieves a higher volume tier than the subsidiary negotiating alone at 800 users. The incremental discount from tier uplift (often 5–10% on per-user pricing) frequently justifies the administrative effort of consolidation.

Frequently Asked Questions

What licence is required for Entra Cross-Tenant Access Settings?

Configuring Cross-Tenant Access Settings requires Entra ID P1 in the resource tenant. For full mutual trust (MFA trust, device compliance trust), P1 is also needed in partner/source tenants. Entra ID Free supports only basic B2B guest invitation without per-partner trust policies. Most M365 E3 and above customers already include P1 — XTAP is typically a configuration exercise, not a new licensing purchase.

Does cross-tenant synchronisation require additional licensing?

Cross-tenant synchronisation requires Entra ID P1 in the source tenant. Target tenants need P1 for full conditional access governance of synchronised users. No separate synchronisation licence exists — it is included in P1. For organisations with multiple tenants post-merger, cross-tenant sync typically resolves the duplicate user management problem without incremental licensing cost if P1 is already deployed.

What is the difference between B2B collaboration and cross-tenant access settings?

B2B collaboration (Free tier) enables guest user invitations. Cross-Tenant Access Settings (P1) provide the governance layer — per-partner trust policies, MFA trust, device compliance trust, and B2B Direct Connect. XTAP is the security and governance framework on top of basic B2B, enabling Zero Trust-compliant external collaboration.

How does B2B Direct Connect differ from B2B collaboration?

B2B Direct Connect allows external users to access specific services (Teams shared channels, M365 apps) without becoming guest users in your directory. Authentication occurs in the user's home tenant; access is granted via cross-tenant trust. Eliminates guest account lifecycle management. Requires P1 in both tenants and XTAP policy configuration.

Do guest users require a licence in the resource tenant?

Guest users do not require a separately purchased Entra ID licence in the resource tenant — the 1:5 guest ratio covers this. However, access to M365 services (SharePoint, Teams, Power BI) may require service-level licences depending on the specific feature the guest is accessing. Always verify per-service guest access terms for the specific M365 features being shared.