On Safari, there is a known issue where sending too many FIDO credentials in the “allow list” in a Webauthn authentication will cause the YubiKey to appear to be unresponsive.
The “allow list” is used in passwordless authentication flows where the user enters their username, and is prompted to use their YubiKey with a PIN, and second factor flows, where the user enters their username and password, and then is prompted to use their YubiKey without entering a PIN.
The “allow list” is not used with usernameless flows, where a user is prompted to use their YubiKey first, and then (optionally) selects a username afterward.
When using FIDO / Webauthn on a YubiKey to log in to a web site or identity provider,
there are three distinct flows:
* The first, which is most similar to the original U2F standard, is Webauthn as a
second factor. This relies on traditional username and password authentication,
and then using a YubiKey or similar FIDO device as an MFA factor.
* The second, passwordless, was introduced with FIDO2. It relies on getting the
username either by prompting the user or using persistent cookies, and then
prompting the user to use their YubiKey with a PIN.
* The third, usernameless, was also introduced with FIDO2, and has been popularized
as “passkey” logon, where the user only needs to activate their FIDO device using
a PIN or biometric, and they can be securely logged into a service.
Some identity providers (like personal Microsoft accounts and Microsoft Entra) and GitHub, will allow the user to log in with either a usernameless or a passwordless flow.
The exact number of credentials in the allow list can vary depending on a number of factors, including the type and firmware version of the YubiKey, the algorithm type of Webauthn credential, and other data that contributes to the overall size of the messages sent to the YubiKey.
While this issue affects all web sites and identity providers that allow usernameless and Webauthn as a second factor login flows, it is more likely to occur with Microsoft (both consumer and Entra) accounts, because Microsoft supports a variety of passkey authentication methods which also get added to the "allow list" this may include Windows Hello, Microsoft Authenticator, and macOS Platform SSO credentials.
Yubico has reported this issue to Apple, however we encourage affected users to report the feedback to Apple through their Feedback program, and reach out to Apple sales team if applicable.
Issue possible mitigations and workarounds
- Use a different browser:
- On MacOS, Chromium based browsers are unaffected by this issue.
- On iOS/iPadOS, all browsers are affected
- Consider removing some passkeys/security keys from your accounts.
Before engaging in other workarounds, make sure that all of the registered passkeys (or devices in the case of Microsoft accounts) are necessary. Remove any devices or passkeys you no longer have access to. - Use a “usernameless” authentication flow:
For example Entra ID allows a usernameless login option.
When prompted for username at the Sign in screen, instead of typing username select Sign-in options
Select Face, fingerprint, PIN or security keyThen follow the prompts to sign-in with a security key.