Entra Identity Multi Tenant Organizations: MFA, SSO, Conditional Access, and User Management Guide 2026

Before you touch a single configuration setting, you need to formally define which tenants are part of your multitenant organization. Microsoft Entra ID has a specific feature called Multitenant organization, and it's distinct from simply having multiple tenants. It creates an official, recognized boundary around the tenants your organization owns, and it unlocks better collaboration experiences in Microsoft Teams and other Microsoft 365 apps.

The process works through an invite-and-accept flow. The owning tenant creates the multitenant organization and invites other tenants to join. Each invited tenant's admin accepts the invitation. Once that mutual recognition is in place, cross-tenant access settings automatically get a flag indicating those tenants are part of the same multitenant organization, which simplifies a lot of downstream policy configuration.

To create your multitenant organization, you have two paths:

Via Microsoft 365 admin center (recommended for smaller orgs): Go to admin.microsoft.com, navigate to Settings > Org settings > Multitenant collaboration, and use the guided wizard. This gives you an intuitive portal experience that also walks you through basic user synchronization setup.

Via Microsoft Entra admin center: Go to entra.microsoft.com, navigate to Identity > External Identities > Multitenant organizations, and create the organization there. You can then add tenants and generate the invitation tokens that partner admins use to join.

Via Microsoft Graph API or PowerShell, you can also automate this with the multiTenantOrganization resource type, useful if you're scripting large-scale multitenant organization setup across many tenants.

# Connect to Microsoft Graph with the required scope
Connect-MgGraph -Scopes "MultiTenantOrganization.ReadWrite.All"

# Check if a multitenant organization already exists in your tenant
Get-MgTenantRelationshipMultiTenantOrganization

If the command returns a multitenant organization object with an id, you're already in one. If it returns nothing or an error, you'll need to create one. When your multitenant organization is active and partner tenants have accepted their invitations, you'll see the tenant list populate under Tenants in the Multitenant organizations blade. That's your confirmation it worked.

This is the most technically involved step and the one that causes the most headaches. Cross-tenant access settings in Entra ID control four distinct things: B2B collaboration, B2B direct connect, cross-tenant synchronization, and the multitenant organization trust signals. Each one has its own inbound and outbound controls per partner tenant.

Here's how I approach this systematically. For each tenant in your multitenant organization, open Identity > External Identities > Cross-tenant access settings and check that tenant's entry (or create one if it's missing). Then configure:

Inbound B2B collaboration: Set this to "Allow" for users and groups from the partner tenant. You can scope this to specific groups if you don't want to allow everyone, this is smart in larger organizations where only certain teams need cross-tenant access.

Outbound B2B collaboration: Controls whether your users can authenticate to apps registered in the partner tenant. For internal multitenant organizations, you generally allow all users outbound.

B2B direct connect inbound/outbound: This is required specifically for Teams shared channels. B2B direct connect users don't get a guest account in your directory, they're visible in Teams but not represented as users in your tenant. Enable this if Teams shared channel collaboration is a requirement.

Trust settings (critical for MFA): Under the partner tenant's inbound settings, go to Trust settings and check "Trust multifactor authentication from Microsoft Entra tenants". This tells your tenant to honor MFA claims the partner tenant has already satisfied. Without this, users from the partner tenant get hit with a second MFA prompt every time they access your resources, which is a terrible experience and kills adoption.

# View cross-tenant access partner configurations via Graph API
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Check inbound trust settings for a specific partner tenant
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners/{partnerTenantId}

When these settings are correctly configured on both sides, users from partner tenants will stop seeing unexpected MFA prompts and authentication failures. Outlook and Teams will also start showing them as trusted internal users rather than external guests.

Cross-tenant access settings open the door, but users from your partner tenants still don't automatically appear in your directory. That's what cross-tenant synchronization solves. It's a synchronization service that automatically creates, updates, and deletes B2B collaboration users in target tenants, so they show up in Microsoft 365 apps, address books, and people searches without anyone manually managing guest accounts.

Cross-tenant synchronization is configured in the source tenant, the tenant where the users live, and it pushes those users into the target tenant as B2B collaboration users. The sync is governed by the cross-tenant synchronization settings you set up in Step 2.

To configure this in the Microsoft Entra admin center (source tenant):

1. Navigate to Identity > External Identities > Cross-tenant synchronization.
2. Click Configurations, then New configuration.
3. Give the configuration a name (e.g., "Sync to Fabrikam Tenant") and enter the target tenant ID.
4. Authenticate to the target tenant, you'll need admin consent granted in the target tenant for the provisioning service.
5. Under Provisioning, set the provisioning mode to Automatic.
6. Configure the scope, either sync all users or filter to a specific group. Scoping to a group first is good practice.
7. Review the attribute mappings and save.

# Check provisioning status for cross-tenant sync via PowerShell
Connect-MgGraph -Scopes "Synchronization.Read.All"

# Get synchronization jobs for a specific service principal
Get-MgServicePrincipalSynchronizationJob -ServicePrincipalId 

# Trigger an on-demand sync cycle
Invoke-MgServicePrincipalSynchronizationJobOnDemand `
  -ServicePrincipalId  `
  -SynchronizationJobId 

A successful initial sync cycle will show provisioned users appearing in the target tenant as B2B collaboration users with user type "Member" (if configured that way) rather than "Guest." The difference matters, Member-type B2B users get access to more Microsoft 365 applications than Guest-type users, which is exactly what you want for employees moving between tenants in your own organization.

If the sync is failing, check the provisioning logs under Monitoring > Provisioning logs in the Entra admin center. Error code AzureActiveDirectoryInvalidCredentials usually means the admin consent in the target tenant wasn't granted properly. Error code InvalidCrossTenantSynchronizationConfiguration means the cross-tenant access settings in Step 2 don't permit this sync.

This is where enterprise IT teams often paint themselves into a corner. Conditional Access policies that work perfectly for your own users can completely break the experience for B2B collaboration users coming in from partner tenants, and the policy failures show up as generic access denied errors that your users will interpret as "the system is broken."

The key concept to understand: when a B2B collaboration user from another tenant in your multitenant organization accesses a resource in your tenant, your tenant's Conditional Access policies evaluate them. That user's home tenant Conditional Access policies also evaluated them before they got here. If you haven't configured MFA trust (from Step 2), your policy might demand MFA that the user technically already completed.

Here's how to structure your Conditional Access policy for multitenant organization users:

In Microsoft Entra admin center > Protection > Conditional Access > Policies, create or modify the policy that applies to external users:

1. Under Users, include Guest or external users and specifically target B2B collaboration guest users and/or B2B collaboration member users.
2. Under Conditions > Filter for devices, consider whether your policy should apply differently to managed vs. unmanaged devices crossing tenant boundaries.
3. Under Grant, if you require MFA, also check "Require multifactor authentication to be satisfied by MFA claim in the token", this honors MFA the user already completed in their home tenant, assuming you've set up MFA trust in cross-tenant access settings.
4. For named locations, ensure your policies don't inadvertently block IP ranges from the partner tenant's office locations.

For SSO to work across tenants, the applications in your tenant need to be configured to accept B2B users. In Enterprise applications, for each app, check Properties and confirm Assignment required is either set to No, or the synced B2B users have been assigned. Many teams forget that cross-tenant synchronization creates the user, but application assignment is separate.

# Query Conditional Access sign-in logs to diagnose failures
# Look for CAE interrupts or MFA failures for B2B users
Connect-MgGraph -Scopes "AuditLog.Read.All"

# Get sign-in logs filtered to B2B cross-tenant sign-ins
GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$filter=crossTenantAccessType eq 'b2bCollaboration'

When this is configured correctly, users from partner tenants will sign in with their home tenant credentials, satisfy MFA once at their home tenant, and access resources in your tenant without being challenged again. That's the seamless SSO experience the whole multitenant organization setup is designed to deliver.

You've got the identity plumbing working, now let's make sure Microsoft 365 actually knows about it. Microsoft 365 multitenant people search is what lets users in one tenant find and contact users in another tenant of the same multitenant organization through Outlook, Teams, and other apps. Without this, users can technically access resources cross-tenant but can't discover each other organically.

People search for B2B collaboration users works when two conditions are both true:

1. The B2B collaboration users have been synchronized into the target tenant via cross-tenant synchronization (from Step 3).
2. Those users are shown in the address list (not hidden from the Global Address List).

By default, B2B guest users are hidden from the Global Address List. B2B member users are not hidden. So if you provisioned users as Guest type rather than Member type, you need to either change their user type or explicitly show them in the address list. You can do this in the Entra admin center under the user's profile, or at scale via PowerShell:

# Change a B2B user's ShowInAddressList property via Microsoft Graph
PATCH https://graph.microsoft.com/v1.0/users/{userId}
Content-Type: application/json

{
  "showInAddressList": true
}

For Microsoft Teams specifically, if you configured B2B direct connect (from Step 2), users from partner tenants will be visible in Teams for shared channel collaboration without needing a directory entry in your tenant at all. This is a different path from B2B collaboration, users appear in Teams but nowhere else in your Microsoft 365 environment.

For Viva Engage and other Microsoft 365 apps, the multitenant organization feature (the formal boundary you created in Step 1) enables deeper integration. Users elevated to Member type in your tenant get access to most Microsoft 365 applications as if they were internal users, not with the limited guest access profile.

To validate people search is working: from a user account in your tenant, open Outlook on the web at outlook.office.com, start a new email, and type the name of a known synced user from the partner tenant. If they appear in autocomplete with their name and correct email, cross-tenant people search is working. If they don't appear, check the provisioning logs and the address list setting. It typically takes up to 24 hours after provisioning for address book data to fully propagate across Exchange Online.