Entra Cross Tenant Synchronisation Guide: Securing Sync Between Your Own Tenants

Microsoft Entra cross-tenant synchronisation turns one tenant into an identity source for another, so a mistake or a compromise in the source tenant becomes an account in the target tenant within one sync cycle. It exists for organisations that run several Entra tenants of their own, after mergers, for regional or regulated subsidiaries, or for separate Azure resource tenants, and it is the provisioning engine behind most multitenant organisation (MTO) deployments. This guide treats sync as both a provisioning design and an attack path: how the trust is built, which settings carry the risk, how attackers have shown it can be used for lateral movement and persistence, and how to detect and govern it. It is written for identity engineers and security architects who own more than one tenant. The inbound and outbound access settings for ordinary B2B guests are covered in the Entra ID Cross-Tenant Access and B2B Guest Governance Guide; this page goes deeper on the sync relationship itself.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The source tenant is the authority. Synced users authenticate in their home tenant, and every attribute, including credentials, comes from the source, so the target inherits the source tenant's security posture.
• Three checkboxes create the trust. "Allow user synchronization into this tenant" in the target and "Automatically redeem invitations with the tenant" on both sides are what make silent account creation possible.
• Member userType is a privilege decision. The default mapping creates external members, who behave much like internal users; choose Guest unless internal-like access is needed.
• Sync is a documented attack path. An attacker with enough privilege can add a compromised user to an outbound sync scope, or enable inbound sync from a tenant they control, using only native features.
• Deleting the policy does not clean up. Users already created stay in the target, so offboarding a tenant relationship needs an explicit deprovisioning step.

How cross-tenant synchronisation works

Cross-tenant synchronisation is built on the Microsoft Entra provisioning engine. The source tenant pushes users (and optionally groups) into a target tenant; the target never pulls. Each configuration is one-way and peer to peer, so two-way collaboration needs two configurations, one in each tenant, each with its own scope. A single source can feed many targets, and one target can receive from many sources.

• Who can be synced: only internal members of the source tenant. Internal guests and external users in the source cannot be synced onward, which stops chains of guests travelling across tenants.
• What they become: external members by default, or external guests if the userType mapping is changed. Matching uses the internal alternativeSecurityIdentifier attribute, so an existing B2B guest for the same person is matched and updated rather than duplicated.
• Cycle: the initial cycle runs first, then incremental cycles at a fixed interval of about 40 minutes. Provision on demand can push a single user immediately.
• Attributes: common user attributes such as displayName and userPrincipalName, directory extension attributes, showInAddressList and, in Azure commercial only, manager. Photos and custom security attributes are not synced.
• Groups: security groups (static and dynamic) and Microsoft 365 groups in the source can be synced as static security groups in the target. Nested groups and distribution groups are not synced.
• What it does not do: it does not sync role assignments, devices or contacts, does not migrate tenants, and does not read changes made in the target. A target-side edit stays until the source user changes, then the source value overwrites it.

Microsoft positions sync for tenants owned by one organisation. For collaboration between separate legal entities its topology guidance points to connected organisations and entitlement management access packages instead, where partner users request time-limited access that is reviewed. See the Entra ID Entitlement Management and Access Packages Guide.

The trust settings that matter

Sync is enabled by a small set of settings split across the two tenants. Each one widens the trust, so each should have an owner, a change record and an alert.

Microsoft's configuration guidance names the roles for this work: Security Administrator for cross-tenant access settings in either tenant, Hybrid Identity Administrator to configure the sync job in the source, and Cloud Application Administrator or Application Administrator to assign users to a configuration. Global Administrator is not needed and should not be used for routine sync changes.

Topologies and when to use each

Microsoft documents three patterns. The choice decides how far a compromise in one tenant can spread, so make it on security grounds as well as collaboration needs.

Decision guidance: a small organisation with one production tenant and an acquired company usually needs a temporary application hub with a dated exit plan, not a permanent mesh. A large group with regulated subsidiaries should prefer a user hub or partial mesh with narrow scopes, and reserve full mesh for tenants that meet the same security baseline. A multitenant organisation allows up to 100 active tenants, a tenant can belong to only one MTO, and an MTO cannot be formed between a Cloud Solution Provider and its customer tenants.

Sync as an attack path

Vectra AI researchers described two techniques in 2023 that use only native sync features. Neither relies on a vulnerability; both need an account with enough privilege in a tenant, which is why prevention rests on privileged access control and detection.

• Lateral movement: an attacker in a compromised tenant reads the cross-tenant access policies to find partners with outbound sync configured, then adds a compromised user to the sync application's scope. If the target's inbound settings allow sync from that source, the account is created in the target and the attacker signs in with the same credentials. This maps to ATT&CK T1199 Trusted Relationship and T1078.004 Cloud Accounts.
• Backdoor: an attacker with privilege in the victim tenant adds a partner entry for a tenant they control and enables inbound user sync with automatic redemption. They can then push new accounts into the victim tenant at will, long after the original foothold is removed. This maps to T1484.002 Trust Modification and T1136.003 Cloud Account.
• Trust inheritance: with inbound MFA and device trust turned on, the attacker's accounts can satisfy the target's Conditional Access using claims issued by the tenant they control.
• Precursors: the research ties these techniques to earlier signs such as suspicious sign-ins, unusual scripting engine use against Entra and suspicious OAuth applications, so sync abuse is usually a later stage of an intrusion that started elsewhere.

Test, development and acquired tenants deserve particular attention: they often have weaker MFA coverage and fewer reviewers, yet any trust they hold towards production is as usable as the production tenant's own. Every tenant that can push users into yours sits inside your trust boundary, whether or not it gets production-grade attention.

Where identity governance fits

Synced accounts are provisioned by a service principal, not a person, and the target audit log records their creation with the actor Microsoft.Azure.SyncFabric. That makes the sync job a non-human identity with write access to your directory. Treat its configuration the way you would any privileged integration: named owner, least-privileged admin roles, change control, and alerting on scope changes. Role assignments never flow through sync, so assign target-tenant roles only through the target's own approval process, ideally eligible assignments in Privileged Identity Management. See the Privileged Identity Management (PIM) Guide.

• Lifecycle: a user deleted, unassigned, removed from an assigned group or moved out of a scoping filter in the source is soft-deleted in the target and hard-deleted after 30 days. Disabling the source account blocks sign-in in the target without deleting it.
• Access reviews in the target: review what synced users can reach in the target (groups, apps, Azure RBAC), not just whether they exist. Membership of a synced group is controlled by the source, so a review in the target cannot fix it alone. See the Access Reviews Guide.
• Licensing as a guardrail: user sync needs Microsoft Entra ID P1 per synced user in the source, and group sync needs Microsoft Entra ID Governance or Microsoft Entra Suite. Licence counts are a useful sanity check on scope growth.

How to implement safely

1. Inventory first. List every tenant you own, including test, development and acquired tenants, and record each partner entry in cross-tenant access settings with its inbound and outbound sync state and trust settings.
2. Decide the topology and userType per relationship. Write down why each pair needs sync, which direction, which population and whether users arrive as members or guests. Default to Guest.
3. Set the target first, narrowly. In the target, add the source as a partner, enable "Allow user synchronization into this tenant" only for that partner, leave group and role-enabled group sync off unless designed for, and enable inbound automatic redemption. Leave the default (non-partner) inbound sync off.
4. Configure the source with assigned scope. Create the configuration, test the connection, choose "Sync only assigned users" and assign one pilot group. Keep "Prevent accidental deletion" on at or below the default threshold and set a monitored notification email for quarantine alerts.
5. Pilot with provision on demand. Push a few test users, confirm attributes and userType in the target, confirm Conditional Access applies as designed, then start provisioning.
6. Harden the trust settings. Enable inbound MFA and device trust only for tenants that meet your own authentication and device baseline; otherwise require MFA in the target.
7. Turn on detection before expanding scope. Stream audit and provisioning logs from both tenants to your SIEM and deploy the alerts below.
8. Plan rollback and exit. To stop a relationship, remove all assignments and let the deprovisioning cycle soft-delete users while inbound sync is still allowed, then disable inbound sync in the target and delete the configuration. Deleting the policy first leaves orphaned accounts.

Detection and measurement

All sync and trust changes appear in the Entra audit log under the Core Directory service. The activities below are the ones to alert on.

Metrics that show the control is working:

• Number of partner entries with inbound sync enabled, against the approved list (target: no difference).
• Percentage of sync configurations using assigned scope rather than "Sync all users".
• Time from source leaver event to target soft-delete, measured from provisioning logs (target: within two cycles).
• Count of synced users holding target directory roles or privileged Azure RBAC assignments, each with a recorded approval.
• Sync configurations in quarantine or with failed cycles for more than 24 hours.
• Trust setting changes made outside an approved change, per quarter.

For query patterns over these events see the Entra ID Audit Log Detection Guide.

Common failure patterns

• Inbound sync left on the default policy. Enabling sync in the default cross-tenant access setting rather than per partner means any tenant that configures outbound sync can push users in. Keep it per partner only.
• Member by default, everywhere. Accepting the default Member userType gives every synced user internal-like access in the target, including directory browsing and app defaults designed for employees.
• "Sync all users" in the source. Admin accounts, test users and service-style user accounts flow into the target, enlarging the attack surface and licence cost.
• Trusting MFA from a weaker tenant. A target with phishing-resistant MFA that trusts MFA claims from a tenant still allowing SMS has effectively accepted SMS.
• Forgotten tenants inside the boundary. Acquired or test tenants keep outbound sync and privileged accounts long after the project ends, and nobody monitors their audit logs.
• Tearing down in the wrong order. Deleting the configuration or the inbound setting before deprovisioning leaves enabled accounts in the target that no longer track the source.

Framework mapping

Practitioner checklist

• Inventory every tenant you own and every partner entry with sync or automatic redemption enabled.
• Keep inbound user, group and role-enabled group sync off in the default policy; enable per partner only.
• Use "Sync only assigned users" or "Sync only assigned users and groups" and review assignments quarterly.
• Default the Member (userType) mapping to Guest unless internal-like access is justified and recorded.
• Trust inbound MFA and device claims only from tenants that meet your own baseline.
• Use Security Administrator, Hybrid Identity Administrator and Application Administrator for sync work, not Global Administrator.
• Keep "Prevent accidental deletion" on and send quarantine notifications to a monitored mailbox.
• Alert on partner, identity sync setting and MTO audit activities in both tenants.
• Assign target roles only through the target's own PIM approval; never rely on the source.
• Offboard relationships by deprovisioning first, then removing the trust.

Standards and references

• Microsoft Learn: What is cross-tenant synchronization?
• Microsoft Learn: Configure cross-tenant synchronization
• Microsoft Learn: Topologies for cross-tenant synchronization
• Microsoft Learn: What is a multitenant organization in Microsoft Entra ID?
• Microsoft Learn: Configure cross-tenant access settings for B2B collaboration
• Microsoft Learn: Microsoft Entra audit log activity reference
• MITRE ATT&CK: T1484.002 Trust Modification
• Vectra AI: Microsoft Cross-Tenant Synchronization research

Related NHI Mgmt Group resources: Entra ID Cross-Tenant Access and B2B Guest Governance Guide · Entra ID Security Guide · Conditional Access Guide · Entra ID Privileged Roles Guide · How to find multi-tenant Azure app registrations