Some other responders have given you the answer as it currently exists. They are all either inconvenient, weaken security, or both. For that reason, I would only suggest using a security key for a small number of critical services, where it's worth the extra effort to deal with the backup mechanisms.
If you mean when registering for a new account, annoyingly you need to physically have each key with you to register it with a new service. Biggest flaw in the spec IMO.
If creating new accounts only when you are at the secure location where your backup key lives works for you that's great, but I suspect that most people in that situation would do one or more of the following:
(1) Store their backup key in a more convenient, but less secure location (likely their home), putting them at risk of losing both the primary and backup key to the same event.
(2) Enroll only their primary key when an account is created, putting them at risk of locking themself out if they forget to add the backup at some point.
(3) Only use security keys for the highest value accounts, which tend to be a small enough number that you have a chance of actually remembering to add the backup key every time you set one up.
Of these, #3 is the only one that doesn't pose what I consider an unacceptable risk of lockout to the average person, so that's what I recommend.
The location doesn't need to be "secure" in the military sense of the term. Mainly you want it "secure" in the sense that if you lose the one key, you won't have lost the other key at the same time.
In the end, the two keys are equivalent from a risk profile if they are compromised, and for most people, the one they carry with them is going to be the weak link in the chain, so additional security on the other key isn't really accomplishing much.
In truth, if your home isn't secured, there's enough holes in most people's online security that someone in your home could find a way to compromise much of your online security (and from there, most of the rest).
Just keeping the other key tucked away in a drawer has some risk, but is pretty decent for most people. Keeping it locked in a fireproof safe in their home along with other important documents/keys/bits is a better choice and not terribly inconvenient.
If you want to be more thorough, you can always have a third key that you keep locked away in a bank vault, and you do "wing it" with just two keys for a period of time on new accounts.
What you don't want to do is "wing it" with one key (though AWS seems to think that's the way to do things). That can lead to disaster. What you also don't want to do is only use it for a subset of your accounts, because in practice most people are terrible at risk compartmentalization, so invariably a compromise of some of your accounts quickly becomes a compromise in all of them.
In my experience #1 is the right way for most people to go. There are disaster scenarios where you lose both keys, but usually that's a disaster severe enough that recovering your online access is the least of your worries, and it does a great job of mitigating the much larger risk of mismanaging the security of accounts that aren't secured with the key.
I agree with your definition of secure for this topic. I don't agree that a primary residence qualifies as secure under that definition. Fire, flood, earthquake, etc all put you at risk of losing both keys, as does a search by law enforcement.
I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened.
And home isn't really convenient enough for many people: I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2.
"I _really_ don't agree that if one of those things happen I will no longer care about accessing my digital possessions/accounts. If anything I need that access more than I did before it happened."
You might care, but most people would have bigger problems at that point.
> I, for one, frequently create accounts at work and when traveling. This subset of people are going to be doing either #2 or #3.
Again, most people aren't on the road a lot, and most of those that do already follow so many other bad security practices when they do so that creating new accounts in that context will already be fraught with peril regardless of the mechanism you use... and they'd probably be increasing their exposure if they used a password manager. I'd advise them to not do it, or to create a temporary account using some low-security, low-tech compartmentalized mechanism (like writing the passwords on a piece of paper ;-) and then delete the whole thing and create a new one from scratch when they get home, because that's probably less likely to be a problem. ;-)
"For the folks that are still using the same password everywhere I think a password manager is a better recommendation than a security key. For one it helps them everywhere, not just the small number of sites that currently support U2F/Webauthn. For another, such a person is probably at high risk of making mistake #2."
I do use a YubiKey secured password manager for services that do not currently support U2F/Webauthn, so I agree that is really the only practical solution for certain cases. There's an in between space where you can use the SmartCard protocol or hardware based OTP, but... My observation has been that for "most people" the non Webauthn cases are a) not necessary and b) actually far more difficult for them to manage, leading to them simply not using the password manager for a lot of cases.
It turns out the typical person's needs are surprisingly limited, but the risk is enormous as is the number of "pathways to failure".
However, a good solution for this issue is finally in the works: https://www.yubico.com/blog/yubico-proposes-webauthn-protoco...