Cross-tenant access trust settings decide whether your Conditional Access policies believe anything a partner tenant says about a guest. By default they believe nothing. That is why a guest who completed multifactor authentication in their own tenant five minutes ago is challenged again in yours, and why a shared channel from a partner organisation can fail with an error that mentions neither Teams nor the channel. Every fact below was verified against Microsoft Learn on 14 September 2026.
The two outcomes are not the same failure. A B2B collaboration user is re-challenged, which is friction. A B2B direct connect user is blocked, which is an outage. Both come from the same untouched default, and both are usually investigated as a broken conditional access policy rather than as a trust setting nobody turned on.
What cross-tenant access trust settings actually control
Microsoft’s definition is narrow, and it is worth reading literally rather than skimming:
Trust settings (inbound) determine whether your Conditional Access policies trust the multifactor authentication (MFA), compliant device, and Microsoft Entra hybrid joined device claims from an external organization.
Three things follow from that sentence. The settings are inbound, so they govern external users arriving in your tenant and say nothing about your own users going out. They operate on claims, so they do not relax a Conditional Access control, they accept somebody else’s evidence that the control was already satisfied. And there are exactly three of them, with these labels in the portal:
| Inbound trust setting | What your tenant accepts | Who issued the evidence |
|---|---|---|
| Trust multifactor authentication from Microsoft Entra tenants | An MFA claim from the home tenant satisfies your MFA grant control | The partner’s authentication methods policy |
| Trust compliant devices | A compliant device claim satisfies your require compliant device control | The partner’s Intune compliance policies |
| Trust Microsoft Entra hybrid joined devices | A hybrid joined claim satisfies your require hybrid joined device control | The partner’s on-premises domain and sync configuration |
The third column is the one that gets skipped. Each checkbox moves the authority for one of your own access controls into an organisation whose configuration you cannot see and cannot audit. That is a defensible trade for the MFA claim and a considerably harder one for the two device claims, which I come back to below.
Configuring cross-tenant access trust settings, or scoping access settings to specific users, groups or applications, requires a Microsoft Entra ID P1 licence. The default settings exist in every tenant whether you hold P1 or not, which is why a tenant with no premium licensing still has a working answer to all of this, and the answer is no.
Where cross-tenant access trust settings live
The path is Entra ID > External Identities > Cross-tenant access settings, and the blade opens on two tabs that behave differently. Default settings applies to every external Microsoft Entra organisation that does not have an entry of its own. Organizational settings holds the per-partner entries, and those take precedence over the default. The three checkboxes then sit on the Trust settings tab inside whichever of those two scopes you are editing, as set out in the cross-tenant access settings documentation on Microsoft Learn.
Two mistakes come out of that precedence rule. The first is enabling MFA trust on the default and assuming it reached everybody, when the one partner that matters was given its own entry months earlier by somebody else and is still evaluated against that entry. The second is adding a per-partner entry to loosen a single thing, and quietly changing the answer for everything else that entry now covers. Read the partner’s entry before you change the default, and read the default before you add a partner.
Microsoft’s own guidance on authentication strength for external users makes the ordering explicit: check your inbound trust settings before you create the Conditional Access policy, rather than afterwards while reading sign-in logs.
The failure modes
Four things go wrong here in practice. Three are produced directly by cross-tenant access trust settings. The fourth comes from a neighbouring setting on the same blade, and is routinely blamed on the trust settings instead.
B2B collaboration, MFA trust off. The user is presented with an MFA challenge from your organisation, and Microsoft describes that flow as the same one used for external users who are not in a Microsoft Entra tenant at all. In practice your guest registers an authentication method against your tenant, carries a second set of credentials on your behalf, and rings your service desk when they change phone. Nothing is broken. It is a running cost you selected by leaving a checkbox alone.
B2B direct connect, MFA trust off. This one is a hard stop, and the documentation does not hedge:
If the resource organization doesn’t enable MFA trust with the user’s home tenant, the user is blocked from accessing resources.
The error the partner sees is AADSTS90071, and its wording is the most useful thing on this page:
The organization you’re trying to reach needs to update their settings to let you sign in. AADSTS90071: An admin from <organization> must update their access settings to accept inbound multifactor authentication.
Read who has to act. The person seeing the error is in the home tenant. The setting that fixes it is in the resource tenant, which is the organisation hosting the Teams shared channel. The time lost to this error is almost always spent by the wrong administrator searching the wrong tenant, because the message opens by talking about the organisation you are trying to reach and the reader reasonably concludes the problem belongs to somebody else.
The invitation that never arrives. A separate default can stop B2B collaboration before any trust question is asked, and it produces its own text, quoted in Microsoft’s B2B troubleshooting article:
This invitation is blocked by cross-tenant access settings. Admins in both your organization and the invited user’s organization must configure cross-tenant access settings to allow the invitation.
Both organisations are named in that sentence for a reason. An inbound block in your tenant and an outbound block in theirs look identical to the person holding the failed invitation.
The compliant device control no guest can ever satisfy. If a Conditional Access policy in scope for guests requires a compliant device and you have not trusted the compliant device claim, the guest fails it permanently. Their device is not enrolled in your tenant, so your tenant holds no compliance record for it and never will. This is the same shape of problem as a Conditional Access device filter that matches nothing, and it presents the same way: a policy that reads correctly and blocks everyone it applies to.
The object limit that may or may not still apply to you
Partner entries were historically capped, not by a count of partners but by the size of the policy object, and the failure surfaces as Failure to update policy due to object limit at 25 KB. Microsoft’s B2B troubleshooting article, last updated 19 February 2025, still documents that error and the Graph method for working out how many bytes are left.
The current answer is different. The B2B collaboration FAQ, last updated 17 April 2026, states that there are no limits to the number of organisations you can add in cross-tenant access settings. The cross-tenant access settings article, last updated 24 April 2026, frames the same change conditionally: once a migration completes, the 25 KB storage cap is gone and there are no further limits on partners.
Both pages are current. The honest reading is that the cap is being lifted by a background migration, that the FAQ describes the end state, and that the troubleshooting article describes what you will still see if your tenant has not reached it. If you are planning a partner onboarding programme around per-partner entries, test the limit in your own tenant rather than trusting either page, and test it before you commit to a date.
What I would do differently
My tenant is a lab with no enrolled devices and no partner organisations, so I have not watched a real partner estate drift out of compliance and take a shared channel down with it. What follows is a position derived from the documented behaviour, not a war story.
Trust the MFA claim. It is a statement about a person completing an authentication method, and you keep a lever over which methods count, because Conditional Access authentication strength for external users works together with the trust setting rather than around it. You can accept the home tenant’s MFA and still refuse to accept SMS. Leaving the setting off does not make you safer. It makes a second copy of every guest’s authentication registration and hands you the support cost of maintaining it.
Do not trust the two device claims by default. A compliant device claim is a statement about an estate governed by somebody else’s compliance policy, which they can weaken at any time without telling you, and which you have no way to audit. There are partners for whom that is a reasonable risk, and those partners should get a per-partner entry that says so explicitly. Enabling it in Default settings applies it to every organisation you have not thought about yet, including the ones you will start collaborating with next year.
Then treat the cross-tenant access trust settings as part of the Conditional Access change rather than a separate job. Any policy that scopes guests into an MFA or device control is a policy whose real behaviour is decided on this blade, in the same way that a named location decides the real behaviour of a policy that trusts an IP range. Changing one without reading the other is how you produce an outage nobody can find.
Last verified: 14 September 2026.
