Getting Identities to Talk Across Tenants with Microsoft Entra Cross-Tenant Synchronization

If you have been working in Microsoft 365 for any length of time, you have probably run into a situation where you needed users from one tenant to have access to resources in another. Maybe your organization acquired another company. Maybe you have a subsidiary that runs its own tenant. Maybe you are operating in both commercial and government cloud environments simultaneously. Whatever the reason, managing identities across tenant boundaries is one of those problems that sounds simple until you actually have to do it.

The traditional approach has been B2B guest invitations. You invite the user, they accept, and they show up in your directory as a guest. It works fine for a handful of people. At scale, though, it becomes a mess. Attributes drift. People leave the source organization, and their guest accounts linger. Display names go stale. Someone has to manually track all of it, and that someone is usually you.

Microsoft Entra Cross-Tenant Synchronization (CTS) is the automated solution to that problem. Instead of managing guest accounts by hand, you configure a provisioning engine to handle creation, updates, and removals automatically.

So What Is It?

Cross-Tenant Synchronization is a feature of Microsoft Entra ID that automatically provisions and manages users across two separate tenants. You have a source tenant where your users live, and a target tenant where you want those users to appear. CTS keeps the two in sync without you having to do anything manually once it is set up.

It is built on the same provisioning engine that Microsoft uses for automated user provisioning to SaaS applications. If you have ever configured app provisioning in Entra ID, the concepts will feel familiar. If you have not, do not worry about that yet. The important thing to understand right now is that this is not a one-time operation. It is an ongoing, automated relationship between two tenants.

What Can It Do?

The most obvious thing CTS does is create users in the target tenant based on what exists in the source. When you add someone to the sync configuration, they are automatically provisioned in the target. No invitation required, no manual steps, no waiting on end users to accept anything.

Beyond creation, it keeps user attributes up to date. Things like display names, job titles, departments, email addresses, and manager information stay consistent across both tenants as long as the sync is running. If something changes in the source, it flows through to the target on the next cycle.

It also handles deprovisioning. When a user leaves scope, either because they left the organization or because you removed them from the configuration, they get removed from the target tenant as well. That alone is a significant improvement over the traditional guest model, where stale accounts often stick around long after they should have been cleaned up.

Users appear in the target tenant as B2B collaboration users. By default, they are created as external members rather than external guests, which means they behave much more like internal users across Microsoft 365 workloads. They show up in Teams directories, they have broader access to SharePoint, and they generally run into fewer friction points day to day. You can configure them as guests if that suits your environment better, but member is the default for good reason.

What About Different Cloud Environments?

Standard CTS works within the same Microsoft cloud. Commercial to commercial, or GCC-High to GCC-High. But Microsoft also supports synchronization across different cloud environments, which opens things up considerably.

You can synchronize identities between a commercial tenant and an Azure Government tenant, or vice versa. You can also go between commercial and the 21Vianet cloud used in China. This matters a lot to organizations that operate across both commercial and government environments, which is more common than you might think, particularly in the defense and federal contracting space.

The configuration for cross-cloud synchronization follows the same general pattern as the same-cloud setup, with a few additional steps to establish trust across the cloud boundary. I will cover that in detail in a later article.

Why Does This Matter?

The short answer is that it removes a significant amount of manual work and replaces it with something reliable and consistent.

If you have been managing guest accounts across tenants by hand, you know how quickly it becomes a problem. Users change roles, and their guest profile in the other tenant still shows their old job title. Someone leaves, and their guest account sits there for months. A new person joins, and someone has to remember to send them an invitation, hope they accept it, and then manually verify that the attributes look right.

CTS takes all of that off your plate. Once it is configured, it runs on its own. Accounts get created when they should, updated when they should, and removed when they should. The tenants stay consistent without requiring ongoing manual effort to maintain that consistency.

It also benefits the users themselves. With automatic invitation redemption, they do not have to take any action to appear in the target tenant. Access just works. That is a much better experience than receiving an invitation email, clicking through a consent prompt, and hoping everything is set up correctly on the other side.

For organizations running multi-tenant environments, whether that is due to a merger, a regulatory requirement, or just the way things grew over time, CTS gives you a foundation for managing identities that actually scales.