Entra cross-tenant synchronization: connecting tenants without pretending they are one

After an acquisition, the first identity request is usually immediate: employees need to find colleagues and open Teams or SharePoint resources in the other company, while mailboxes, devices and data are not ready to move. Entra cross-tenant synchronization can make that interim state manageable. It does not create one tenant and it is not a migration engine. It automates the lifecycle of B2B identities between a source and a target. Missing that boundary can produce a better people search while quietly creating a second directory with unclear attribute ownership, Exchange address-list defects and dangerous offboarding behavior.

Decide whether the outcome is collaboration or consolidation

Cross-tenant synchronization is designed for organizations that own multiple tenants and need automated creation, update and deletion of B2B collaboration objects. The person still authenticates in the home tenant and data stays where it is. Microsoft explicitly says the service does not migrate a mailbox, OneDrive or SharePoint and that the source tenant remains necessary for authentication. If the acquisition requires one directory, one mailbox and one device-management plane, synchronization is a coexistence mechanism within the migration program, not the end state.

What actually runs between source and target

Provisioning is a one-way push from the source. The source defines scope, mappings and transformations; the target permits inbound synchronization and can stop it. Automatic redemption must be configured on both sides in the correct direction. Otherwise the user can receive a consent experience or the connection test can return an error that misleadingly resembles invalid administrator credentials. Current Microsoft documentation says the synchronization interval starts on a fixed cadence of about 40 minutes, while an initial cycle can take considerably longer than later incremental runs.

A multitenant organization adds Microsoft 365 context

A multitenant organization, or MTO, sits above tenant relationships and cross-tenant synchronization. For Teams it provisions external users with a Member user type rather than the familiar Guest type so Microsoft 365 can offer a more coherent cross-tenant experience. The Microsoft 365 admin center synchronizes the same selected users to every MTO tenant; different scopes per destination require Entra ID configuration. MTO can improve collaboration and people discovery, but it does not centrally manage Exchange, Intune or Conditional Access for every tenant.

User and group synchronization have different license floors

For same-cloud user synchronization, each synchronized person needs Entra ID P1 in the home source tenant; the target does not need a license solely for synchronization. Group synchronization and cross-cloud scenarios require Entra ID Governance or Entra Suite in the home tenant. Target services can impose their own licenses, and External ID billing can affect other external-user scenarios. Model cost by people and consumed capabilities rather than by the raw number of B2B objects.

Matching existing objects is the highest-risk pilot task

Entra matches an internal source account to an external target object through an internal alternativeSecurityIdentifier. It can bring an existing B2B object under management, but cannot merge two internal Member accounts that already exist in both tenants. Default mappings also do not necessarily change a historic Guest to Member unless userType is deliberately mapped. Before starting, create a matrix of home account, target object, mailbox, UPN, primary SMTP, object ID and intended result. Without that evidence, a duplicate may first become visible in a people picker or Teams rather than in the provisioning wizard.

Exchange attributes need a separate design

The subtle failures often live in Exchange. Cross-tenant synchronization creates a B2B user, not a mail contact, and it cannot generally write every Exchange attribute. proxyAddresses can be read-only in the target, targetAddress is not a normal mapping target and address-list visibility is not governed like an ordinary Entra property. showInAddressList can support people search, but it does not prove mail routing, free/busy or a coherent GAL. Test those outcomes separately; never infer the mail design from the presence of an Entra object.

Scope by target resource, not only by the org chart

Start with people who need specific target applications. Synchronizing everyone may improve discovery, but it also expands the population covered by target Conditional Access, reporting, privacy notices and offboarding. Group sync has additional boundaries: target objects are static security groups, not Microsoft 365 groups, distribution groups or mail-enabled security groups; nested and role-assignable groups are unsupported. Group synchronization requires “Sync only assigned users and groups.” A dynamic source group can select members, but the resulting target group is static.

Deprovisioning changes access; it is not directory housekeeping

Removing a person from synchronization scope soft-deletes the target object. That is safe only when the team understands its application assignments, group membership, ownership and recovery window. A deleted object can normally be restored for 30 days, but on-demand provisioning might not revive it automatically; creating a replacement can introduce a duplicate. Keep inbound sync enabled until controlled deprovisioning completes. Explicitly test the sequence of blocking sign-in, removing scope, restoring and permanent deletion, and document which tenant is authoritative for accountEnabled.

Hub-and-spoke and mesh topologies carry different operating costs

Every source-to-target direction is a separate configuration. A three-tenant mesh is therefore several trust relationships, mapping sets and log streams, not one service. Hub-and-spoke reduces the connection count but makes the hub critical to application access. Count configurations, owners, break-glass procedures and deprovisioning flows in each direction. External objects are not forwarded again, which prevents loops but also means an identity does not transit automatically through a middle tenant.

A six-step rollout

1. 01

   Define identity home

   Assign one authoritative tenant per person and prohibit parallel internal accounts

2. 02

   Inventory collisions

   Locate historic guests, members, contacts, mailboxes and duplicate addresses

3. 03

   Design minimum scope

   Select the pilot by target resources and risk rather than department alone

4. 04

   Configure bilateral trust

   Verify inbound sync, automatic redemption, MFA trust and Conditional Access

5. 05

   Exercise the lifecycle

   Test create, update, manager change, block, remove, restore and hard deletion

6. 06

   Expand with telemetry

   Track provisioning errors, sign-ins, duplicates and experience in Teams, SharePoint and the directory

Measure three independent layers after launch

An operating dashboard should separate provisioning health, Microsoft 365 usability and the security outcome. Monitor scope size, success and error counts per cycle, age of the latest change, duplicates, unexpected re-enablement and soft deletions. From the employee view, test sign-in, people discovery, Teams entry and SharePoint access. Security validation must test actual authorization and Conditional Access in the target. A green provisioning job proves neither a secure design nor correct mail flow.

When cross-tenant synchronization is the wrong tool

For suppliers or partners outside one corporate group, Microsoft points toward entitlement management and standard B2B governance; cross-organization synchronization can create additional privacy, legal and consent responsibilities. It is also a poor shortcut around a migration plan or an attempt to manage a subsidiary’s devices from headquarters without an Intune design. It works best when tenant ownership, identity home and offboarding accountability are unambiguous.