Entra cross-tenant access: B2B collaboration, inbound trust, delegation

TL;DR — Entra cross-tenant access settings are the policy layer that decides whether users from another Entra tenant can collaborate with your apps and whether you will trust that tenant’s MFA, compliant device, or hybrid-join claims instead of re-checking them yourself. The most important decision is not "allow B2B"; it is "which assurance signals am I delegating to the partner tenant, for which users/apps, and what happens when their identity hygiene is weaker than mine?" Reading time: ~7 min

What it is and where it sits

Entra cross-tenant access settings sit between external identity federation and your app authorization layer. In practice, they govern B2B collaboration between Entra tenants: who can come in, which of your users can go out, and whether inbound/outbound trust should honor claims from the other tenant for MFA, device compliance, and Microsoft Entra hybrid joined state.

This is not your app’s RBAC. It is not classic AD FS federation config. It is tenant-to-tenant policy that influences sign-in evaluation before your app sees a token.

What it replaces or reduces:

• Per-app ad hoc guest rules
• Repeated MFA prompts for partner users when both sides already enforce MFA
• Older federation assumptions where every org solved trust differently

Where it lives in the request flow:

• User starts sign-in to your app
• Your app redirects to Entra
• Entra identifies the user as external/home-tenant managed
• Cross-tenant access policy is evaluated
• If allowed, Entra decides whether to trust partner claims like MFA/compliant device
• Conditional Access is evaluated using those trusted or untrusted signals
• Token is issued to your app, usually for a guest/B2B object in your tenant context

User (partner tenant) -> Your app -> Your Entra tenant
                               |
                               v
                 Cross-tenant access settings
                 - inbound allow/block
                 - trust MFA/device/hybrid join?
                               |
                               v
                    Conditional Access evaluation
                               |
                               v
                        Token to your app

The architecture point that matters: inbound trust changes the inputs to your Conditional Access decisions. You are not just allowing login; you are allowing another tenant’s authentication and device-management posture to satisfy your controls.

How it actually works

Walk one realistic example: a contractor from Fabrikam needs access to your internal issue tracker app in your Contoso tenant. Your app requires sign-in through Entra and a Conditional Access policy that says: require MFA for all users, and require a compliant device for the admin area.

Step 1: The user is external, but the resource is yours

The contractor alex@fabrikam.com hits https://tracker.contoso.example. Your app redirects to your Entra tenant’s authorize endpoint. Entra sees the user’s home realm is Fabrikam.

Step 2: Cross-tenant inbound policy is checked

Your tenant has a partner-specific cross-tenant inbound policy for Fabrikam:

• B2B collaboration: allowed
• Inbound users/groups: only Fabrikam-Contractors group
• Applications: only tracker-prod enterprise app
• Trust settings: trust Fabrikam MFA = true, trust compliant device = false, trust hybrid joined = false

If Alex is not in the allowed Fabrikam group, sign-in fails before app access. In logs, the shape is typically "blocked by cross-tenant access policy" rather than "app authorization failed." That distinction matters: your app never got a usable token.

Step 3: Home tenant authenticates the user

Fabrikam performs primary auth and MFA in its own tenant. It returns claims/assertions that your tenant can evaluate. If you have enabled inbound trust for MFA, your tenant can accept Fabrikam’s MFA claim as satisfying your CA policy requiring MFA.

What you delegated here: the correctness of Fabrikam’s MFA policy, registration quality, and sign-in risk handling. If they count SMS as MFA and you consider that too weak, trusting their MFA means your stronger preference is bypassed for those users.

Step 4: Your tenant evaluates Conditional Access with trusted signals

Your CA policy says MFA is required. Because inbound trust for MFA is enabled, Alex is not prompted again by your tenant.

Your CA policy for the admin area says compliant device is required. Because inbound trust for compliant device is disabled, Fabrikam’s device compliance claim is ignored. If Alex opens the admin route, your tenant cannot satisfy that requirement from Fabrikam’s claim, so access is denied unless you have another path.

This is the key mechanism: inbound trust is per-signal. You can trust MFA but not device compliance.

Step 5: Token issuance and app behavior

If Alex is accessing the normal tracker UI, your tenant issues a token and your app sees a user in your tenant context, usually as a B2B guest/collaboration identity. Your app still does its own authorization:

• token valid? issuer/audience/tid checks
• user mapped to app role/group?
• route-level authorization

Cross-tenant access settings do not grant app permissions. They only decide whether the external identity can get through tenant-level gates and which external assurances count.

A realistic failure mode looks like this in sign-in troubleshooting: the user says, "I did MFA at my company, but your app still says blocked." The cause is often one of:

• inbound trust for MFA is off
• app/user scope in cross-tenant policy excludes this app or user
• your CA policy requires compliant device, but you do not trust partner device compliance
• the partner claim is missing or not in a form your tenant accepts

When to use it (and when not to)

Use cross-tenant access settings when you have repeated, organization-to-organization collaboration and want explicit control over who can cross the boundary and which assurance claims are portable.

You probably don’t need this if your only goal is "invite a few guests and assign them to one app." Default B2B collaboration and app assignment often solve that without partner-specific trust decisions.

Trade-offs

Every benefit here costs something operationally.

• Fewer MFA prompts for partner users
  • Cost: you are delegating MFA strength and enrollment quality to the partner tenant.
• Cleaner partner experience across many apps
  • Cost: policy sprawl. Per-partner, per-app, per-user/group exceptions become hard to reason about.
• Ability to trust partner device/compliance signals
  • Cost: you inherit blind spots from their MDM/compliance definitions. "Compliant" may not mean what your security team thinks it means.
• Centralized tenant-level control
  • Cost: debugging gets harder because failures can happen before app auth, inside cross-tenant policy or CA evaluation.
• Reduced duplicate controls
  • Cost: lock-in to Entra-to-Entra semantics. If one side changes IdP architecture, your trust assumptions may break.

Latency/cost notes:

• User-perceived latency usually changes little; the bigger cost is troubleshooting time, not request milliseconds.
• Licensing and feature availability vary by tenant capabilities and policy types. Treat partner trust design as a security architecture decision first, not a convenience toggle.

In practice

Example 1: Read partner cross-tenant configuration via Microsoft Graph

Use Graph to inspect what is actually configured instead of trusting screenshots from a portal.

az login
az account get-access-token --resource-type ms-graph --query accessToken -o tsv > /tmp/graph.token
TOKEN=$(cat /tmp/graph.token)

curl -sS -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners" | jq '.value[] | {tenantId, inboundTrust: .inboundTrust, b2bCollaborationInbound: .b2bCollaborationInbound}'

What it does: fetches partner-specific cross-tenant policy objects and prints the parts you care about first during triage. Gotcha: Graph permissions matter; if your token lacks policy read scope, you will get a 403 that looks like this:

{
  "error": {
    "code": "Authorization_RequestDenied",
    "message": "Insufficient privileges to complete the operation.",
    "innerError": {
      "date": "2026-08-05T11:42:19Z",
      "request-id": "...",
      "client-request-id": "..."
    }
  }
}

Example 2: Patch inbound trust for a specific partner tenant

⚠️ Changing inbound trust can immediately alter sign-in behavior for external users. Do this first in a test tenant or against a narrowly scoped partner/app policy, and record the previous JSON before patching.

PARTNER_TENANT_ID="11111111-2222-3333-4444-555555555555"
TOKEN=$(az account get-access-token --resource-type ms-graph --query accessToken -o tsv)

curl -sS -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners/$PARTNER_TENANT_ID" \
  -d '{
    "inboundTrust": {
      "isMfaAccepted": true,
      "isCompliantDeviceAccepted": false,
      "isHybridAzureADJoinedDeviceAccepted": false
    }
  }' -D /tmp/headers.out

cat /tmp/headers.out

Typical success header shape:

HTTP/2 204 No Content
request-id: ...
client-request-id: ...

What it does: trusts only partner MFA, not device or hybrid-join claims. Gotcha: a 204 No Content means the patch was accepted, not that your CA outcomes are now what you intended; immediately test a real sign-in and inspect sign-in logs.

Example 3: App-side token checks so you do not confuse tenant policy with app auth

Your app should still reject tokens from the wrong tenant or audience. Example in Node using jose:

import { createRemoteJWKSet, jwtVerify } from 'jose';

const tenantId = process.env.ENTRA_TENANT_ID;
const issuer = `https://login.microsoftonline.com/${tenantId}/v2.0`;
const audience = process.env.API_APP_ID_URI;
const jwks = createRemoteJWKSet(new URL(`https://login.microsoftonline.com/${tenantId}/discovery/v2.0/keys`));

export async function verifyAccessToken(token) {
  const { payload } = await jwtVerify(token, jwks, {
    issuer,
    audience,
  });
  return {
    sub: payload.sub,
    tid: payload.tid,
    oid: payload.oid,
    roles: payload.roles || [],
  };
}

What it does: validates issuer and audience against your tenant, independent of cross-tenant settings. Gotcha: if you support multiple issuers/tenants intentionally, do not loosen this to "accept anything signed by Microsoft"; explicitly enumerate allowed issuers.

Further reading

• Microsoft Graph "crossTenantAccessPolicy" resource type
• Microsoft Entra documentation section "Configure cross-tenant access settings for B2B collaboration"
• Microsoft Entra documentation section "Inbound trust settings"
• Microsoft Entra Conditional Access documentation
• OpenID Connect Core 1.0

This article was written by an AI system and published pending human review. Verify anything you intend to act on.