Cross-Tenant Synchronisation (Microsoft Entra ID)

What Cross-Tenant Synchronisation Changes in Entra ID

Cross-Tenant Synchronisation moves identity data and account attributes across tenant boundaries so collaboration can work more smoothly, but it also changes where trust is established and where access decisions can propagate. That makes the feature more than a convenience setting, because its scope directly affects who can appear in another tenant and under what conditions.

The practical consequence is that a tenant should treat synchronisation policy as a boundary control, not a simple directory preference. If the wrong users, groups, or attributes are included, the receiving tenant may inherit identities that look legitimate but were not meant to exist there in the first place.

How Cross-Tenant Synchronisation Works

At a high level, the feature creates a controlled path for identity projection between two Microsoft Entra tenants. It is commonly used for mergers, managed partnerships, and shared operations where separate directories still need a workable collaboration model.

The important distinction is that synchronisation is not the same as merging tenants. The source and target remain separate, but selected identities and their relationships can be replicated or represented across that tenant boundary, which means administrators must think carefully about direction, scope, and governance.

Because the feature is designed for cross-organisation cooperation, it often sits near other Entra settings such as inbound and outbound trust, B2B collaboration, and group-based access. The security question is not whether the feature is useful, but whether the trust path it creates is narrower than the business need.

Where the Security Boundaries Are

The main boundary is tenant scope, followed by the policy rules that decide which identities are eligible to synchronise. Restricting the scope to the minimum necessary users and groups helps reduce accidental exposure and keeps the synchronised footprint understandable to both sides.

Another boundary is the trust relationship itself. If inbound and outbound trust settings are broader than intended, a synchronised identity can end up carrying more access than the collaboration scenario requires, especially when administrators assume the remote tenant is already trusted by default.

For this reason, the feature should be assessed alongside broader federation and trust design. NHIMG’s Federation and Trust Relationships Guide is useful here because it explains how trust relationships can widen exposure when they are not deliberately constrained.

Operational and Identity Implications

Cross-tenant synchronisation can simplify lifecycle management, but it also introduces an identity governance problem: the same person may now exist in more than one tenant with different effective access, naming, and ownership expectations. That makes joiner, mover, and leaver handling more complex, not less.

Administrators should also expect review and remediation work after any change to synchronisation scope. If a user, group, or role was synchronised too broadly, the receiving tenant may already have made access decisions based on that representation, so fixing the source policy is only part of the response.

For teams managing Entra estates, NHIMG’s Active Directory and Entra ID Hardening Guide provides the broader hardening context, while the Privileged Identity Management (PIM) Guide is the right companion when synchronised access can touch privileged roles or activation workflows.

Monitoring and Control Points

Good monitoring focuses on tenant-to-tenant identity flows, unexpected scope expansion, and changes to trust policy. If synchronised identities begin appearing where they were not expected, that may indicate a configuration drift problem, an overly permissive sync rule, or an abuse path that deserves immediate review.

It is also important to review who can administer the synchronisation configuration itself. Control over the feature can be as sensitive as the identities it moves, because changing the policy can silently widen access without any obvious end-user action.

For that reason, cross-tenant synchronisation should be governed with the same seriousness as other identity-control changes: limit the configuration surface, log policy changes, and verify that collaboration scenarios still match the original trust intent after every adjustment.

Risk and Threat Considerations

Cross-tenant synchronisation creates a material exposure surface because a mis-scoped policy can project identities, attributes, or access relationships into a tenant that should not receive them. The result is often not a dramatic break, but a quiet expansion of trust that is harder to notice than an overt breach.

Failure mechanism: Overbroad inclusion rules, weak trust settings, or poor change control can let a synchronised identity gain visibility or access beyond the intended collaboration boundary, and attackers may try to abuse that path if they can influence the source tenant or the synchronisation configuration.

Impact: The likely consequences are unwanted trust, overexposed accounts, lateral movement across tenant boundaries, and a wider blast radius if one tenant is compromised or a synchronised identity is misused.

Practitioner Guidance

Governance implication: Treat the synchronisation policy as a controlled trust decision, not a convenience setting. Ownership should sit with the team that understands both tenants' access model, because the security outcome depends on how identity scope, trust direction, and collaboration intent line up.

What to watch for: Review which users and groups are synchronised, verify inbound and outbound trust settings, and check that the resulting identities still match the least-privilege intent of the collaboration use case. If the feature is supporting a merger, partner relationship, or shared operations model, revalidate the configuration whenever that relationship changes.

Related resources from NHI Mgmt Group

• How should security teams implement Microsoft Entra ID SSO with SAML in a multi-tenant application without creating inconsistent access policies?
• Who is accountable when Entra ID ownership leads to tenant compromise?
• How should security teams manage configuration drift in Microsoft 365 and Entra ID?
• How should security teams implement IAM resilience for Microsoft Entra ID in hybrid identity environments?