Passkeys for B2B guests in Entra ID: close the supplier authentication gap before October

Your staff sign in with phishing-resistant methods. The contractor in your finance SharePoint may not. Microsoft's next Entra ID change removes the last technical excuse.
The boundary problem
Most organisations have spent the last two years raising the bar on employee sign-in. Phishing-resistant methods, Conditional Access, authentication strength policies, the retirement of SMS and voice.
That work usually stops at the organisation's boundary.
Suppliers, contractors, auditors and partners reach the same SharePoint sites, Teams channels and line-of-business apps as B2B guests. Their sign-in is often held to a different standard, and sometimes to no standard the resource tenant has chosen at all.
In most client tenants I review, guest accounts are left out of strong authentication. They rely on the guest's home-tenant MFA, if they check for any at all.
Why this is a business risk, not a configuration detail
The Verizon 2026 Data Breach Investigations Report found that breaches with third-party involvement grew by 60% year on year and now account for 48% of all breaches in its dataset.
The same report looked at the publicised cloud-based third-party incidents of 2025. It found that a good number came down to insecure authentication, such as missing MFA or poor credential rotation, or to a lack of least privilege.
For a CIO or CISO, that turns guest authentication from an admin setting into a supply-chain control. For organisations in scope of NIS2, Article 21 lists supply-chain security and the use of multi-factor authentication among the required risk-management measures. An auditor who asks about one will reasonably ask how you apply the other to your suppliers.
What Microsoft is changing
Message Center post MC1459133 announces passkey registration and sign-in for B2B users in Microsoft Entra ID. This covers both internal guest users and external users.
Eligible B2B users will be able to register a passkey issued by the resource tenant (your tenant) and use it to satisfy your MFA requirements.
Why it matters. Until now, a B2B user could not use a resource-tenant passkey when your tenant required MFA and did not trust the home tenant's MFA. Microsoft's guidance on authentication strength for external users shows the effect. When MFA is completed in the resource tenant, the only available methods are text message, voice call, Microsoft Authenticator push and OATH software tokens. None of those is phishing-resistant.
How users register. Users can register a resource-tenant passkey from your My Security Info page, during a proof-up prompt, or through a passkey registration campaign.
Rollout schedule (per MC1459133):
Population | Timing |
Overall general availability | Early October 2026 to late February 2027 |
Internal guest users | Early October to late October 2026 |
External users | To be announced in a future Message Center update |
Scope caveats:
The schedule covers Worldwide and GCC tenants. GCC High and DoD are not covered by this notice.
Microsoft Authenticator passkeys will be supported for internal guests but not for external users.
Most partner accounts in B2B collaboration are external users (they authenticate in their own organisation). For them the resource-tenant passkey option arrives later than October.
Defaults. The feature is enabled by default, and Microsoft says no action is required. B2B users who are already in scope of your passkey policy become eligible automatically.
The catch: excluding guests is not enough on its own
This is the detail most summaries miss.
Microsoft's SMS and voice retirement changes (MC1426371 and MC1434201) mean that any user enabled for SMS or voice becomes enabled for all passkey types automatically. This applies whether SMS or voice is enabled in the Authentication methods policy or in legacy MFA policies, and eligible B2B users are included once B2B passkey support is available.
Microsoft is explicit that excluding these users from the passkey policy alone will not prevent this. If you don't want specific guests enabled for passkeys, you have to move them off SMS and voice in every applicable policy.
In practice, the passkey scope for your guests is set as much by leftover SMS and voice assignments as by the passkey policy itself.
Trust or strength: decide what you actually accept
Many organisations handle guest MFA by trusting the home tenant through cross-tenant access settings. That is a reasonable choice. It spares partners a second prompt and uses the MFA they already have.
On its own, however, trust only tells your tenant that some MFA happened in the partner's tenant. A text message or a voice call satisfies it.
The meaningful control is the combination:
MFA trust plus a phishing-resistant authentication strength. With trust enabled, only the home-tenant claims Microsoft lists for external users are accepted. A phishing-resistant strength narrows that to methods such as FIDO2 security keys, Windows Hello for Business and certificate-based authentication. Your requirement applies, even though the partner performed the MFA.
No trust plus a phishing-resistant authentication strength. Until this change, guests had no way to meet this in your tenant. Resource-tenant passkeys start to close that gap, internal guests first.
Trust with no strength requirement. You accept whatever your least mature partner allows.
One limitation to plan for: authentication strength policies currently apply only to external users who authenticate with Microsoft Entra ID. For email one-time passcode and SAML/WS-Fed guests, Microsoft directs you to the "require MFA" grant control instead.
Pre-rollout checklist
Work through these before internal guests start receiving the feature in early October.
Inventory your guests. Separate internal guests from external users, identify which partner organisations they belong to, and remove accounts that no longer need access.
Set passkey scope deliberately. Review the Authentication methods policy and confirm which users are in scope for passkeys, including guest and external users. Exclude groups that shouldn't be in scope.
Clean up SMS and voice. Check SMS and voice assignments in both the Authentication methods policy and any legacy MFA policies. For guests you don't want auto-enabled for passkeys, move them off SMS and voice everywhere.
Check registration campaigns. Confirm the passkey registration campaign's user scope matches your intent for guests.
Review Conditional Access for guests. Confirm which policies target guest or external users, and whether sensitive apps require a phishing-resistant authentication strength rather than generic MFA.
Review cross-tenant MFA trust. Decide per partner whether you trust home-tenant MFA, and pair that trust with an authentication strength where the data warrants it.
Align policy scoping. Make sure the groups and user types targeted by each authentication-related policy match your requirements for guests and external users.
Assign ownership. Every guest population should have a business owner who can answer why the access exists and how it is authenticated.
What good looks like
A mature organisation can answer three questions for any external identity in its tenant:
who sponsored the access,
what it can reach,
which authentication method was required, and by whom.
It applies the same authentication strength to a contractor handling financial data as to the employee sitting next to them. And it reviews guest access on the same cycle as staff access, because under NIS2 and ISO/IEC 27001:2022 (supplier relationship controls 5.19 to 5.22, and secure authentication, 8.5), auditors increasingly look at both.
The question to take to your next security review
Take the last external contractor who opened your most sensitive application. Which authentication method did they use, and who decided that it was acceptable?
If the answer takes more than a minute to find, the October rollout is a good time to fix it.
Nimbus Cyber helps organisations review identity and access across employees, guests and non-human identities, and design authentication policies that hold up to audit.
Sources
Microsoft 365 Message Center, MC1459133, Microsoft Entra ID: Passkey support for B2B users (2026). https://admin.microsoft.com/#/MessageCenter/:/messages/MC1459133
Microsoft 365 Message Center, MC1426371, SMS and voice authentication retirement. https://mc.merill.net/message/MC1426371
Microsoft Learn, Passkeys by default and retirement of Microsoft-provided SMS and voice authentication. https://learn.microsoft.com/en-au/entra/identity/authentication/concept-sms-voice-retirement
Microsoft Learn, Frequently asked questions about SMS and voice retirement. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq
Microsoft Learn, Authentication strength for external users. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strength-external-users
Microsoft Learn, Require MFA for guest access (notes on authentication strength limits for external users). https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-old-require-mfa-guest
Microsoft Learn, B2B collaboration user properties (internal guests vs external users). https://learn.microsoft.com/entra/external-id/user-properties
Verizon, 2026 Data Breach Investigations Report. https://www.verizon.com/dbir
Directive (EU) 2022/2555 (NIS2), Article 21, EUR-Lex. https://eur-lex.europa.eu/eli/dir/2022/2555/oj



Comments