Difference to other authentification schemes
So, why is a technology giant like Microsoft alongside other major companies such as Google, Intel or Amazon pushing for the FIDO specification to become an integral part of its operating systems (https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/20/sign-in-to-your-microsoft-account-without-a-password-using-windows-hello-or-a-security-key/) and the entire product family as recently announced at Microsoft Ignite (https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/What-s-new-in-Azure-Active-Directory-at-Microsoft-Ignite-2019/ba-p/827831)?
If you are looking to supersede password based authentication on a large (enterprise) scale, e.g. Azure AD, please keep in mind that TOTP among other conventional authentication solutions is generally rather tricky to handle. On top of its reliance on a shared / symmetric secret, the scheme also requires solid clock synchronisation which may not always work well depending on various factors such as latency for instance. Please also note that TOTP uses time to generate a One Time Password which is of course far from being as unique as true entropy or a Pseudo Random Number Generator (PRNG) based on one. That observation calls for additional countermeasures, e.g. rate limiting. TOTP is vulnerable to phishing, can be attacked from the inside by a rogue administrator for instance and on the practical side of things TOTP client devices require batteries.
FIDO on the other hand uses asymmetric keys which are decoupled from the user’s secret: the biometric sample of the user’s fingerprint for instance is never sent to a FIDO server / Relying Party. Instead, upon a successful local authentication attempt which could entail PIN entry and fingerprint unlock to support 2FA, the FIDO device generates and registers a public key with the Relying Party. That means that in contrast to TOTP where the shared secret is largely stored in the clear on the server side (unless additional countermeasures such as low-level volume or transparent data encryption with databases are implemented), FIDO “gets away” with public user keys only. A final note on the countermeasures: low-level volume or transparent data encryption can only reach the highest currently known level of protection if used in conjunction with hardware-based key management which again would not be explicitly required for FIDO.
Incidentally, FIDO also supports Federated Identity Management (FIM) (see https://fidoalliance.org/specs/fido-uaf-v1.1-id-20170202/fido-uaf-overview-v1.1-id-20170202.html, section 5) which could come in handy in a B2B/AAD scenario. Section 6 by the way also indicates that FIDO is working to extend its realm into OATH and other standards.
Last, but not least: it is possible to have a heterogenous setup where PCs, laptops or similar workstations could use the power of a 2FA biometric-enabled USB dongle while also leveraging the usual mobile platforms (e.g. Android or iOS) to run MS Authenticator by way of a backup or if your company supports the idea of Bring Your Own Devices (BYOD) or Mobile Device Management (MDM) in conjunction with strong smartphone key storage capabilities.
For more information on Microsoft’s new passwordless strategy, kindly refer to https://www.microsoft.com/en-us/security/technology/identity-access-management/passwordless