Passkeys for B2B Guests Landed—Three Reasons You Still Can’t Turn Off Passwords

The pitch writes itself: passkeys work for guests now, so you can finally kill passwords and legacy MFA for everyone, employees and partners alike. That is the wrong lesson, and it will bite the admins who act on it fastest.

Here is the version I actually agree with first, because it’s true. Entra News #167 reports passkey (FIDO2) support extending to B2B users, and that closes a gap that has annoyed anyone running a serious passwordless program. Until now you could hold your own staff to a phishing-resistant bar and then watch a guest wander in on a password plus SMS, straight through the same Conditional Access estate. Being able to bring external identities into the same authentication-strength story is a genuine improvement. Authentication strength policies that demand phishing-resistant credentials stop being a policy you can only aim at your own people. That part is good, and if you’ve been waiting for it, stop waiting and go test it.

Now the part the announcement doesn’t dwell on. Turning on a capability is not the same as owning the outcome, and for B2B collaboration the outcome lives on the far side of a boundary you don’t administer.

The constraint that actually decides this

B2B collaboration guests authenticate against their home tenant, not yours. That single fact governs everything downstream. When a partner from contoso.com opens a resource in your tenant, they sign in at Contoso, and your tenant consumes the result. So there are two models, and they behave completely differently:

• You trust the home tenant’s MFA via cross-tenant access settings. In that case the passkey — if there is one — is registered and enforced at Contoso. You get an MFA claim. You do not get to dictate that the claim came from a passkey unless your Conditional Access authentication strength says so and the home tenant can actually satisfy it.
• You don’t trust their MFA, so the guest proofs up in your tenant. Now the passkey lives in your directory, on your authentication methods policy — and you’ve just taken on credential lifecycle for someone who doesn’t work for you.

Neither of those is “turn off passwords for everyone.” The first outsources the decision to a tenant whose security posture you can request but not enforce. The second makes you the help desk for a stranger’s authenticator.

Three things this doesn’t fix

One: you can’t force a partner to deploy passkeys. If you require phishing-resistant authentication strength for external users and the home tenant hasn’t rolled out FIDO2, those users don’t get a weaker path — they get no path. They’re blocked. That may be exactly what you want at a bank. It is a support catastrophe if you flip it on across a supply chain of small partners who are still on Authenticator push. Authentication strength for guests is a business negotiation wearing a policy toggle.

Two: what you can see is not what they use. When you audit a guest’s authentication methods in your tenant, you’re seeing what they registered here. If MFA trust is on and they authenticate at home, your baseline report will look empty or sparse and tell you almost nothing about whether that person is protected. Don’t read a clean audit as a clean posture.

Three: the redemption UX still isn’t yours to design. A new guest redeeming an invite registers credentials in whichever tenant is doing the authenticating. You can nudge, you can document, but the enrolment flow, the fallback methods, and the “I lost my key” recovery path largely sit with the home tenant. The boundary didn’t move. It just got a nicer credential on the other side of it.

Where to actually look in the admin center

Two blades matter, and people conflate them. Passkey (FIDO2) itself is enabled under Protection → Authentication methods → Policies. That policy governs registration and use for identities that authenticate in your tenant — your staff, and guests you proof up locally. The cross-tenant behaviour lives under External Identities → Cross-tenant access settings, where inbound trust settings decide whether you accept the home tenant’s MFA claim at all. The Conditional Access piece — authentication strength scoped to guest and external users — sits under Protection → Conditional Access. Check whether the feature shows as preview or GA in your own tenant before you build a rollout plan on it; I’m not going to quote a status or a date the source doesn’t nail down.

On licensing, keep two things separate. The passkey method is a free-tier authentication method — you don’t buy Premium to register a FIDO2 key. Conditional Access and authentication strength require Entra ID P1, and that’s the licence that does the real work for guests. B2B external identities bill under the MAU model (with a monthly free allowance), so premium features consumed by guests are charged against active guests rather than per-seat. Confirm the current free MAU threshold on your billing blade rather than trusting a number you half-remember.

Get your baseline before you touch policy

Before any of this, know what your guests are actually holding today. This read-only audit enumerates guest accounts and the methods registered in your tenant. Read the caveat under it — it changes how you interpret the output.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

#Requires -Modules Microsoft.Graph.Authentication, Microsoft.Graph.Users
​
# Read-only: no state is changed. Least-privilege scopes only.
Connect-MgGraph -Scopes 'User.Read.All','UserAuthenticationMethod.Read.All' -NoWelcome
​
try {
    $guests = Get-MgUser -Filter "userType eq 'Guest'" -All `
        -Property Id, DisplayName, UserPrincipalName -ErrorAction Stop
}
catch {
    Write-Error "Failed to enumerate guests: $($_.Exception.Message)"
    return
}
​
$report = foreach ($g in $guests) {
    try {
        $methods = Get-MgUserAuthenticationMethod -UserId $g.Id -All -ErrorAction Stop
    }
    catch {
        Write-Warning "Could not read methods for $($g.UserPrincipalName): $($_.Exception.Message)"
        continue
    }
​
    $types = $methods.AdditionalProperties.'@odata.type' |
        ForEach-Object { $_ -replace '#microsoft.graph.', '' }
​
    [pscustomobject]@{
        DisplayName       = $g.DisplayName
        UserPrincipalName = $g.UserPrincipalName
        HasPasskey        = [bool]($types -match 'fido2AuthenticationMethod')
        MethodCount       = $methods.Count
        Methods           = ($types | Sort-Object -Unique) -join ', '
    }
}
​
$report | Sort-Object HasPasskey | Format-Table -AutoSize

The caveat: for guests who authenticate at their home tenant under MFA trust, this returns little or nothing, because their credentials aren’t in your directory. A sparse result is not a sign they’re unprotected — it’s a sign your visibility ends at the boundary. Treat HasPasskey = $false as “unknown, investigate,” not “insecure.” When you move to enforcement, do it through a Conditional Access authentication-strength policy scoped to guest and external users, staged in report-only mode first, on a reviewed list of partner tenants — never a blanket flip.

So: enable it, absolutely. It’s the right direction and it removes a real excuse for keeping weak methods alive. Just drop the fantasy that a credential improvement erases an ownership problem. The password you most want to kill probably isn’t in your tenant, and no toggle in your admin center reaches it.