>you are free to use a dedicated USB key storage instead to store your private key As long as the server supports the device/protocol/options you want, and doe

>you are free to use a dedicated USB key storage instead to store your private key As long as the server supports the device/protocol/options you want, and doesn't enforce attestation against a small list of enterprise vendors. For instance Microsoft Azure AD's Entra ID authentication service, the one that keeps changing name, has a hardcoded list which you can consult here: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passwordless#fido2-security-key-providers https://learn.microsoft.com/en-us/entra/identity/authenticat... In theory there's no vendor lock-in. As long as Azure adds your vendor to the Azure-approved list, and as long as every other provider refrains from making their own list. For the Apple/Google ecosystems specifically, it's also important to keep the compatibility matrix for each service in mind. For instance with Azure again: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-fido2-compatibility https://learn.microsoft.com/en-us/entra/identity/authenticat... In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.