Guests and external identities

Three grant controls that simply do not work for guests, and what to use instead.
Published by Urbannerd Consulting · Reviewed 2026-07-29

Conditional Access for guests and external identities

Source: Authentication and Conditional Access for B2B users

· doc date 2026-03-27 · retrieved 2026-07-29

benchmark guidance says almost nothing here beyond "exclude guests or onboard them with a compliant device".

This is where most real Conditional Access work goes wrong, because **several grant controls

simply do not function for external users** — and they fail silently as blocks, not as errors.

The six external user types

Conditional Access can target these separately. The distinction matters because they behave

differently.

Portal change worth knowing: "All guest and external users" has been replaced by

"Guest and external users" plus selectable sub-types. Existing policies now show the parent

plus all sub-types selected. No functional change to evaluation — but a policy the customer

believes covers "all guests" now displays differently, and the granularity is newly available.

Service provider users are their own type. For MSP-managed tenants, delegated partner

access can be targeted separately from ordinary guests. Rarely done, and worth raising.

What actually works for external users

The support matrix. This is the highest-value table in the file — three commonly-recommended

grant controls do not work for guests at all.

Why approved-client-app and app-protection fail: both require the device to be registered

in the resource tenant, and a device can only be managed by its home tenant. Microsoft's

guidance is explicit — do not require an app protection policy for external users. These

controls also only apply to iOS and Android.

B2B direct connect gets no session controls whatsoever. Any design applying sign-in

frequency or persistent-browser rules to shared-channel users is not doing what its author

thinks.

Custom controls are not supported for cross-tenant trusts.

Cross-tenant access settings — the mechanism that unblocks guests

Inbound trust lets the resource tenant accept MFA claims and device claims (compliant,

hybrid joined) satisfied in the guest's home tenant. Configurable for all Entra organisations

or per organisation.

The authentication flow, condensed:

1. Guest from the home tenant initiates sign-in to a resource tenant.
2. Entra evaluates the resource tenant's CA policies and cross-tenant settings (home

tenant's outbound, resource tenant's inbound).

1. Entra checks whether the resource tenant trusts MFA and device claims from the home tenant.
2. If trusted, it looks for claims in the session showing MFA was completed and the device state.
3. If required but absent, challenges are issued in the home tenant.
4. If no trust is configured — B2B collaboration users are challenged for MFA *in the

resource tenant*; B2B direct connect users are blocked outright. If device compliance is

required and cannot be evaluated, both are blocked.

The agent's rule: whenever a design requires MFA or device compliance and guests are in

scope, ask whether inbound trust is configured. Without it, B2B direct connect breaks

completely and device policies block every guest. This is the correct answer to "guests can't

satisfy our device policy" — better than blanket exclusion, which leaves them uncovered.

Authentication strength for guests — a genuine trap

Authentication strength works on external users, **but only those authenticating with Microsoft

Entra ID. For email one-time passcode, SAML/WS-Fed federation, and Google federation users,

authentication strength does not apply — use the plain MFA grant control instead.**

Worse, the acceptable methods differ by where MFA is performed:

Read the right-hand column. Every phishing-resistant method is unavailable in the resource

tenant. So:

You cannot enforce phishing-resistant MFA on a guest who completes MFA in your tenant.

It is only achievable by enabling MFA trust and having the guest satisfy phishing-resistant

MFA in their home tenant — which requires that their organisation has enabled the method and

that the user can register for it.

An organisation that applies its phishing-resistant admin policy to guests has built something

guests cannot satisfy. The agent must catch this. If MFA trust is off and phishing-resistant

strength is required, guests are blocked with no route forward.

Also: if the user cannot complete MFA, **or a Conditional Access policy such as a compliant-

device requirement prevents them from registering**, access is blocked. The registration

deadlock applies to guests too.

Risk-based policies and guests — do not apply them

The sharpest guidance on the page, and it contradicts the instinct to protect everything.

Sign-in risk is evaluated in the resource tenant and is enforced. But if the guest has not

previously registered for MFA in the resource tenant, they are blocked — deliberately, to

stop an attacker registering their own MFA credentials after compromising a password.

User risk cannot be resolved at all:

• User risk is evaluated in the guest's home directory.
• A user-risk policy forcing password reset blocks the guest — they cannot reset a password

in your directory.

• Your risky users report does not show external users, because evaluation happens in their

home directory.

• Your admins cannot dismiss or remediate a risky external user, having no access to the

home directory.

Microsoft's recommendation, which the agent should reproduce:

Create a group containing all external users and **exclude it from user-risk and sign-in-risk

Conditional Access policies.**

This is one of the few places where a broad, permanent exclusion is the correct design rather

than a smell — and the agent should say so plainly rather than flagging it as a finding.

What behaves normally

• Client app conditions — identical for guests. Blocking legacy authentication works.
• Session controls — identical for B2B collaboration guests (but see the matrix for direct

connect, which supports none).

• Location conditions — IP-range policies work if you can define the partner's trusted

ranges; country-based works too.

• Device filters — usable with cross-tenant trust. Pattern: trust device claims from the

organisation → map the attribute to a supported device extension attribute → write a filter.

Non-Entra external users

For guests from Google, Facebook, SAML/WS-Fed IdPs, or email one-time passcode, **the resource

tenant is always responsible for MFA**. There is no trust relationship to lean on. The guest

registers Entra MFA with your tenant, and consumes a licence from your tenant — you need

sufficient premium licences to cover them.

MFA is deliberately completed at the resource tenant for predictability. The guest sees your

sign-in page in the background and their own home branding in the foreground.

Proof-up reset for a B2B collaboration user who needs to re-register:

Connect-Entra -Scopes 'UserAuthenticationMethod.ReadWrite.All'
Reset-EntraStrongAuthenticationMethodByUpn -UserPrincipalName jmorgan_fabrikam.com#EXT#@woodgrovebank.onmicrosoft.com

Note the #EXT# UPN form — useful for recognising guest accounts in pasted configuration.

Checklist the agent should run when guests are in scope

1. Which external user types are actually present? Guests, direct connect, service providers?
2. Is inbound trust configured for MFA? For device claims? Per-organisation or global?
3. Does any policy apply approved client app, app protection or password change to

external users? All three are non-functional — remove or re-scope.

1. Does any policy require phishing-resistant strength where guests are in scope, without

MFA trust? Guests cannot satisfy it.

1. Are guests excluded from user-risk and sign-in-risk policies? If not, recommend it.
2. Do guests hit a device compliance requirement with no trust configured? They will be

blocked.

1. Are B2B direct connect users subject to session controls that do not apply to them?
2. Are there enough premium licences in the resource tenant to cover non-Entra guests

registering MFA?

1. Is the Rights Management Services exclusion (00000012-0000-0000-c000-000000000000)

needed for externals opening sensitivity-labelled documents?