Cross-Tenant Access Policies in Entra ID

Cross-tenant access policies in Microsoft Entra ID (formerly Azure Active Directory) allow organizations to manage how users from external Microsoft Entra tenants access their resources and how their own users access resources in external tenants. These policies are essential for B2B collaboration, enabling seamless yet controlled access across organizational boundaries.

Before cross-tenant access policies, organizations had limited control over B2B collaboration. External users were either invited as guests with default settings or blocked entirely. There was no granular way to restrict which external tenants could access what, or to enforce trust for multi-factor authentication (MFA) and device compliance. Cross-tenant access policies solve this by providing a centralized, policy-driven approach to manage inbound and outbound access.

Cross-tenant access policies operate at the tenant level and are enforced during authentication and authorization flows. When a user from Tenant B attempts to access a resource in Tenant A, the following steps occur:

For outbound access (users in Tenant A accessing resources in Tenant B), Tenant A can configure outbound policies to control which external tenants their users can access and what trust they will accept from those tenants.

Cross-tenant access policies can be configured via the Microsoft Entra admin center or Microsoft Graph PowerShell. Key PowerShell commands:

# Get the default cross-tenant access policy
Get-MgPolicyCrossTenantAccessPolicyDefault

# Update default inbound trust settings
Update-MgPolicyCrossTenantAccessPolicyDefault -InboundTrust @{ IsMfaAccepted = $true; IsCompliantDeviceAccepted = $true; IsHybridAzureADJoinedDeviceAccepted = $false }

# Create a new partner-specific inbound policy
$params = @{
    DisplayName = "Contoso Inbound Policy"
    TenantId = "contoso.onmicrosoft.com"
    InboundTrust = @{
        IsMfaAccepted = $true
    }
    B2BCollaborationInbound = @{
        Applications = @{
            IncludeApplications = @("All") 
        },
        UsersAndGroups = @{
            IncludeUsers = @("All")
            IncludeGroups = @()
        }
    }
}
New-MgPolicyCrossTenantAccessPolicyPartner -BodyParameter $params

# Verify policy
Get-MgPolicyCrossTenantAccessPolicyPartner -Filter "tenantId eq 'contoso.onmicrosoft.com'" | Format-List

When two companies merge, they often need to provide cross-tenant access during the integration period. For example, Contoso acquires Fabrikam. Both have separate Microsoft 365 tenants. Cross-tenant access policies allow Contoso users to access Fabrikam's SharePoint sites and Teams channels without migrating data immediately. The IT team configures inbound trust for Fabrikam's tenant, trusting MFA and device compliance. They also create outbound policies to allow Fabrikam users to access Contoso's resources. During the transition, they use B2B collaboration to add Fabrikam employees as guests to specific teams. The policies are set to allow only the necessary applications (e.g., SharePoint, Teams) and block access to sensitive apps like Dynamics 365. Common issues: if trust settings are not configured correctly, users may be prompted for MFA repeatedly, causing frustration. Also, if the default policy is set to block, all access fails until partner-specific policies are created. Performance is generally not an issue because policies are evaluated at authentication time, which adds minimal latency.

A healthcare organization, HealthCo, partners with a research lab, LabCorp. HealthCo must comply with HIPAA and requires that all external users complete MFA and use compliant devices. HealthCo configures a cross-tenant access policy for LabCorp with inbound trust for MFA and compliant device. They also set outbound policies to restrict HealthCo users from accessing LabCorp resources except for a specific research SharePoint site. LabCorp configures its own inbound policies to trust HealthCo's MFA claims. This setup ensures that only authorized, authenticated, and compliant users can access sensitive health data. A common pitfall is that if LabCorp does not enforce MFA for its own users, the trust setting is meaningless. HealthCo's Conditional Access policies should also require MFA for guest users as a backup. The policies are tested with a pilot group before rolling out to all users.

A large enterprise, MegaCorp, works with hundreds of external contractors, each from different tenants. MegaCorp uses cross-tenant access policies to manage access for these contractors. They set a default inbound policy that blocks all external tenants, then create specific policies for each contractor tenant with limited access to only the applications they need (e.g., a contractor portal). They do not trust MFA or device compliance from any contractor tenant because they cannot enforce those policies. Instead, MegaCorp requires contractors to use their own MFA and then uses Conditional Access to require MFA for all guest users. This layered approach ensures security. The challenge is managing hundreds of policies. MegaCorp uses PowerShell scripts to automate policy creation based on a spreadsheet of contractor tenants. They also monitor sign-in logs for anomalous access attempts. Misconfiguration often occurs when a new contractor tenant is added but the policy is not created, causing access denials.