If you don't know what webauthn is about, it's basically a passwordless to "login". I invite you to start reading the first post of this serie if you want an introduction.

Basically, the webauthn protocol handles how asymmetric keys are created and verified. They are also bound to the device. If you loose your device, you loose your access key.

The first question that arises is "What happens if I loose my device?! Would I be locked out?!" The simple answer is "yes". That's why it is important to have a way to recover it.

However, there are plenty of ways how you could deal with account recovery as a provider. Here are some.

1. associate the account to an email/phone and simply send a link to register a new device on demand
2. provide a link or QR code to register a new device that the user can store somewhere safe
3. use recovery passwords
4. register multiple devices
5. video identification / confirmation

All of these recovery methods have their strength and weaknesses, but share the same purpose: to allow to register a new device for the account. Regarding these recovery methods, here are a few more considerations.

1. By sending an email/sms, you implicitely trust that the user has not compromised either.
2. Same goes for the link or QR code, you must be sure it is safely stored and not exposed/stolen.
3. Since passwords are easely forgotten, a question/answer system is sometimes a nice alternative.
4. This requires that the user has multiple devices ...and to not loose them at once.
5. In order to recover the account that way, it must obviously be verified upon registration too.

These methods are also not exclusive. They could be used as alternatives or even combined for increased security.

Lastly, some more tibits. There was quite some discussions about making "backups" of the credentials in the specifications working group, and baking it into the protocol. Honestly, it sounds to me like opening Pandora's box. The fact that the private key is a secret that only the device knows makes it secure and easy to reason about. Allowing to "share" this key, or a derivative of it, in the name of backups sounds risky to me.