Two years of Passkeys: A reflection point

I have been quiet on writing for the last two years, mostly because I was not sure what to write. The FIDO ecosystem had a complete reboot. The change was messy, and full of slogans. In 20 months the FIDO ecosystem changed its paradigm, security model, feature set, and name.

The king is dead! (FIDO) Long live the king! (Passkeys)

Coming back from my publishing hiatus, I want to look back on where the FIDO ecosystem was just three short years ago, and where we are now — the world of Passkeys.

This article is not about religious preaching, or trying to set the world ablaze (😘 Firstyear).

Instead, it’s written to help us better understand where we came from and what the future might hold for the FIDO ecosystem by answering three simple questions:

• What were passkeys before 2022?
• What are the passkeys today?
• What is missing?

Let’s get rolling.

What were passkeys before 2022?

Until 2022, FIDO Alliance followed a four-prong strategy:

1. Security
2. MFA
3. Phishing resistance
4. Death to passwords

Every step that FIDO took until 2022 carefully followed that strategy. The resulting ecosystem entering 2022 looked like this:

The core features of platform passkeys before 2022, were:

• Keys can not be exported, period. (We will get later to that part)
• Vast majority of the private keys were hardware protected (apart from some Android devices).
• You had a very solid indication of security of the key material via attestation. TPM, Apple, SafetyNet, would give you clear indicators on where a key was stored, and how well it was protected.
• While the user experience wasn’t perfect, it was consistent enough to support adoption.
• Platform solutions could’ve been deployed in various environments, from small websites, to huge Govt. eID solutions.
• But… Account recovery was a problem.

So in summary: Before 2022, the FIDO Alliance focused on security, multi-factor authentication (MFA), phishing resistance, and eliminating passwords. Although the platform passkeys had robust security features, including hardware protection and attestation, account recovery remained a significant challenge despite widespread adoption.

What are the passkeys today?

First, let’s discuss the term. Passkeys, as alternative to passwords, just mean FIDO credentials, or FIDO. That’s it. So we can all stop saying “WebAuthn”, and “FIDO”, with just say “passkeys”. This is a positive move by the alliance and the platforms, as it creates a unified technology brand, and simplifies user messaging. “Login with passkey” is simple, and intuitive.

Passkeys, as a strategy, were created for marketing and adoption. The reality is that no matter how you look at the situation, phishing is the number one threat to online security, and the only viable solution to this threat is phishing resistant authentication, aka passkeys, aka FIDO. The passkeys were focused on simplifying deployment, encouraging adoption, and clearing roadblocks. In spite of the original goal, the reality of the last two has been less than desirable, with aggressive change to the ecosystem, chaotic messaging, and lack of vision beyond large consumer enterprises.

Passkeys bring a big improvement in account recovery by offloading that responsibility to the user’s platform, with authentication synced across devices — set it up on your iPad, and it’s ready to use on your MacBook. This simplifies both the user experience and the messaging around it.

Where passkeys fall short is in areas like device binding, multi-factor support, assurance levels, and some aspects of privacy and security. While they’re still based on the same technical standards — FIDO2 and WebAuthn — the approach has shifted. Previously, FIDO credentials were device-bound, meaning they were tied to a specific device. Now, companies like Apple and Google have moved to a default model where passkeys are synced across devices via their cloud services. Although the option for device-bound passkeys still technically exists, it’s effectively been deprecated, with only Microsoft continuing to support it, with the unfortunate caveat of not supporting synced passkeys.

So here’s what passkeys look like today:

Feature wise:

• Overall, less issues with account recovery, so big win with UX.
• Account recovery is good, since keys are synchronised, if you register on iPhone, it will work on iPad, MacBook, etc, within your ecosystem. You lost an iPhone, so long you can login to your iCloud you will be fine.

And the issues:

• It’s phishing resistant, BUT a single factor, since it does not give you device binding.
• Limited usability in all high assurance industries: Banking, eGov, Medical, Enterprise, etc, since it is a single factor.
• Under PSD2/PSD3 it is considered a single factor, so EU banks need an additional factor with it, so those that deploy passkeys, do it with… SMS…
• Cross-ecosystem, hybrid flow, has really strong user friction. One of my clients during testing had close to 80% drop off when hybrid flow was invoked.

Which brings us to the elephant in the room, enterprises do not care for passkeys, and without enterprises, we only solve half of the adoption.

What is missing?

One of the most common arguments I’ve encountered for eliminating support for device-bound credentials is related to adoption. The goal is to deploy passkeys to as many users as possible, and since a purely device-bound approach supposedly didn’t work, the platforms opted for a synced passkeys instead. But let’s pause for a moment and consider the experience of the average user.

In the same reality where a mom is packing her kids’ school lunches and catching up with her sister on Facebook, she also needs to check her Chase bank account and log into her Etsy’s PayPal account to see how much she’s earned. People manage multiple online identities, each requiring varying levels of security, and often must balance convenience with security depending on the situation.

The puritanic, convenience, and marketing focused strategy, is killing the deployments that this ecosystem needs. Where, the same mom, might be furious about additional security checks when logging in to Facebook, she would be completely oblivious about more friction when logging into her bank account.

The success of the ecosystem isn’t driven by features alone. Over the past two years, we’ve seen important user experience improvements that FIDO needed, such as WebAuthn Autofill and seamless recovery with synced credentials. However, to reach the same level of ubiquity as passwords — which, I might add, are a complete nightmare — we still have a long way to go. This is especially critical as phishing and fraud are on the rise, and AI-driven impersonations are becoming so advanced that KYC and IDV systems are likely to face significant challenges in the years ahead.

Which brings me to the point of this article.

Recently proposed Supplemental Public Keys (SPK) proposal has been killed, with a note that something might replace them. This does not amaze me, since both Device Public Keys (DPK) and device bound credentials were killed. These actions did not go unnoticed.

As of now, no major banks are planning to roll out passkeys, nor insurance companies, nor actual GovID systems. There is just too little to offer over the existing legacy solutions, even though they are obviously not phishing resistant.

When we think about the success of technology, we need to take into account what economists call an opportunity cost. When a product/engineering team has to take on migrating to new technology, they have multiple projects on the road map. Passkeys require quite substantial engineering resources to integrate them, and considering how little they deliver, the basic question would be: Should we invest into a single factor passkeys, that still needs step up, and are unfamiliar to our users, OR stick to time tested password + SMS, and work on new user impactful products, that would satisfy our customers and shareholders?

In order to make passkeys truly successful, they need to be outstanding in comparison to the existing authentication solutions, with actual support for SCA and high assurance scenarios, and trust mechanisms that allow services to be confident in their authentication solution.

The unfortunate result of ignoring high assurance scenarios is that those that need phishing resistant authentication the most, banks, insurance, eGov, are the ones that are not compelled enough to use them.

What passkeys ecosystem needs is a concrete commitment from the platforms on three specific points:

1. Device binding signal — Like what SPK with device scope, and DPK were.
2. Device attestation — So that you know that your device signal was not generated by a malware. Without it there is no way for services to distinguish malware generated passkeys injected via XSS attack, vs real hardware backed credentials.
3. Provider signal — So that RPs know when passkey was shared, stolen, or exported.

These all were part of the original SPK proposal, and were good.

And lastly what we need is a long term commitment to the stability of the ecosystem. The “move fast, break things” approach that we’ve experienced in the last few years has left lots of companies that were deploying passkeys, before they even were passkeys, in a state of distrust. The only way this can change is if there are concrete steps in stabilising the ecosystem, clear messaging, and actual standards with some sensible commitment not to break them.

Notes:

Supplemental Public Keys (SPKs)

This was a proposed extension that would add a secondary keys to the main passkey. Basically you get multi-device passkey, and you get device-bound public key that is signing over your passkey, and so you get device binding.

Additionally it would have “provider” key, that would link your main passkey to the keychain, so that in the case where passkey was shared with someone, or stolen, you would be able to detect it by receiving different provider key.

Device Public Key, or DPK, was earlier iteration of SPK.