Jed Laundry

A key piece of Microsoft's push towards Phishing-Resistant Authentication is the Authentication strength Conditional Access control. Building on the Authentication Methods policies, which specify which types a user can enrol, Authentication Strength enforces the use of specific authenticator types at a resource level.

Microsoft's recommendations for implementing Essential Eight ML2 include enforcing Authentication Strengths on B2B Guests [source].

No more Resource tenant MFA

As per the documentation, "Microsoft Entra ID doesn't support guests registering for phishing resistant multifactor authentication options in the resource tenant." [source]

This is different to how Microsoft Authenticator and push MFA used to work; with push MFA, users could register Microsoft Authenticator in the Resource tenant, so it didn't matter what they did (or didn't) use in their Home tenant. According to Microsoft, this is not supported for phishing-resistant options. [source]

This means that the Home tenant administrator will need to configure a phishing-resistant authentication option--either FIDO2 security keys, Windows Hello for Business, Certificate-based Authentication, or Device-bound Passkeys in Microsoft Authenticator--in their tenancy's Authentication Methods Policy. If you don't, when users try to access Resource tenants, they will get the error You can't get there from here "An authentication policy cannot be fulfilled. Please contact your administrator."

What if the User's Home tenant uses Federated authentication (such as Okta / ADFS), or an External Authentications Method (such as Cisco Duo, RSA, or Falcon Identity Protection)

In the WS-Federation scenario, the WS-Fed assertion only emits the MultipleAuthN boolean value indicating if MFA was present, it doesn't provide multifactor types used. Therefore, Entra can't use the Authentication Strength control to enforce phishing-resistant authentication.

Similarly, in the EAM scenario, Microsoft does not currently support the amr or acr signals provided by the External Authentication Method provider, and so you will not be able to use a Conditional Access Policy to enforce phishing-resistant authentication.

In other words, Microsoft don't have a way to enforce Phishing-Resistant Authentication for B2B Guests, unless the B2B Guest Home tenancy is also using Entra for authentication and MFA.

The "Solution"

Instead, to make these scenarios work:

• You will need to have a written agreement between the Home and Resource tenant organisations, so that the Resource tenant can trust incoming users.
• The Home tenant administrator will need to configure a policy on their authentication/MFA platform, to enforce their users use phishing-resistant authentication when accessing Microsoft 365 resources.
• The Resource tenant administrator will need to exclude these B2B users from all Conditional Access Policies that enforce Require Authentication Strength. And, if the Default Inbound Access settings don't include "Trust multifactor authentication from Microsoft Entra tenants", this should be enabled.