A guest replaces their phone. They update Microsoft Authenticator at their employer, then open a partner application and receive a challenge for the old device. The obvious question is whether the update failed. The more useful question is: which tenant is asking for MFA?
Updated 14 November 2026. This is an updated version of my original article. Since then, the registration experience, cross-tenant MFA trust and authentication options have changed. Here is how to manage B2B guest MFA in Microsoft Entra workforce tenants today.
Separate the account from the resource
The home tenant owns the external Microsoft Entra identity. The resource tenant hosts the application and its guest representation. Resource-tenant Conditional Access and inbound cross-tenant settings are evaluated alongside the home tenant's outbound settings.
If the resource tenant accepts the home tenant's MFA claim, a qualifying authentication there can satisfy its requirement. Without MFA trust, a B2B collaboration guest must satisfy resource-tenant MFA when required. That can mean a separate registration. Trust accepts evidence of authentication; it does not copy a phone or Authenticator registration. Microsoft explains the authentication flow.
Make partner trust an explicit decision
In the Entra admin center, open Entra ID → External Identities → Cross-tenant access settings → Organizational settings. Review the specific partner's inbound configuration and the users, groups and applications it permits. Under inbound trust, decide whether to accept MFA claims. Review device claims separately.
My recommendation is to document the partner, purpose, scope and owner before changing trust. A registration problem alone is not a reason to extend trust to every organization. Restrictive application allowlists also need the account-management applications: Microsoft lists My Sign-ins, My Profile and Microsoft App Access Panel, including dependencies for Security Info. Check both inbound and outbound restrictions when that page fails. See the cross-tenant settings and application IDs.
Require the right method, not merely another prompt
A sensitive application can require a phishing-resistant authentication strength. The important B2B limitation is where the guest authenticates. Microsoft's current external-user matrix lists FIDO2 security keys, Windows Hello for Business and certificate-based authentication configured as multifactor for home-tenant fulfillment, but not resource-tenant fulfillment. Resource-tenant options include Authenticator push and software OATH; they do not become phishing-resistant because the policy is stricter.
For external Entra users, combine an agreed home-tenant method with suitable inbound MFA trust and the required strength. If the partner cannot meet it, access should fail until an approved design exists. Check the current external-user methods matrix.
Authentication strengths currently apply to external users authenticating with Microsoft Entra ID. Microsoft directs email OTP, SAML/WS-Fed, Google federation and personal Microsoft account scenarios to the MFA grant control instead. Keep those populations explicit rather than assuming one guest policy covers identical capabilities. See the external-user policy guidance.
Change a phone while a working method remains
First establish the tenant that owns the registration you need to change. Microsoft documents a tenant-specific Security Info entry point:
https://mysignins.microsoft.com/security-info/?tenantId=<Tenant ID>Replace the placeholder with the verified tenant GUID. Use a modern browser, check the signed-in account and organization, and complete the required verification. A home-tenant update does not update a separate resource-tenant registration. Microsoft documents directory switching and this URL.
For an allowed Authenticator registration, select Add sign-in method → Microsoft Authenticator and follow the QR-code setup and verification prompts. Microsoft's Authenticator setup guide describes the current enrollment sequence.
For a planned replacement, my sequence is: add the new method, verify it, then perform a fresh sign-in to the actual partner application using it. Keep the working old method until the new route succeeds; then remove the retired registration. Repeat only for tenants with their own registration. Never share enrollment QR codes with a support caller.
Check policy when a method is missing
The Authentication methods policy controls which methods users and groups can register and use. Authentication strengths impose a further restriction for the protected scenario. Enabling a method tenant-wide does not guarantee it satisfies the target application's strength.
Use the modern policy rather than reproducing legacy MFA/SSPR settings. Microsoft states that management through those legacy policies ended on 30 September 2025. See authentication method policy management.
Treat lost access as recovery, not a phone change
If no working method remains, use the established help-desk recovery process. My recommendation is to verify the requester through an independent approved channel, record the affected account and tenant, and identify whether the home or resource organization owns the broken registration before any reset.
In the responsible tenant, an authorized administrator can open Entra ID → Users → the user → Authentication methods. Use the narrow role supported for that target account. Be deliberate with Require re-register MFA: Microsoft says it deletes phone numbers, Authenticator apps and software OATH methods and deactivates hardware OATH tokens. It is not a targeted replacement of one phone, and should not be described as removing every possible credential. See the action's documented effects.
Where available and licensed, use PIM to activate the administrative role only for the recovery window, with the required justification or approval. PIM supports time-bound activation and audit history.
Understand the limits of TAP and session revocation
A resource-tenant administrator cannot issue a Temporary Access Pass to an external B2B guest. Microsoft distinguishes these from internal guest accounts. A TAP from the home tenant can be used under the documented home-tenant and cross-tenant trust requirements; use it to bootstrap an accepted method. A TAP is not phishing-resistant and cannot itself satisfy the Passwordless MFA or Phishing-resistant MFA strength. Check the external-user method matrix as well as cross-tenant trust. Check TAP guest restrictions.
Credential recovery and session containment are separate tasks. Microsoft Graph v1.0 explicitly states that revokeSignInSessions does not revoke external-user sessions because those users authenticate through their home tenant. Coordinate with that organization and the resource application when containment is needed. Do not report a successful guest-object API call as proof that every session has ended. See the revocation API limitation.
Verify the decision in logs and a real sign-in
For a failed or surprising sign-in, capture the timestamp, user, application, request ID and correlation ID. Inspect Authentication Details and Conditional Access, together with home tenant ID, resource tenant ID and cross-tenant access type. A fresh MFA prompt alone does not tell you which registration was used.
Allow for log aggregation: Microsoft notes that early Authentication Details can be incomplete or inaccurate. The sign-in activity reference explains these fields and limits.
For policy changes, first assess report-only results while existing protection stays enforced. Report-only does not make users complete a new MFA challenge, so it cannot prove successful enrollment or recovery. Follow with a scoped enforced pilot and actual partner-app sign-ins. Microsoft documents what report-only evaluates.
Keep a small recovery record
For each partner, record the resource application, guest population, chosen strength, accepted home-tenant evidence, registration owner and support contact. Test planned phone replacement and complete loss of the registered device as separate cases.
A useful guest MFA design tells the user where to register, gives support a safe recovery route, and gives the resource owner evidence that the required authentication actually happened.