I guess (speculation!) that the origin of the limit may be “historical”: a few years ago, hardware security keys were even less “widespread” as they are now (they aren’t), and I can imagine that with the limit of five, the idea was “who will ever have more than 5 hardware keys?”.
[PS: the FIDO alliance was founded in 2012… the idea, that other devices than “hardware keys” (e.g. my Android device and Windows Hello/TPM can also store passkeys now) would support FIDO/FIDO2 is also fairly new and may have not been considered, as this function was first implemented here )
Second thought: the function works. It is limited, but it works. - If it wouldn’t work (properly), there may be a change sooner.
And third: I guess, not enough developers have a problem with the limit themselves.
While I agree with the sentiment that 5 Passkeys for 2SV might fall short in some cases (not in my particular one right now, but by a little, I have 4).
This advice to switch to synced Passkeys I think is a valid one.
However, it should be pointed that it might not satisfy everyone, as synced Passkeys should be, by default, considered less secure that the device-bound ones.
Device-bound Passkeys can really be considered another authentication factor (something you have). Synced Passkeys can not (strictly speaking).
Absolutely. NIST makes this clear in the current draft of their Identity Guidelines. Reaching their highest assurance level (AAL3) requires the equivalent of a device-bound Passkey:
Without hardware-based (“device bound”), the best one can do is AAL2, which is where syncable Passkeys best-fit.
Although the hardware requirement is a significant improvement, NIST considers it separately from the three factors. NIST considers both syncable and device bound passkeys (“Single-/Multi- Factor Cryptographic Authenticators”) to be something you have, and if User-Verification is present, to also be something you are or something you know.
I guess this is due to the fact that keys may be used for vault encryption. With each new key any change in the vault has to be encrypted again, thus increasing the server load.
I don’t believe that in normal circumstances where the user has a password set, that Passkeys have any bearing on vault encryption. Also, vault encryption should be occurring client-side anyways, such that the unencrypted data is never processed by the server.
That depends on the implementation, e.g. if the data is encrypted multiple times. But you are right, normally this should happen only on the client side. However, this could still be the reason for a limit like the warning when changing the number of KDF iterations.
Marlin, that’s not the feature that OP or many of these other people are using. They’re using Second-Factor passkeys on top of already having a password set.
So, to support this Feature Request, it would be ~100 KB of storage per additional security key. That’s minuscule and should certainly be considered given the unlimited vault storage items allowed.
Ah, this thread started in 2020 and back then the vault encryption with passkeys was not available. Thanks for clearing that up and sorry if I caused any confusion.
This thread is about FIDO2-credentials as 2FA. Bitwarden calls them inaccurately “passkeys”, though they are not passkeys per definition of the FIDO alliance, since they are non-discoverable credentials. (though there is some not quite proven speculation, if Bitwarden might create them - or at least the “other side” stores them - also as discoverable credentials under certain circumstances)
Then there is the “login-with-passkey”-feature of Bitwarden. Here, Bitwarden indeed creates “discoverable credentials” = passkeys. And only here come “with encryption”/PRF etc. into play. But this whole second point here is not what this feature request is about. PS: A feature request for this point: Support more than 5 passkeys for passwordless login
PS: And if you insist on using the term “passkey” for both FIDO2-Bitwarden-credentials (as 2FA vs. as “login-with-passkey”), please at least make sure of which of both types you are talking.
I just feel safer, if I have this unique private encryption key on a hardware key that I am able to take to bed with me I would like to have this as my only verfication method. Then, it is understood that perhaps registering more than 5 hardware keys - given a large family - is more than appropriate. Any objections? (The vault encryption topic is excluded here.)
Agreed. But why having a limit in the first place, if the technical reason is not proven and server are getting more powerful as we speak? It should be best to leave the number of hardware keys to the discretion of each individual. I see a reasonable upper number such as 10 or 100 may make sense but 5 is the objective of this and has been that of other threads.
The best thing you can do to support this feature request (other than voting) is to provide a clear description of your use-case, with an explanation for how the proposed feature would make a difference to you.
I absolutely support a higher limit for FIDO2-2FA keys, and though I can see the appeal in diversification and several “key pairs”, more such backup keys don’t necessarily have to come “in pairs” (though I understand that one want’s that).
)
I personally find that limitation very inconveniant. 
I would like to have this as my only verfication method. Then, it is understood that perhaps registering more than 5 hardware keys - given a large family - is more than appropriate. Any objections? (The vault encryption topic is excluded here.)