Compliant in whose tenant? The boundary hidden inside cross-tenant device trust

Separate claim acceptance from local compliance

Entra inbound cross-tenant trust changes whose device assessment you accept, not whose resources you protect. Microsoft documents that the resource tenant evaluates its Conditional Access policies, checks inbound trust, and looks for a device-state claim in the external user’s authentication session. The documented mechanism accepts the partner’s compliant-device claim rather than evaluating that device against your own Intune compliance policies. Your compliant-device requirement therefore remains an access condition, but the accepted evidence comes from another tenant’s assessment.

That distinction matters when interpreting a successful sign-in. It demonstrates that the applicable access checks were satisfied; it does not establish that the partner’s compliance requirements match yours. Microsoft treats compliant-device and Microsoft Entra hybrid joined claims as distinct device information, so neither should be described as interchangeable evidence. The supplied guidance applies to B2B collaboration and B2B direct connect in workforce tenants. It also explicitly excludes Conditional Access Custom Controls from cross-tenant trusts; do not propose them as a supported bridge.

Evidence: Manage cross-tenant access settings for B2B collaboration, Authentication and Conditional Access for External ID

Compare defaults with each partner’s settings

Start the review in External Identities, under Cross-tenant access settings. Examine Default settings before opening each partner under Organizational settings. Microsoft documents that defaults apply where organization-specific customized settings do not exist, and that adding an organization initially leaves its settings inherited from those defaults. Recommended practice is to record whether each partner inherits or customizes inbound settings, then compare accepted MFA, compliant-device, and hybrid joined claims. Treat permission to collaborate and permission to trust claims as separate decisions.

Next, compare the permitted external users, groups, and internal applications with the Conditional Access assignments protecting those applications. The authentication flow checks the partner’s outbound settings as well as your inbound settings, so inbound trust alone does not establish access. Microsoft requires Entra ID P1 or P2 for selecting specific external users, groups, or applications, and does not allow targeting users or groups in inbound defaults. Review business dependencies before changing defaults: Microsoft warns that blocking access can interrupt business-critical collaboration.

Evidence: Manage cross-tenant access settings for B2B collaboration, Authentication and Conditional Access for External ID

Test trusted, untrusted, and missing claims

Then run a controlled comparison. Hypothetical test: an external Entra user accesses an application covered by your compliant-device requirement, first with that partner’s compliant-device claim trusted, then without that trust. Keep the user, application, and applicable policy scope consistent, and record the settings and observed outcome. With trust enabled, Microsoft’s documented flow looks for the device-state claim and allows access when the required checks are satisfied. That outcome must not be reported as evidence of compliance with your Intune baseline.

Include a missing-claim case rather than testing only successful authentication. With device trust configured, Microsoft documents challenges in the user’s home tenant when a required device claim is absent; access is blocked if the checks cannot be satisfied. Without trust, required device compliance that cannot be evaluated blocks both B2B collaboration and B2B direct connect. Keep MFA results separate: without trust, B2B collaboration users can satisfy MFA in the resource tenant, whereas B2B direct connect users are blocked when MFA is required.

Evidence: Authentication and Conditional Access for External ID

Document the requirement behind the trust

Finally, identify the partner compliance requirement that makes its claim acceptable for your resource. This is a governance recommendation, not an automatic Entra comparison. Request the partner’s applicable compliance requirements and compare them with your acceptance criteria, including their scope. Hypothetical example: your requirement is device encryption; ask whether the partner’s baseline requires encryption for the devices accessing your application. Record the requirement, supporting evidence, and unresolved differences. A successful trusted sign-in alone does not demonstrate that the requirements match.

Assign an owner to approve the comparison and revisit it when the partner’s requirements or your access needs change. Retest the trusted, untrusted, and missing-claim paths after relevant configuration changes, retaining enough context to explain the decision. NIST’s federation guidance frames trust agreements around the parties’ rights and expectations, supporting this explicit agreement approach without establishing an Entra compliance certification. The practical conclusion is narrow: trust accepts externally supplied evidence. It does not automatically make the partner’s compliance baseline equivalent to yours.

Evidence: ABSTRACT, Manage cross-tenant access settings for B2B collaboration, Authentication and Conditional Access for External ID