Security key backup was always the biggest obstacle. In principle you could create fungible keys flashed with the same private key, but in practice that isn't possible (outside of some obscure open-source implementations).
The second obstacle, of course, is the question: why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
> In principle you could create fungible keys flashed with the same private key, but in practice that isn't possible (outside of some obscure open-source implementations).
> why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.
Trusted computing and vendor neutrality are unfortunately somewhat at odds with each other. Google has learned that the hard way with Google Pay – only when they finally gave up on Secure Elements (in favor of HEE and software-based OS attestation) did it become available on non-Google devices. The device vendors and mobile carriers (which control the SIM, the only other pragmatic trusted hardware).
It would be amazing if there was a sort of "embeddable Yubikey" specification that would allow you to, logically or physically, install your own Secure Element/TPM and have that be decoupled from both OS and OEM, but it would be a major upstream effort.
The second obstacle, of course, is the question: why do I need a separate microcontroller taking up a USB slot, when the host device is capable of running the same software? Passkeys do solve that (though so would soft-FIDO without resident keys), but the bait comes with the hook of vendor lock-in.