Review Cross-Tenant MFA and Device Trust

A partner’s users should not need a second unmanaged device identity simply to collaborate with your team. Equally, accepting a partner’s security claims deserves more thought than ticking three trust boxes.

This guide covers B2B collaboration between Microsoft Entra workforce tenants. Establish the partner, the resource being shared and the conditions you expect before changing the trust.

Separate access from evidence

Microsoft’s cross-tenant overview describes inbound and outbound access settings alongside inbound trust for MFA, compliant-device and hybrid-joined-device claims. These are related controls with different jobs.

Access settings determine which collaboration is allowed. Trust settings determine whether your Conditional Access evaluation can accept particular evidence from the user’s home tenant. Application permissions still need to give the person access to the resource.

MFA trust does not mean your MFA requirement disappears. It can allow the partner’s completed MFA to satisfy it. Device trust similarly relies on a claim made by the partner tenant.

That leaves a business question to answer: does the partner’s definition of compliance provide the assurance you need for this resource?

Ask for the decisions behind the claim

Use a short discussion with the partner’s identity and device owners. Establish which devices can become compliant, which minimum controls are required, how exceptions are approved and what happens when a device stops meeting policy.

Ask how quickly departing users lose access and how an incident will be reported. Record the people authorised to change the arrangement at both organisations. Avoid making the security contact a person who is already leaving the joint project.

Keep the resulting record proportionate to the data shared. A public project schedule and a restricted engineering workspace may justify different requirements. The record should explain why the chosen claims are sufficient for the actual resource.

A certificate or policy document can inform that judgement, but it does not tell you which configuration the specific test user and device have received.

Configure the named organisation

Microsoft supports organisation-specific cross-tenant settings, which take precedence over defaults. Start with the verified partner tenant ID and confirm whether each setting is inherited or customised.

For a limited project, prefer explicit user, group and application scope where supported and licensed. Obtain the relevant object identifiers from the partner rather than guessing from display names.

Keep the current configuration with the change record. Be particularly careful with defaults: modifying them affects organisations without their own custom configuration.

Also record the intended end state when the partnership finishes. Removing the partner’s custom entry returns it to the default settings. If the intended result is to block access, deletion alone may not express that decision.

Test a useful set of sign-ins

The B2B authentication flow considers the home tenant’s outbound settings, the resource tenant’s inbound settings and Conditional Access. An unsuccessful test can therefore involve more than your trust checkbox.

Agree test cases with the partner:

Use harmless test resources or authorised accounts. Capture the tenant, resource, user, device state, relevant sign-in result and time. Ask the partner to retain matching evidence from its side.

A successful sign-in is insufficient if a required claim was never evaluated because the user was excluded from the policy. Check the applied policy result as well as the user experience.

Keep failure handling specific

If MFA fails, investigate the accepted method and trust configuration. If the device requirement fails, investigate the device claim and applicable policy. Do not solve either problem by excluding all guests from Conditional Access.

A temporary exception should name the user, resource, compensating arrangement and expiry. Someone should know how to remove it without disrupting the rest of the partnership.

Review the trust when the partner changes identity systems, compliance standards or project membership. Combine that review with the existing guest-access review process, while keeping the two questions visible: who should still have access, and what evidence you accept when they use it.

References

• Microsoft — Cross-tenant access overview. Accessed 17 October 2026.
• Microsoft — Configure cross-tenant access for B2B collaboration. Accessed 17 October 2026.
• Microsoft — Authentication and Conditional Access for B2B users. Accessed 17 October 2026.