Official documentation checked October 14, 2026.
AADSTS90072 is an identity and MFA-context error, not proof that Copilot needs a blanket cross-tenant trust change. Microsoft’s current definition says the external account is missing from the tenant being accessed, preventing satisfaction of that tenant’s MFA requirements; a synchronization source-anchor mismatch is another documented possibility.
Start by checking the account and target tenant. Do not enable access for all external applications, weaken MFA, or buy a guest license on the assumption that it resolves this error.
Confirm the account, tenant, and exact error
- Record the full error message, timestamp, request or correlation identifier, application, and tenant shown. Keep identifiers in an authorized support ticket, not a public forum.
- Confirm which organization account should be used for this particular Copilot service. A guest relationship in another tenant is not the same as using the licensed account in your home tenant.
- Sign out of the affected web session and try a fresh browser profile or private window, deliberately selecting the intended work account.
- Use the organization’s approved Copilot entry point. Compare the tenant in the new error with the intended organization.
The Microsoft Entra error reference identifies AADSTS90072 as PassThroughUserMfaError. If a different error appears after selecting the right account, investigate that new error rather than continuing to change cross-tenant settings.
Have the administrator verify the identity record
An authorized administrator should locate the corresponding sign-in event, identify the home and resource tenants, and check whether the expected user object exists. For an intended external collaboration scenario, verify the approved invitation and redemption state before creating a duplicate identity.
For synchronized users, the error reference also identifies an ImmutableID or source-anchor mismatch. Escalate that evidence to the identity synchronization owner. Do not change these attributes or delete and recreate the account as a casual Copilot troubleshooting step; doing so can affect access to other services.
Only investigate cross-tenant policy as the cause when the sign-in evidence supports it. Microsoft’s cross-tenant overview distinguishes B2B collaboration, B2B direct connect, and inbound trust of MFA or device claims. B2B collaboration is not universally blocked by default, and trust settings are not simple inbound and outbound True/False values.
If a policy adjustment is genuinely required, its owner should scope it to the approved partner, users, and applications, assess the security effect, and verify it through a controlled test. A generic allow-all recipe is not appropriate.
Verify Copilot eligibility separately from sign-in
Successful authentication does not establish that the account can use the requested Copilot feature in that tenant. Check the current Copilot requirements and the supported external-user scenario with the service owner. Guest access to a SharePoint site does not automatically confer organizational Copilot rights.
Keep product distinctions explicit: external access documented for Security Copilot or a separately published agent does not establish support for every Microsoft 365 Copilot workload.
After resolving the evidenced identity issue, repeat the original sign-in with the intended account and inspect the new event. Record whether authentication succeeded and whether the requested Copilot feature then worked. If not, provide support with the sanitized before/after errors, tenant context, and feature name. Do not remove Conditional Access protections simply to turn an authentication failure into a successful sign-in.