Microsoft Entra ID Cross-Tenant Synchronization

Microsoft Entra ID Cross-Tenant Synchronization is a Cloud Identity Feature that automatically shares and manages Users across multiple Microsoft Entra Tenants, enabling Organizations to collaborate securely and efficiently without manually creating or managing guest accounts.
Microsoft Entra ID Cross-Tenant Synchronization is a feature that allows two different organizations or Microsoft Cloud Environments (called Tenants) to automatically share Users.
In this document, we are using Contoso as the Source Tenant and Fabrikam as the Target Tenant.

Definition of Source and Target Tenants: Source (Send Identity Out --> Target (Receives Identity In)

Source Tenant (Contoso, the Tenant Exporting or Sharing Users)

• Sends the Identities Out
• Owns the original User Accounts
• Is the Authoritative Identity Source
• Controls Authentication, Passwords, MFA, and Lifecycle

Target Tenant (Fabrikam the Tenant Importing or Receiving Users)

• Receives the identities
• Creates Synchronized B2B Users
• Grants Access to Resources and Applications
• Trusts the Source Tenant's Authentication

Contoso (Source) has its own Microsoft Entra Environment.
Fabrikam (Target)has its own Microsoft Entra Environment.

Normally, if users from Company Contoso need access to Apps, Teams, SharePoint, or Resources in Fabrikam, Administrators must manually invite them one by one as Guest Users.

Cross-Tenant Synchronization automates that process.

What It Does It automatically:

Creates user accounts between tenants
Updates user information
Removes access when users leave
Keeps identities synchronized

This allows users from one company or tenant to securely access resources in another tenant without creating separate passwords or separate full accounts.

Real-World Example

A Parent company owns multiple companies
Each company has its own Microsoft 365 Tenant
An employee named John works in Tenant Contoso but needs access to:
Teams, SharePoint, Applications, Email collaboration, inside Tenant Fabrikam.

Cross-Tenant Synchronization automatically creates John's identity in Fabrikam Tenant so he can work there using his normal login from Contoso Tenant. John signs in once using his home Contoso company credentials and gains secure access to the second Fabrikam environment.

What makes it so valuable, without Cross-Tenant Sync:
Administrators manually invite users, and access may become messy; old guest accounts must be reviewed, cleaned, and maintained. Security becomes more demanding and difficult to manage.

With Cross-Tenant Sync, everything is automated, access stays up to date, security is centralized, and the user lifecycle is controlled automatically.

The main goal is: Easier Collaboration between Organizations or Tenants, better Security, less Manual Administration, and Automatic Identity Management.

Common Use Cases

Organizations use it for:
Mergers and acquisitions
Multiple company divisions
Global enterprises
Partner collaboration
Shared IT environments
Multi-tenant Microsoft 365 deployments

Key Thing to Understand
The user still belongs to their Original Company.
Cross-Tenant Synchronization does NOT:
Copy Passwords
Move the User Permanently
Create a Separate, Independent Identity

Instead:
It creates a Trusted Linked Identity in another Tenant.

Main Benefits

Automatic User Provisioning
Automatic Deprovisioning
Easier Teams Collaboration
Centralized Identity Management
Reduced Administrative Work
Improved Security
Better User Experience

Flow: User exists in Source Tenant -> Source Tenant Sends/Synchronizes Identity -> Target Tenant Receives Identity -> User Gains Access to Apps/Resources in Target Tenant

Supported Cloud Pairs
Cross-Tenant Synchronization Supports These Cloud Pairs:

Source                       Target                       Azure Portal Link Domains
Azure Commercial      Azure Commercial     portal.azure.com --> portal.azure.com
Azure Government     Azure Government    portal.azure.us --> portal.azure.us
21Vianet (China)         21Vianet (China)       portal.azure.cn --> portal.azure.cn  

Prerequisites:

Source Tenant Prerequisites

1. Microsoft Entra ID Tenant
   The organization must have:

• A valid Microsoft Entra tenant
• Microsoft 365 or Azure subscription associated with the tenant

The source tenant is where the user identities already exist.

2. Microsoft Entra Licensing
   Typically requires:

• Microsoft Entra ID P1
  or
• Microsoft Entra ID P2

Depending on the features being used.

3. Global Administrator or Appropriate Permissions
   Administrative permissions are required to configure:

• Cross-tenant access settings
• Provisioning
• Synchronization policies
• User assignments

Common required roles:

• Global Administrator
• Hybrid Identity Administrator
• Application Administrator
• Cloud Application Administrator

4. Users Must Exist in Source Tenant
   The identities being synchronized must already exist in the source tenant.

Supported users may include:

• Cloud-only users
• Hybrid synchronized users
• Federated users

5. Cross-Tenant Access Configuration
   The source tenant must configure:

• Outbound access settings
• Trust relationships
• Allowed organizations (target tenants)

This establishes which external tenants can receive identities.

6. Automatic Provisioning Enabled
   Provisioning must be configured and enabled.

This includes:

• Provisioning scope
• User/group assignments
• Synchronization mappings

7. Internet Connectivity to Microsoft Cloud Services
   Since synchronization is cloud-based, the tenant must allow communication with:

• Microsoft Entra services
• Microsoft Graph services
• Provisioning endpoints

8. Allowed User Scope
   Administrators should define which users are synchronized.

Options commonly include:

• All users
• Specific groups
• Assigned users only

Best Practice:

• Use scoped groups instead of syncing everyone.

9. B2B Collaboration Must Be Enabled
   The source tenant must support:

• External Collaboration
• B2B Synchronization
• Cross-Tenant Identity Tust

10. Matching Target Tenant Trust
    The target tenant must trust the source tenant.

Without Mutual Configuration:

• Synchronization will fail
• Users cannot authenticate properly

11. Optional MFA and Device Trust
    For advanced secure collaboration:

• MFA trust may be configured
• Device compliance trust may be configured
• Conditional Access trust may be configured

This improves User Experience and Security.

12. Provisioning Agent Not Required
    Unlike Older Hybrid Synchronization Methods:

• No on-premises provisioning agent is required
• No Azure AD Connect requirement specifically for Cross-Tenant Sync itself

The feature is fully Cloud-Native.

The Source Tenant must:

• Own the users
• Have Entra licensing
• Configure outbound trust
• Enable provisioning
• Define which users are synchronized
• Allow secure collaboration with the target tenant

Target Tenant Prerequisites

1. Microsoft Entra ID Tenant
   The organization must have:

• A valid Microsoft Entra tenant
• Microsoft 365 or Azure subscription

This is the tenant receiving synchronized users.

2. Microsoft Entra Licensing
   Typically requires:

• Microsoft Entra ID P1
  or
• Microsoft Entra ID P2

depending on features and governance requirements.

3. Administrative Permissions
   Administrators need permissions to configure:

• Cross-tenant access settings
• External collaboration
• Provisioning
• Trust policies

Common Required Roles:

• Global Administrator
• Application Administrator
• Cloud Application Administrator
• External Identity Administrator

4. Inbound Cross-Tenant Access Configuration
   The target tenant must configure:

• Inbound trust settings
• Allowed source tenants
• Collaboration permissions

This tells the Target Tenant:

• Which external tenants are trusted
• Which identities are allowed in

5. B2B Collaboration Must Be Enabled
   The target tenant must allow:

• External Identities
• B2B collaboration users
• Guest/member synchronization

Without B2B enabled:

• External synchronized users cannot be created.

6. Automatic Redemption Configuration
   Optional but recommended:

• Enable automatic redemption

This removes the need for users to manually accept invitation emails.

It creates a seamless SSO experience.

7. Provisioning Must Be Enabled
   The target tenant must allow:

• Automatic user creation
• User updates
• Deprovisioning

This enables lifecycle Automation.

8. User and Group Scope Configuration
   Administrators should define:

• Which synchronized users are allowed
• Which groups/apps they can access

Best Practice:

• Use Least Privilege Access.

9. Conditional Access Planning
   The Target Tenant should configure:

• MFA Trust Policies
• Conditional Access Rules
• Device Compliance Policies

This Controls:

• Who can access resources
• Under what security conditions

10. Applications and Resources Must Exist
    The resources users need access to must already exist in the target tenant.

Examples:

• Teams
• SharePoint
• Enterprise applications
• SaaS apps
• Azure resources

11. Matching Trust with Source Tenant
    The target tenant must trust the source tenant.

Both tenants must establish:

• Mutual trust
• Allowed synchronization policies

12. Sufficient Directory Capacity
    The target tenant must allow:

• Additional B2B users
• External identities
• Synchronization objects

Large environments should plan for:

• Directory scale
• Governance
• Access reviews

13. Monitoring and Auditing
    Recommended prerequisites include:

• Provisioning logs enabled
• Audit logging enabled
• Identity governance monitoring

This helps track:

• User creation
• Access activity
• Synchronization errors

The Target Tenant must:

• Receive identities
• Trust the source tenant
• Allow B2B collaboration
• Enable automatic provisioning
• Control access to resources
• Apply security and Conditional Access policies

Step 1: Allow User and Group Synchronization in The Target Tenant (Fabrikam)

(As of May 25, 2026, Cross-Tenant Group Synchronization in Microsoft Entra ID is still considered a Preview feature in Microsoft documentation and rollout communications)

Under Inbound Access of the added Organization, select Inherited from Default.
Select the Cross-Tenant Sync tab.
Select the Allow User Synchronization into this Tenant checkbox.
Optionally, select the Allow Group Synchronization (Preview as of 5-25-2026) into this Tenant checkbox.

Select Save
If you see an Enable Cross-Tenant Sync and Auto-Redemption dialog box asking if you want to enable auto-redemption, select Yes.
Selecting Yes will Automatically Redeem Invitations in the Target Tenant.

Step 2: Automatically Redeem Invitations in the Target Tenant (Fabrikam)

In the target tenant, on the same Inbound access settings page, select the Trust settings tab.
Check the Automatically redeem invitations with the tenant <tenant> checkbox.
This box might already be checked if you previously selected Yes in the Enable cross-tenant sync and auto-redemption dialog box.

Select Save

Step 3: Automatically Redeem Invitations in the Source Tenant (Contoso)

In this Step, you Automatically Redeem Invitations in the Source Tenant.
Sign in to the Microsoft Entra Admin Center of the Source Tenant.
Browse to Entra ID > External Identities > Cross-Tenant Access Settings.
On the Organization Settings Tab, select Add Organization.
Add the Target Tenant by typing the Tenant ID or Domain Name and selecting Add.

Under Outbound Access for the Target Organization (Fabrikam), select Inherited from Default.
Select the Trust settings tab.
Check the Automatically Redeem Invitations with the Tenant checkbox.

Select Save

Step 4: Create a Configuration in the Source Tenant

In the Source Tenant, browse to Entra ID > External Identities > Cross-Tenant Synchronization.

If you are using the Azure Portal, browse to Microsoft Entra ID > Manage > Cross-Tenant Synchronization.

Select Configurations.
At the top of the page, select New Configuration.
Provide a name for the configuration.

Select Create

It can take up to 15 seconds for the configuration that you just created to appear in the list.

Step 5: Test the connection to the Target Tenant (Fabrikam)

In the Source Tenant, you should see your New Configuration. If not, in the Configuration List, select your Configuration.

Select Get started.
Set the Provisioning Mode to Automatic.
Under the Admin Credentials section, change the Authentication Method to Cross Tenant Synchronization Policy.

In the Tenant ID box, enter the Tenant ID of the Target Tenant.
Select Test Connection to test the connection.
You should see a message that "The supplied credentials are authorized to enable provisioning". If the test connection fails, reference Common Scenarios and Solutions later in this Article.

Select Save

Mappings and Settings Sections appear.
Close the Provisioning Page.

Step 6: Define Who is in Scope for Provisioning

The Microsoft Entra provisioning service allows you to define who will be provisioned in one or both of the following ways:

• Based on assignment to the configuration
• Based on attributes of the user

Start small. Test with a small set of users before rolling out to everyone. When the scope for provisioning is set to assigned users and groups, you can control it by assigning one or two users to the configuration. You can further refine who is in scope for provisioning by creating attribute-based scoping filters, described in the next step.

In the source tenant, select Provisioning and expand the Settings section.

In the Scope List, select whether to Synchronize All Users in the Source Tenant or only Users Assigned to the Configuration.
It's recommended that you select Sync Only Assigned Users and Groups instead of Sync All Users. Reducing the Number of Users in Scope Improves Performance.
If you want to Synchronize Groups, you must select Sync Only Assigned Users and Groups.
If you made any changes, select Save.
On the configuration page, select Users and Groups.
For Cross-Tenant Synchronization to work, at least one Internal User must be assigned to the configuration.
Select Add User/Group.
On the Add Assignment page, under Users and Groups, select None Selected.
On the Users and Groups Pane, search for and select One or More Internal Users and Groups you want to Assign to the Configuration.
If you select a Group to Assign to the Configuration, only Users who are Direct Members in the Group will be in Scope for Provisioning. You can select a Static Group or a Dynamic Group. The Assignment Doesn't cascade to Nested Groups.
Select Select.
Select Assign.

Step 7: (Optional) Define Who is in Scope for Provisioning with Scoping Filters

Regardless of the value you selected for Scope in the previous step, you can further limit which Users are Synchronized by creating Attribute-Based Scoping filters.
In the Source Tenant, select Provisioning and expand the Mappings Section.

Select Provision Microsoft Entra ID Users to open the Attribute Mapping page.
Under Source Object Scope, select All records.

On the Source Object Scope page, select Add Scoping Filter.
Add any scoping filters to define which users are in scope for provisioning.
To configure scoping filters, refer to the instructions provided in Scoping users or groups to be provisioned with scoping filters.

Select OK and Save to save any changes.
If you added a filter, you'll see a message that saving your changes will result in all assigned users and groups being resynchronized. This may take a long time depending on the size of your directory.

Select Yes and close the Attribute Mapping page.
On the Provisioning page, under the Mappings section, select Provision Microsoft Entra ID Groups to open the Attribute Mapping page.
If you want to Synchronize Groups, set the Enabled Toggle to Yes.
By Default, this toggle is set to No.
If you want to Scoping Filters for Groups, follow similar previous Steps as Users.

Step 8: Review Attribute Mappings

Attribute Mappings allow you to define how data should flow between the Source Tenant and the Target Tenant.

For information on how to customize the default attribute mappings, see Tutorial - Customize user provisioning attribute-mappings for SaaS applications in Microsoft Entra ID.
In the Source Tenant, select Provisioning and Expand the Mappings Section.
Select Provision Microsoft Entra ID Users.
On the Attribute Mapping page, scroll down to review the User Attributes that are Synchronized between Tenants in the Attribute Mappings Section.
The First Attribute, alternativeSecurityIdentifier, is an Internal Attribute used to uniquely Identify the User across Tenants, match Users in the Source Tenant with existing Users in the Target Tenant, and ensure that each User only has one Account. The matching Attribute can't be changed. Attempting to change the matching attribute or adding additional matching attributes will result in a schemaInvalid error.

Select the Member (userType) Attribute to Open the Edit Attribute page.
Review the Constant Value Setting for the userType Attribute.
This setting defines the type of User that will be created in the Target Tenant and can be one of the Values in the following Table. By Default, Users will be created as External Member (B2B Collaboration Users).

For more information, see Properties of a Microsoft Entra B2B collaboration user.

Constant Value Description
Member    
Default. Users will be created as External Member (B2B Collaboration Users) in the Target Tenant. Users will be able to function as any internal member of the target tenant.
Guest: Users will be created as External Guests (B2B Collaboration Users) in the Target Tenant.

Note
If the B2B user already exists in the target tenant, then Member (userType) won't be changed to Member, unless the Apply this Mapping Setting is set to Always.
The user type you choose has the following limitations for apps or services (but aren't limited to):

App or Service Limitations
Power BI:  Support for a UserType value of Member in Power BI is currently in preview.

For more information, see Distribute Power BI content to external guest users with Microsoft Entra B2B.

Azure Virtual Desktop: For limitations, see Prerequisites for Azure Virtual Desktop.
Microsoft Teams: For limitations, see Collaborate with Guests from other Microsoft 365 Coud Environments.

If you want to define any transformations, on the Attribute Mapping page, select the Attribute you want to transform, such as displayName.
Set the Mapping type to Expression.
In the Expression box, enter the transformation expression.

For example, with the Display Name, you can do the following:
Flip the First Name and Last Name and add a Comma in between.
Add the Domain Name in parentheses at the end of the display name.
For example, see Reference for writing expressions for attribute mappings in Microsoft Entra ID.

On the Provisioning page, under the Mappings section, select Provision Microsoft Entra ID Groups to open the Attribute Mapping page.
If you want to Modify Attribute mappings for Groups, follow the previous steps as users.

Tip
You can map directory extensions by updating the Schema of the Cross-Tenant Synchronization. 
For more information, see Map Directory Extensions in cross-tenant synchronization.

Step 9: Specify Additional Provisioning settings

In the Source Tenant, select Provisioning and expand the Settings Section.

Select the Send an Email Notification when a Failure Occurs checkbox.
In the Notification Email box, enter the Email Address of a Person or Group who should receive Provisioning Error Notifications.
Email Notifications are sent within 24 Hours of the Job Entering Quarantine State. For Custom Alerts, see Understand how Provisioning Integrates with Azure Monitor Logs.
To prevent Accidental Deletion, select Prevent Accidental Deletion and Specify a threshold value. By Default, the threshold is set to 500.
For more information, see Enable accidental deletions prevention in the Microsoft Entra provisioning service.
Select Save to save any Changes.

Step 10: Test Provision on DemandNow, that you have a configuration, you can Test On-Demand Provisioning with one of your Users.
In the Source Tenant, browse to Entra ID > External Identities > Cross-Tenant Synchronization.
Select Configurations and then select your Configuration.
Select Provision on Demand.
In the Select a User or Group box, search for and select one of your Test Users.

Select Provision.
After a few moments, the Perform Action page appears with information about the provisioning of the test user in the target tenant.

If the user isn't in scope, you'll see a page with information about why the test user was skipped.

On the Provision on Demand page, you can view details about the provision and have the option to retry.
In the target tenant, verify that the test user was provisioned.

If all is working as expected, assign additional users to the configuration.
For more information, see On-demand provisioning in Microsoft Entra ID.

Step 11: Start the Provisioning Job

The provisioning job starts the initial synchronization cycle of all users defined in the Scope of the Settings section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Microsoft Entra provisioning service is running.
In the source tenant, browse to Entra ID > External Identities > Cross-Tenant Synchronization.
Select Configurations and then select your configuration.
On the Overview page, review the provisioning details.

Select Start Provisioning to start the Provisioning Job

Step 12: Monitor Provisioning

Select Provisioning Logs to determine which users have been provisioned successfully or unsuccessfully. By default, the logs are filtered by the service principal ID of the configuration.

For more information, see Provisioning logs in Microsoft Entra ID.

Select Audit logs to view all logged events in Microsoft Entra ID. For more information, see Audit logs in Microsoft Entra ID.

You can also view audit logs in the target tenant.
In the target tenant, select Users > Audit logs to view logged events for user management. Cross-tenant synchronization in the target tenant will be logged as the actor being the "Microsoft.Azure.SyncFabric" application.

Step 13: Configure leave settings

Even though users are being provisioned in the target tenant, they still might be able to remove themselves. If users remove themselves and they are in scope, they'll be provisioned again during the next provisioning cycle. If you want to disallow the ability for users to remove themselves from your organization, you must configure the External user leave settings.

1. In the target tenant, browse to Entra ID > External Identities > External collaboration settings.
   2. Under External user leave settings, choose whether to allow external users to leave your organization themselves.
   
2. This setting also applies to B2B collaboration and B2B direct connect, so if you set External user leave settings to No, B2B collaboration users and B2B direct connect users can't leave your organization themselves. For more information, see Leave an organization as an external user.

Common Scenarios and Solutions
Symptom - Test connection fails with AzureActiveDirectoryCrossTenantSyncPolicyCheckFailure

When configuring Cross-Tenant Synchronization in the source tenant and you test the connection, it fails with one of the following error messages:

Automatic redemption is not setup in the source tenant

You have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: AzureActiveDirectoryCrossTenantSyncPolicyCheckFailure
Details: The source tenant has not enabled automatic user consent with the target tenant. Please enable the outbound cross-tenant access policy for automatic user consent in the source tenant. aka.ms/TroubleshootingCrossTenantSyncPolicyCheck

Automatic redemption is not set up in the target tenant
You appear to have entered invalid credentials. Please confirm you are using the correct information for an administrative account.
Error code: AzureActiveDirectoryCrossTenantSyncPolicyCheckFailure
Details: The target tenant has not enabled inbound synchronization with this tenant. Please request the target tenant admin to enable the inbound synchronization on their cross-tenant access policy. Learn more: aka.ms/TroubleshootingCrossTenantSyncPolicyCheck

Cause
This error indicates the policy to automatically redeem invitations in the source and / or target tenants wasn't set up.

Solution
Follow the steps in Step 3: Automatically redeem invitations in the target tenant and Step 4: Automatically redeem invitations in the source tenant.
Symptom - Automatic redemption checkbox is disabled

When configuring cross-tenant synchronization, the Automatic redemption checkbox is disabled.

Cause
Your tenant doesn't have a Microsoft Entra ID P1 or P2 license.

Solution
You must have Microsoft Entra ID P1 or P2 to configure trust settings.
Symptom - Recently deleted user in the target tenant is not restored
After soft deleting a synchronized user in the target tenant, the user isn't restored during the next synchronization cycle. If you try to soft delete a user with on-demand provisioning and then restore the user, it can result in duplicate users.

Cause
Restoring a previously soft-deleted user in the target tenant isn't supported.

Solution
Manually restore the soft-deleted user in the target tenant. For more information, see Restore or remove a recently deleted user using Microsoft Entra ID.

Symptom - Users are skipped because SMS sign-in is enabled on the user
Users are skipped from synchronization. The scoping step includes the following filter with status false: "Filter external users.alternativeSecurityIds EQUALS 'None'"

Cause
If SMS sign-in is enabled for a user, they will be skipped by the provisioning service.
Solution
Disable SMS Sign-in for the users. The script below shows how you can disable SMS Sign-in using PowerShell.

PowerShell
##### Disable SMS Sign-in options for the users

#### Import module
Install-Module Microsoft.Graph.Users.Actions
Install-Module Microsoft.Graph.Identity.SignIns
Import-Module Microsoft.Graph.Users.Actions

Connect-MgGraph -Scopes "User.Read.All", "Group.ReadWrite.All", "UserAuthenticationMethod.Read.All","UserAuthenticationMethod.ReadWrite","UserAuthenticationMethod.ReadWrite.All"

##### The value for phoneAuthenticationMethodId is 3179e48a-750b-4051-897c-87b9720928f7

$phoneAuthenticationMethodId = "3179e48a-750b-4051-897c-87b9720928f7"

#### Get the User Details

$userId = "objectid_of_the_user_in_Entra_ID"

#### validate the value for SmsSignInState

$smssignin = Get-MgUserAuthenticationPhoneMethod -UserId $userId

    if($smssignin.SmsSignInState -eq "ready"){   
      #### Disable Sms Sign-In for the user is set to ready

      Disable-MgUserAuthenticationPhoneMethodSmsSignIn -UserId $userId -PhoneAuthenticationMethodId $phoneAuthenticationMethodId
      Write-Host "SMS sign-in disabled for the user" -ForegroundColor Green
    }
    else{
    Write-Host "SMS sign-in status not set or found for the user " -ForegroundColor Yellow
    }

End the script

Symptom - Group skipped due to EntityTypeNotSupported
Group is skipped from synchronization because EntityTypeNotSupported.

Cause
This message likely indicates that group synchronization is not enabled in the source tenant.

Solution
In the source tenant, on the Provisioning page, under the Mappings section, select Provision Microsoft Entra ID Groups to open the Attribute Mapping page. Make sure the Enabled toggle is set to Yes. For more information, see Step 8: (Optional) Define who is in scope for provisioning with scoping filters.

Symptom - Users fail to provision with error AzureActiveDirectoryForbidden
Users in scope fail to provision. The provisioning logs details include the following error message:
Guest invitations not allowed for your company. Contact your company administrator for more details.

Cause
This error indicates the Guest invite settings in the target tenant are configured with the most restrictive setting: "No one in the organization can invite guest users including admins (most restrictive)".

Solution
Change the Guest invite settings in the target tenant to a less restrictive setting. For more information, see Configure external collaboration settings.
Symptom - UserPrincipalName does not update for existing B2B users in pending acceptance state
When a user is first invited through manual B2B invitation, the invitation is sent to the source user mail address. As a result the guest user in the target tenant is created with a UserPrincipalName (UPN) prefix using the source mail value property. There are environments where the source user object properties, UPN and Mail, have different values, for example Mail == user.mail@domain.com and UPN == user.upn@otherdomain.com. In this case, the guest user in the target tenant will be created with the UPN as user.mail_domain.com#EXT#@contoso.onmicrosoft.com.
The issue raises when then the source object is put in scope for cross-tenant sync and the expectation is that besides other properties, the UPN prefix of the target guest user would be updated to match the UPN of the source user (using the example above the value would be: user.upn_otherdomain.com#EXT#@contoso.onmicrosoft.com). However, that's not happening during incremental sync cycles, and the change is ignored.

Cause
This issue happens when the B2B user which was manually invited into the target tenant didn't accept or redeem the invitation, so its state is in pending acceptance. When a user is invited through an email, an object is created with a set of attributes that are populated from the mail, one of them is the UPN, which is pointing to the mail value of the source user. If later you decide to add the user to the scope for cross-tenant sync, the system will try to join the source user with a B2B user in target tenant based on the alternativeSecurityIdentifier attribute, but the previously created user doesn't have an alternativeSecurityIdentifier property populated because the invitation was not redeemed. So, the system won't consider this to be a new user object and won't update the UPN value. The UserPrincipalName isn't updated in the following scenarios:
1.The UPN and mail are different for a user when was manually invited.
2.The user was invited prior to enabling cross-tenant sync.
3.The user never accepted the invitation, so they are in "pending acceptance state".
4.The user is brought into scope for cross-tenant sync.

Solution
To resolve the issue, run on-demand provisioning for the affected users to update the UPN. You can also restart provisioning to update the UPN for all affected users. Note that this triggers an initial cycle, which can take a long time for large tenants. To get a list of manual invited users in pending acceptance state, you can use a script, see the following sample.

PowerShell
Connect-MgGraph -Scopes "User.Read.All"
$users = Get-MgUser -Filter "userType eq 'Guest' and externalUserState eq 'PendingAcceptance'" 
$users | Select-Object DisplayName, UserPrincipalName | Export-Csv "C:\Temp\GuestUsersPending.csv"

Then you can use provisionOnDemand with PowerShell for each user. The rate limit for this API is 5 requests per 10 seconds.