One of the most popular recent developments in passwordless is FIDO (Fast Identity Online). FIDO is an open standard that enables users to authenticate via a highly secure cryptographic login, which is phishing resistant and easy to implement. FIDO2—the latest protocol—leverages users’ physical devices to store credential information locally on secured hardware and sign authentication challenges.
The joint announcement by Apple, Google, and Microsoft to support passwordless is a clear statement that FIDO is the way to move towards a passwordless future, making it the new standard. Passkeys remove the most common barriers to FIDO adoption by (1) enabling users to enroll to FIDO once, sharing the credential between devices on the same platform, and (2) being able to leverage registered FIDO devices on one platform to authenticate when logging in from another.
Getting here wasn’t without some challenges. Let’s back up a little bit to see how we got to where we are now.
Initial Problems with FIDO
As a cryptographic solution that is both domain-bound and hardware-bound, FIDO has a reputation for being a highly secure and recommended identity and access management (IAM) practice.
However, as innovative as FIDO is intended to be (especially compared to traditional password usage), there were some initial setbacks with FIDO that needed to be mitigated in order for major enterprises like Apple, Google, and Microsoft to be at the point they are now, in which they’re setting the bar and announcing the implementation of passwordless/FIDO passkeys.
Here are some of those setbacks:
Registration and Usability
One of the initial problems with FIDO was that it still had to utilize weaker authentication mechanisms (like passwords) during the initial registration process. The first time you would register a FIDO platform device, you would need to bind your user authentication to that platform on that device.
This meant that if you tried to log in from another platform device that you owned, you would first have to authenticate yourself using an alternative method (again, most likely going back to using a password) before the site or application would give you access. Then, once approved, you would need to register that new device as well in order to be able to leverage FIDO on that device thereafter. This process would have to repeat on each of the devices you used for access.
It’s easy to see how usability then became a tedious task, rendering organizations reluctant to give up traditional passwords and familiar login experiences—albeit weaker methods of authentication—in exchange for something else representing only a slight improvement.
Failure to Fully Eliminate Passwords
Considering the issues with registration, FIDO only really made sense in one circumstance. In order for FIDO to fulfill its vision of completely phasing out passwords and eliminating the threat of common password attacks, it needed to be fully adopted as the primary and only way for users to authenticate. In other words, the act of continuing to mix in traditional password login methods presented a conundrum that ultimately led FIDO to fail to live up to its passwordless promise.
Recovery
Furthermore, the failure to fully eliminate passwords ultimately led to recovery problems. To illustrate, organizations that pursued the route outlined above–choosing only FIDO as the main way for their users to authenticate–ended up facing account issues with user account recovery. These recovery problems resulted from the aforementioned usability issues. As a result, users ended up always needing access to at least two previously registered FIDO devices–in case they lost one–to enable account recovery.
Otherwise, in the absence of the only FIDO-registered device that their identities were bound to, they’d be unable to access any of their accounts.
Slow Adoption
As you can see, there were a plethora of conundrums associated with FIDO. From the inability to eliminate friction from the initial registration process, to the account recovery issues presented via the need to have additional back-up FIDO device as a fallback mechanism (in the event of a user losing their FIDO-enabled device), it was hard to see the benefit that FIDO would bring to organizations and their users. This turned out to be a significant deterrent to broad adoption of FIDO.