Microsoft is introducing passkeys for B2B users in Entra ID. With the roadmap entry RM569432, published on October 1, 2026, internal guests and external users will soon be able to register a passkey issued by the resource tenant and use it to meet its phishing-resistant MFA requirement.
This was explicitly not possible before: Passkeys only worked for member users in their home tenant; guests were excluded from registration. This update closes that gap—and it’s a significant one, because external collaboration has so far been the area where strong, phishing-resistant authentication was hardest to enforce.
B2B users can register the passkey via the My Security Info page of the resource tenant, during a proof-up prompt, or through a passkey registration campaign. One detail deserves attention: Passkeys from the Microsoft Authenticator app are supported for internal guests, but not for external users. External users require a different type of passkey, such as a device-bound FIDO2 key.
Enabled by default, and that's the catch
The feature is enabled by default. B2B users who are already within the scope of your authentication methods policy for passkeys will be automatically activated without you having to enable anything. This is convenient but shifts the workload forward: you need to know before the rollout who in your tenant is actually in scope, otherwise guests and external partners will suddenly start seeing registration prompts.
For administrators, this means specifically checking three areas before deployment.
- First, the authentication methods policy: Which guests and external users are in scope for passkeys.
- Second, the passkey registration campaign: Who would it appeal to?
- Third, the conditional access policies for guests: Does the new phishing-resistant method count as valid strong authentication there?
Also inform the service desk, as a wave of unexpected registration requests from partners will otherwise end up as incident reports.
Conclusion
Passkeys for guests are a long-overdue step, as external identities have so far been the weakest link in many otherwise well-secured tenants. Those who enforced MFA for guests had to rely on methods that are less phishing-resistant than what has long been required of internal users. This asymmetry is now disappearing.
The only stumbling block is the default-on: A feature that activates without intervention catches precisely those organizations off guard that have never consciously configured their guest scopes. Those who know their authentication methods policy and have pre-validated guest conditional access will benefit from the improvement without it ever surfacing in support.
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Leave a comment
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.