I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. It's offsite because that protects me from fire or other such catastrophic events.

This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.

> I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient.

As stated, you can have as many backup keys as you like.

Thus you are not limited to two keys.

Buy one more key. Keep one off-site and two on-prem. Rotate them once in a while to keep the off-site one fresh.

> As stated, you can have as many backup keys as you like.

That does not solve anything unless the backup keys are enrolled to each and every one of the services you use. Adding more backup keys and storing them more and more securely just makes it harder to be sure that you've enrolled them all to the latest service.

This is not an issue if users are explicitly allowed to enroll "virtual" soft authenticators that they can back up and restore as they see fit, but that's an additional requirement that comes at some compromise, since some services might instead want to ensure that you're enrolling a non-cloneable credential. (E.g. your physical bank or non-remote employer, that can easily verify your identity via additional means if needed to restore your access.) The WebAuthn spec allows for both models.

I think their point is that they don't want to have the window of vulnerability (to loss) when they have added a new account but haven't yet rotated their off-site key?

That said, the real answer is that FIDO keys can be synced by e.g. Apple (as described in more detail here: https://www.wired.com/story/fido-alliance-ios-android-passwo...). So you can potentially just make your offsite backup be a hardware key that gets you into your iCloud keychain, and (if you are willing to trust Apple) use your iCloud for backing up all your other accounts' keys.

You cannot register more than one security key with *AWS*. Which a lot of devs beg for, for years. Can't find that support ticket URL now.

That’s a pretty big foul. I use a different hardware key plugged into each workstation I use and then some “roaming” keys that I can use for backup, travel, etc.

To work around this I sync multiple Ledger devices with identical seed phrases which allow for duplicate FIDO devices that can be shared with any teams that need break-glass root account access.

AWS employees are issued two Yubikeys, which are registered for all internal auth use cases. For me, but not for thee, it seems.

And probably never will because the official unofficial solution is to use SSO and have your identity provider handle that.

I have 100s of passwords and dozens of TOTP keys in my password manager. Logging into every one of these sites with 2 keys, and having to re-auth with all of them if you lose one of those is unworkable. It only really makes sense for centralized auth solutions like you'd have at work, not for day to day personal things. I want a FIDO key that I can use for day to day things.

Backup a 24 word seed phrase once on a FIDO device that supports BIP39.

Now go enroll 100 sites in it and then lose or destroy the device.

Enter the 24 word backup to a new device and access to your 100 sites is restored.

This sounds like what GGP would want. Does it exist?

First of all, _most_ services is not _all_ services, so you have a use case here.

Also, you could make FIDO keys that support restoring but not backing up. If you could set up a FIDO with custom random seed _as an expert option_, then you could have a secure key, and keeping the seed private would be your expert problem.

I would adopt such a solution, whereas now I don't adopt the proposed solution because I cannot add a new service while having the backup key remaining off-site.

Maybe another solution would be to be to have _absolutely all_ services accept several keys (enforced by protocol), in addition to be able to accept adding an off-site key with only its fingerprint, but without requiring to have it physically.