Configuring Entra ID Cross-Tenant Access for B2B Guests

#Operational requirement

You will get this ticket in your first month: “Partner company X needs access to a SharePoint site and two Teams channels by Friday.” Someone senior will tell you to “just invite them as guests.” Do not just invite them as guests. Entra ID ships with default cross-tenant access settings that are permissive by design, because Microsoft optimised the default for adoption, not for your audit committee. Left untouched, any user in your tenant can invite any external identity as a B2B guest, and inbound trust from the partner’s home tenant is not automatically extended to your Conditional Access policies. A partner’s MFA claim, performed in their own tenant, is not trusted by yours unless you say so explicitly. The production consequence is not hypothetical: guests either get blocked mid-collaboration by Conditional Access with no clear reason visible to them, or they sail through because your default inbound policy trusts everything, and nobody in a security review can explain why an external identity has standing access to a finance SharePoint site with no MFA enforcement trail.

B2B sprawl is one of the fastest-growing sources of audit findings in Microsoft 365 tenants, which is why this task lands on junior identity engineers so often. Your job is to configure cross-tenant access settings deliberately: restrict who can invite guests, define inbound trust explicitly for the specific partner tenant, and back it with a Conditional Access policy that does not silently fail. This procedure assumes you already hold Global Administrator or Security Administrator rights, or at minimum the Microsoft Graph API permission Policy.ReadWrite.CrossTenantAccess, and that you are working in a tenant with Entra ID P1 licensing at minimum, since cross-tenant access policy and Conditional Access both require it. Confirm your assignment before you start; do not attempt this under a role that only has read access and hope it works.

#Implementation steps

Capture the current state before you touch anything. This is your rollback point, and you will need it if something breaks mid-onboarding.

1Connect-MgGraph -Scopes "Policy.Read.All","Policy.ReadWrite.CrossTenantAccess","Organization.Read.All"
2
3Get-MgPolicyCrossTenantAccessPolicyDefault | ConvertTo-Json -Depth 10 | Out-File .ca-default-backup.json
4
5Get-MgPolicyCrossTenantAccessPolicyPartnerConfiguration -All | ConvertTo-Json -Depth 10 | Out-File .ca-partners-backup.json

Next, tighten the tenant-wide external collaboration settings so guest invitations are not open to every user in the tenant. In the Entra admin centre, go to Identity > External Identities > External collaboration settings and set Guest invite restrictions to “Only users assigned to specific admin roles can invite guest users.” If your organisation genuinely needs broader invite rights, assign a role such as Guest Inviter to specific staff rather than leaving invitations open to everyone. This single setting stops the ad hoc guest sprawl that makes access reviews unmanageable six months later.

Now configure the default cross-tenant access policy. This governs collaboration with tenants you have not explicitly configured, and it should be restrictive by default, not permissive.

1$defaultParams = @{
2  b2bCollaborationInbound = @{
3    usersAndGroups = @{
4      accessType = "blocked"
5      targets = @(@{ target = "AllUsers"; targetType = "user" })
6    }
7  }
8  inboundTrust = @{
9    isMfaAccepted = $false
10    isCompliantDeviceAccepted = $false
11    isHybridAzureADJoinedDeviceAccepted = $false
12  }
13}
14
15Update-MgPolicyCrossTenantAccessPolicyDefault -BodyParameter $defaultParams

With the default locked down, create an explicit partner configuration for the tenant you are onboarding. Get the partner’s tenant ID directly from them, not from a domain lookup; domain-to-tenant mapping is unreliable for multi-domain organisations and you will guess wrong at least once in your career if you rely on it.

1$partnerTenantId = "b1c14d5c-3a2e-4a91-9f6d-2c7e8a1d55f0"
2
3New-MgPolicyCrossTenantAccessPolicyPartnerConfiguration -TenantId $partnerTenantId -BodyParameter @{
4  b2bCollaborationInbound = @{
5    usersAndGroups = @{
6      accessType = "allowed"
7      targets = @(@{ target = "AllUsers"; targetType = "user" })
8    }
9  }
10  b2bCollaborationOutbound = @{
11    usersAndGroups = @{
12      accessType = "allowed"
13      targets = @(@{ target = "AllUsers"; targetType = "user" })
14    }
15  }
16  inboundTrust = @{
17    isMfaAccepted = $true
18    isCompliantDeviceAccepted = $true
19    isHybridAzureADJoinedDeviceAccepted = $false
20  }
21}

Setting isMfaAccepted = $true is the step people forget, and it is the one that actually matters. Without it, your Conditional Access policies will treat every inbound guest sign-in as unauthenticated by MFA regardless of what the partner tenant enforced, and guests get blocked with no obvious explanation on their end.

Finally, back this with an explicit Conditional Access policy scoped to guest and external users, rather than relying solely on cross-tenant trust to carry the whole control. In the Entra admin centre, go to Protection > Conditional Access > New policy, set Users to include the “Guest or External User” types (specifically “B2B collaboration guest users” and “B2B collaboration member users”), target the specific cloud apps the partner needs, such as SharePoint Online and Teams, and require MFA as a grant control. Deploy it in report-only mode first, always.

1New-MgIdentityConditionalAccessPolicy -BodyParameter @{
2  displayName = "CA-Guests-RequireMFA-PilotPartner"
3  state = "enabledForReportingButNotEnforced"
4  conditions = @{
5    users = @{
6      includeGuestsOrExternalUsers = @{
7        guestOrExternalUserTypes = "b2bCollaborationGuest,b2bCollaborationMember"
8        externalTenants = @{ membershipKind = "all" }
9      }
10    }
11    applications = @{ includeApplications = @("00000003-0000-0ff1-ce00-000000000000") }
12  }
13  grantControls = @{
14    operator = "OR"
15    builtInControls = @("mfa")
16  }
17}

Run it in report-only for a minimum of five business days before flipping state to enabled. That window is your safety margin against blocking a partner mid-project because of a misconfigured claim you did not catch in testing.

#Verification

Confirm the partner-specific policy landed correctly before you tell anyone the work is done:

1Get-MgPolicyCrossTenantAccessPolicyPartnerConfiguration -TenantId $partnerTenantId | Format-List

Then check actual sign-in behaviour, not just policy state. In the Entra admin centre, go to Identity > Monitoring & health > Sign-in logs, filter by Cross Tenant Access Type = B2B Collaboration, and inspect the Authentication Details tab for a real pilot guest sign-in. You are looking for the MFA requirement to be satisfied either by the home tenant’s claim, if inbound trust worked, or by your own Conditional Access challenge, if it did not but the fallback still enforced security. Both are acceptable outcomes; a sign-in with no MFA satisfaction recorded at all is not, and should stop the rollout.

Also review the Conditional Access report-only results under Insights and reporting on the policy itself, which shows exactly which sign-ins would have been blocked or challenged had you enforced it live. Do not flip to enforced until this report is clean for at least one full pilot user cycle, including a fresh sign-in after a token refresh, not just the first successful redemption.

#Failure Modes and Common Traps

The legacy allowlist trap catches more people than it should. Tenants that had B2B collaboration configured before cross-tenant access policy existed as a distinct object sometimes still carry old domain-based allow or deny lists under the authorisation policy. These silently override your carefully built partner configuration, and you will spend an afternoon convinced your JSON payload is wrong when it is actually correct and simply being ignored by an older setting nobody remembered to remove.

#Rollback

If the partner-specific configuration causes unexpected lockouts, remove it and fall back to the default policy rather than trying to patch it live under pressure with people waiting on a call.

1Remove-MgPolicyCrossTenantAccessPolicyPartnerConfiguration -TenantId $partnerTenantId

To restore the tenant-wide default to its pre-change state, replay the backup

1$restore = Get-Content .ca-default-backup.json | ConvertFrom-Json
2Update-MgPolicyCrossTenantAccessPolicyDefault -BodyParameter $restore

For the Conditional Access policy, set state back to enabledForReportingButNotEnforced immediately if you see unexpected blocks in production, rather than deleting the policy outright. This preserves your report-only telemetry while removing enforcement, which is the fastest safe reversal available. Only delete the policy object if you are abandoning the approach entirely, and even then, export it first with Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $id | ConvertTo-Json -Depth 10 so you are not rebuilding it from memory next sprint under time pressure.

#Operational Summary

Cross-tenant access configuration is not a one-off checkbox. It is a per-partner decision that has to be made deliberately every time a new external relationship is onboarded, and it needs to sit in your change log with the partner tenant ID, the date, and who approved it. The default posture should be restrictive: block by default, allow explicitly per tenant, and never assume a partner’s MFA claim is trustworthy until you have set inboundTrust.isMfaAccepted yourself and watched a real sign-in prove it in the logs. Pair every cross-tenant policy change with a Conditional Access rule running in report-only mode first, because the failure mode you are avoiding is not a security gap, it is a partner locked out of a live project with no clear diagnostic pointing at the cause. Keep your JSON backups from every change and log the partner tenant ID somewhere durable outside the ticket system; they are cheaper than rebuilding a policy from institutional memory during an incident call, and far cheaper than explaining to an auditor why a guest account has had standing access for eighteen months with nobody able to say who approved it.