Passkeys, now with improved user experience

_{Cover image by Neil Moralee: https://www.flickr.com/photos/neilmoralee/49777943373/in/photostream/}

(Thanks for Michal Kamensky for proof-reading and providing feedback and discussion on the original post 😀)

Introduction

Back in February 2024, I wrote a long post about trying to use passkeys as a consumer. I’d heard loads and loads of buzz about passkeys and how they are bringing about the password-less revolution. However, whilst the technology itself is super-clever, the practicalities and edge-cases had made me hesitant to recommend it to actual organisations who are writing apps for consumers.

(This entire post and the previous post entirely ignore the business to business or enterprise uses for passkeys as they tend to have a more unified ecosystem. These posts focus on consumer-facing applications.)

Following a recent question, I decided to revisit this about 9 months on and see where things stand now.

If you read the previous post, I have marked sections which have been updated as “Updated” or are “New”. If you didn’t, or can’t remember it. Feel free to read through all the way as this post does not rely on the previous post.

If you don’t want to read a long story about me testing passkeys, you can see a summary and some conclusions from the “Experimentation Summary” section onwards.

Also, in certain cases I didn’t update the screenshots as they were identical to last time. I have marked these with “identical screen” just before the image.

Detailed walk-through

So this section is pretty long and complicated but if you are someone who cares about how this impacts user experience, I think it would be worth your while following the journey I went through.

If you don’t want to, maybe skip to the summary section at the end of the example part of the blog.

The chosen example

I decided to stay with Kayak.com as they were the basis of the previous post.

Kayak.com, the travel metasearch engine is one of the case studies which Google themselves highlights as part of their promotion of passkeys so it seemed like they would be a good option.

https://developers.googleblog.com/2023/10/how-kayak-reduced-sign-in-time-and-improved-security-with-passkeys.html

In this post, I’ll walk you through my experiences using passkeys with Kayak.com.

I want to make very clear that nothing in here should be considered critical of Kayak.com and it’s engineering organization. My primary aim is to demonstrate various use cases and allow people who are considering implementing passkeys to see the different situations their users might encounter.

Also, note that some of the screenshots are not strictly in order (e.g. I went back and took further screenshots later) but I am describing faithfully the steps I went through.

Where screens haven’t changed at all, I haven’t always replaced the original screenshots.

Part 1 Creating a mobile passkey

Native App on Android

So the first thing I tried was installing the Android native app. I go to login and see this screen:

Almost immediately though, this “Login with Google” screen pops up over it:

I don’t know if this is Kayak or Google making this pop up, but it is not what I want to do in this case so I close it again. It does however make me wonder whether social login is a far simpler way for B2C apps to handle authentication…

So I choose “Continue with email” and now I can enter in my email address. Throughout this, the username of the account I use to login will be a Hotmail account but when I store my passkeys shortly, it will be to a Google account. Hopefully that makes the different identities clearer.

Notice how it hasn’t said anything to me about passkeys. I believe this is a choice on the part of Kayak but I could be wrong.

I hit continue and it tells me I have been sent a verification code to my email. (identical screen)

Here we go, promptly delivered to my inbox. (identical screen)

I enter in my code and now I’m in as a registered user.

The sharp-eyed among you will have noticed that the “Account” option mentions passkeys. Having noticed that and dug into a couple of sub-menus, I can now create myself a passkey. (identical screen)

I hit “Create” and this screen tells me that I am creating a passkey for “KAYAK” for my Hotmail account, and storing it into my gmail account. (I could also choose other Google accounts from my phone to store it in.) (identical screen)

Now, this is important, something on my device has to be able to store/manage the passkey. Since I am on an Android phone, Google will be managing it. If I was on an iPhone, it would be going into my iCloud Keychain. If I was on a Windows machine then Microsoft would be handling it.

(Updated) So how is device support going?

This page shows which devices/manufacturers support what features:

https://passkeys.dev/device-support/

Back in February, this looked pretty complicated: https://web.archive.org/web/20240206042400/https://passkeys.dev/device-support/

It still looks pretty complicated although there do seem to have been some developments including:

• Better Ubuntu support via Browser Extensions
• Significant increase in support in Microsoft Edge from release 122 onwards
• Introduction of support in Android and iOS webviews.

So it does feel like things are moving although I don’t know if this will improve the ecosystem challenges that I discuss later.

Back to Kayak on Android

Anyway, a swipe of my fingerprint and now I have a passkey created.

So, now what can I do with this?

So if I log out of the app and then go to login, instead of the “Login with Google” pop-up, I now see a new pop-up.

(Updated) Use a passkey from a different device

So there is now an actual difference from last time.

This was the screen I saw last time:

This time around, I have a new option. “Use passkey from a different device”. That seems like an important addition for a situation where I enrolled a passkey somewhere else but want to login on this device.

If I choose that option, it shows me the following screen:

Now, as a consumer user I am less likely to have a USB or NFC security key but I may well have enrolled on a different computer or other device.

Back to Kayak on Android (again)

Anyway, I can hit “Continue” on my locally stored passkey, swipe my finger again and I am back in again!

In terms of user experience, that was great! Nice and easy.

Now, where are my keys?

So, how can I find the passkeys on my device? Well they aren’t in a specific app. (identical screens)

What about in my settings screen? (identical screens)

Well, “Credential Storage” doesn’t have anything to do with this type of credentials and the mysterious “Passkey linked devices” doesn’t seem to do anything at all. Maybe this is specific to my device manufacturer though…?

Turns out, it is on the “Password Manager” screen. (identical screens)

So much for our passwordless future…

How do you know which of these are passwords and which are passkeys? Only by clicking on each one to see.

Not ideal but hopefully we shouldn’t need to use this page very often.

Part 2 Creating a passkey on Windows

Firefox on Windows 11

So, now let’s move to my Windows PC. My usual browser is Firefox so let’s try and login here.

(Updated) 1Password being more clever or less clever or both?

So last time, when I hit “Continue with email” 1Password popped up with the following screens offering to let me use a passkey.

This time, that doesn’t happen which since I don’t have a passkey for Kayak on 1Password makes a lot more sense.

On the other hand, last time it gave me an opportunity to trigger the Windows passkey functionality by clicking on the teeny tiny security key icon on the screen that popped up (see if you can spot it in the Firefox screenshot above).

Now, that doesn’t happen. No popup, no teeny tiny icon, no opportunity to use passkeys (as you can see in the screenshot just below). This feels like a minor regression although it does seem to relate more to Firefox than to 1Password. (Note that in part 6, we see that this popup returns so maybe it was just a temporary bug.)

Back to Kayak on Firefox

So if I ignore 1Password, last time I got a popup asking about logging in with Google but that didn’t happen this time.

So otherwise, nothing still happens (like last time). I have a passkey for this site on my Android device but Firefox gives me no opportunity to use it.

(Updated) Chrome (different Google account) on Windows 11

What about Chrome? Note that this Chrome browser is using a different gmail account to the one where my passkeys are stored.

So previously, Chrome offered me two options. Use a passkey or use passwords saved in my Google account. Now, Chrome just offers to let me use a passkey. I don’t know for sure but I suspect that this is because I don’t have any Kayak passwords/passkeys stored in this Google account. So that seems like another UX improvement, presumably by Google.

So let’s look at “Use a passkey”. I click it and a new screen appears.

Part 3 – Using a mobile Passkey on Windows

Maybe I don’t need a new passkey after all

So I choose Android device as that is where I know I stored the passkey.

So I now get a QR code flashed up to me, I guess I just scan that with a regular QR code app from my phone? (identical screen)

So I scan the code and browse to the URI which it contains.

I guess I want my devices to remember each other so that make sense, and now my devices are connected.

So last time, I got a few other screens about different devices where passkeys could be stored but this time it goes straight to the “computer says no” screen.

So, why did that happen. Same reason as before.

Geographically embarrassed…

For whatever reason, my Kayak app on my phone is set to a region of UK but on my PC I am trying to login to the Israeli version of the site (which Kayak pushes me to automatically based on my location.)

The Passkey is attached to a particular domain and the Kayak app is smart enough to make that www.kayak.co.uk because it is set to UK region but since that domain doesn’t match what I am trying to log into now, I can’t use my existing passkey.

I now have 3 options:

1. Just enter in my email address, I’ll get a magic link and be in my app and working and passkeys be damned.
2. Go and fix my app region and create a new passkey and then try logging on my Windows PC again.
3. Option 1., but then register a passkey on my Windows PC.

Let’s try option 2 first. I also want to see whether the revocation flow has changed.

So back in the Kayak Android app I can “revoke” my current passkey. Do I need to? No idea but it seems like the sensible thing to do (identical screen).

So I revoke it and then sign-out.

I go back to login and get presented with this screen again.

That’s weird, didn’t I just revoke this passkey?

Ah, oh dear. There is a problem.

Now, fortunately since I am doing all of this at the same time, it seems obvious to me that the reason I am getting this error is that despite the fact that I revoked the credential in the Kayak app, it still exists in my Google Password Manager.

Looks like I am going to have to go and delete it manually from there. Hope I can still remember how to find it… (see above…)

Once I have done that, I am going to log back into Kayak, again using an OTP sent to my email, change the region to Israel, create a new passkey and then go back into my Google Password Manager to make sure it is the correct domain (because you don’t see the domain in the Kayak app or when you create the passkey, but you can see it in Google Password Manager).

I’m not going to show you the screenshots, just trust me.

Windows without a new passkey, second attempt

So, back to my Windows PC and to Chrome (identical screen).

I chose my phone and this there is no QR code because I previously did the automagic pairing.

I get the same Android screens as before but this time it recognises my passkey.

I hit Continue, swipe my finger, and wait for something to happen on my laptop. It doesn’t. And then I get the dreaded error.

(Updated) Just when I though it was going to go wrong…

I tried again and this time the automagic didn’t seem to want to work at all, I couldn’t even get to the “Continue” button.

I closed everything and tried a 3rd time, and this time the magic worked and it logged me in!

(Updated) Part 4 – Now I can use Android passkey on windows! Can I break this?

So it looks like the phone manufacturer fixed the bug so this flow now works which is cool.

So now I wanted to stress test this mechanism.

I switched Bluetooth on both PC and Android device.

Sure enough the automagic where the two devices have previously been connnected needs Bluetooth to be on, for both devices.

So I played with this for a bit and after I had done that, even after re-enabling Bluetooth on both devices, the automagic stopped working smoothly. I had try a few times and close and reopen things before I could make it work again. I guess this ties in with the fact that it only worked on my 3rd attempt originally.

This makes me a little nervous about if the functionality is a little too clever and a little fragile. However, QR scanning seems to be more robust and work consistently. The automagic without the QR code seems to be a usability boost but it should always be possible to fallback to the QR code mechanism.

I don’t have a faraday cage or local coworkers who could help me test out the BLE range or necessity so I leave that as an exercise to others 😀.

(Updated) Part 5 – Can I use my saved passkey directly through my Google account?

So, now I wanted to try using a Chrome profile on my Windows 11 laptop using the Google account where I have stored the passkey. (Remember that I am logged into that account on Firefox but for whatever reason I can’t directly use my stored passkeys from my Google Password Manager in Firefox).

I do that and get presented with this.

Haha, sign-in with Google is back. But I don’t want that so I close it and choose to login with an email address.

As my friend Daniel Cuthbert would say:

Now, that’s what I’m talking about!

I stored my passkey in my Google account and now Chrome on Windows is letting me use it.

Let’s give it a try.

(Updated) Google Chrome Password manager but connecting to the Android passkey

So I’m not going to show all the screenshots but use “AC2003” is letting me use the passkey from my phone and not from my Google Password Manager. Which I did and it worked. But then I wanted to actually use the Google Password Manager. So I went back to the login screen again, but now I see this:

I could not convince Chrome to go back to offering to use the passkey from Google Password Manager. I searched in a bunch of places and couldn’t find an option to do that. I did a brief Internet search but didn’t find any useful results.

Eventually I deleted the Chrome profile and recreated it. This doesn’t feel like a realistic solution for a normal case so if anyone has any idea how this is supposed to be fixed, please let me know!

(Updated) Using the passkey directly from Google Password Manager

So now I am back to the screen which is letting me use Google Password Manager for the passkey.

This brought me to this somewhat surprising screen:

I guess it makes some sense although I was pretty surprised (and now I am worried I am going to get shamed for using a pattern instead of a strong passcode on my phone 🙃.)

However, I did my screen lock and it logged me in, nice and slick. This works without any real-time connection to the Android device, no BLE or Internet or anything, It is seems to be synced into Google but protected with something phone specific (the passcode).

Now, this is a one-time operation to get your passkey on that particular device (my PC). After the first time, the passkey is stored by the PC and protected using the PC’s protection mechanism (so Windows Hello).

Which makes sense although the passkey is stored in the Google Password Manager attached to Chrome and not in the Windows passkey storage which makes sense overall but does feel a little confusing.

Look, here it is:

One minor quibble is that it shows kayak.com although if you click into it, it will more correctly show you that actually this is for il.kayak.com.

If you try and use it for https://kayak.com it won’t work. You’ll have to take my word for it but on a previous occasion when I looked, it actually said www.kayak.co.uk on the outside and il.kayak.com on the inside so it seems like there are some weird syncing oddities there.

(Updated) What is protecting these passkeys?

So I was curious about how the protection on the passkey is configured so I went back to my phone to look at the settings.

Note that here it correctly shows www.il.kayak.com.

I then go into settings and find an option about on device encryption.

This then led me to some super scary warnings about this feature might be a good thing but that it is irrevocable and that all sorts of terrible things could or would happen.

At this point, I decide that I didn’t want to dig into this all the way as it sounded like a completely different rabbit hole and I didn’t fancy testing it without a testing device and account. The documentation for this is here: https://support.google.com/accounts/answer/11350823

I still think this is a slick flow that is mostly intuitive though.

(Updated) Part 6 – Creating a Passkey on Windows

Let’s go back to option 3 for Windows which was to enter in my email address, get a magic code, get into the app and then register a passkey on my Windows PC.

Well actually, we showed that I could login on my PC using Chrome and a passkey from my Android device, can I do the same on Firefox as I still really want to use Firefox.

So, this time I open Firefox and the 1Password pop-up is back. Why didn’t it show before? I don’t know!

The tiny security key icon triggers the Windows passkey screen, I choose to use a password from my Android device, the magic happens and I am logged in, nice and easy. (Thanks to 1Password).

So I dig into a few screens and now I am offered to add a passkey.

Once again 1Password pops up, offering to store my passkey. Let’s leave that for later.

For now I click the tiny security key icon to be taken to the Windows passkey mechanism.

This pops me up a Windows security screen with a few interesting options.

Now, I have Windows Hello and a fingerprint scanner so I can save it on Windows but intriguingly I also have an option for use another device. Presumably, someone who doesn’t have Windows Hello on the their laptop would need to use this?

(Updated) Windows passkey on Android device?

I am going to try and store it on my Android device because I have no idea what that actually means or entails 🙂

For this experiment, I deleted my Android/Google Password Manager passkey from both Kayak and Google Password Manager.

I can now and try and add my new Passkey from Windows, to my mobile device.

I use the QR flow although I could probably have used the automagic flow as well and it succeeds. I can see it in my Android device’s password manager and in my Google Password Manager on Chrome:

It is still called kayak.com rather than il.kayak.com, and, even more confusingly, it is called “Firefox” in Kayak itself:

Also, a subtle difference is that when I then tried to use this passkey in Chrome from Google Password Manager, it didn’t prompt me for the device passcode but rather just showed me the regular Windows Hello prompt. I guess because the passcode was created via the Windows PC not the Android Device, although in principle it is stored on the Android Device.

The passkey also worked perfectly logging into Kayak on Android and for logging back into Firefox (via the 1Password passkey popup).

However, on my Windows PC on Firefox without 1Password installed, there is no popup and appears to be no way to login using a passkey. It looks like it needs the presence of 1Password to give it a “leg up” which is baffling. From looking at other sites, it looks like the site itself could prompt Firefox to try using a passkey but in this case it doesn’t.

Edge (release 133) seemed to work after an initial glitch.

Other than that, I guess this worked as expected but the labelling is confusing.

Windows passkey on Windows device?

I go back and revoke that passkey because I don’t want a passkey in Google Password Manager which in Kayak is called Firefox. Luckily, now that Google Password Manager synchronises, I can do that in one place and it takes affect everywhere.

Now, I go back to Kayak in Firefox where I am logged in, choose to create a passkey and select to store using fingerprint on my laptop.

That seems to have saved ok and I can see the new passkey on my list in Kayak.

I logout, go back to login with email, the 1Password pop-up appears, I click the tiny security key icon and now it shows that I can login with my passkey (identical screen).

Swipe my fingerprint on my laptop and I am golden.

Did you notice that the passkey I just created is named “Firefox”.

Can I use it on Chrome? (identical screen)

Yep, so still not a great name but interesting none the less.

Part 7 – Using a Windows passkey on an Android device?

(Updated) Trying natively

Now, is there any way to use my Windows passkey on my Android device?

I have already revoked Android passkey on Kayak and deleted it from my Google Password Manager so that we can find out.

With that done, I clear the Kayak Android app’s data to log me out and open it up on my Android device. I go to login and choose via email. It now pops up an option to use a passkey from a different device.

If I click though, it gives me a QR code which would allow me to do a cross device authentication.

However, I cannot see a way of making this work on Windows 11. If you know how to make this work, let me know.

(Updated) Trying via 1Password

I know from last time that 1Password doesn’t support passkeys on Android until Android 14 and additionally 1Password doesn’t seem to cross device authentication. Again, if you know how to make this work, let me know.

(Updated) Experimentation Summary

So what is the summary of this experiment?

• First of all, I want to reiterate once again that none of this is critical of Kayak.com. At this point, it seems like the only real UX issue that is specific to Kayak’s implementation is the naming of passkeys in Kayak’s interface.
• There has been a UX improvement around passkeys, although I still saw some unpredictable behaviour. I think it is still fair to say that different combinations of browsers and devices lead to a variety of different (and sometimes unpredictable) user journeys.
• Creating a passkey on a device (and using it on that device) is slick with some minor UX differences.
• Once you start trying to use an account on multiple devices, your experience will very much depend on your chosen ecosystem.
  • Google now seems to have a tighter and more interconnected ecosystem.
  • I believe that Apple’s is also supposed to be well integrated.
  • Microsoft/Windows seems to lag behind in terms of synchronization and also doesn’t seem to allow using passkeys stored within it for cross device authentication.
  • 1Password has good support Passkeys support across desktop browsers but on mobile it is only available for iOS 17+ and Android 14+. On Android especially users tend to lag behind the most recent versions. 1Password does not also currently seem to support cross device authentication, which might be a function of not having a “physical” presence to stand make a cross device BLE connection.
• (I said this last time but I have updated this paragraph to be clearer) Most of the talk about Passkeys assumes that you are using a biometric mechanism like face or fingerprint to use a passkey. However, all the biometric mechanisms I have seen in this process (Android, Windows Hello, 1Password unlock) will themselves fall back to some other knowledge based mechanism such as a PIN. The FIDO Alliance (the main industry body that defined the passkey standard) clearly says that passkeys may use a biometric or a device PIN so I don’t think this is necessarily surprising. However, it is worth considering when you talk about using biometrics and physically proving that the actual person did the authentication. If my device gets stolen and the thief has my passcode, the thief can use any of my passkeys stored on the device until I can remotely lock or wipe it.
• As with last time, at pretty much every stage of this experiment, I could have fallen back on to a code being sent to my email address. Without this, the user experience would have been significantly worse.

(new) So what is our current status?

Technically a dream

The technical aspects of passkeys are super cool. Purely using passkeys without supporting fallback mechanisms effectively mitigates phishing and requires no remembered secrets.

The ecosystem is improving but is still a challenge

Since I looked at this ~9 months ago, the ecosystem has definitely improved. If you are using end-to-end Apple devices or you have your Google account signed in everywhere, then you are probably okay. Similarly, if you are logged into your Google account on your Android phone or you are using an iPhone, and you have Bluetooth available to make a cross device authentication flow work then you may also find smooth operations.

However, it seems like right now if you store your passkey into the wrong account or you store it on Windows then you may find those passkeys are not going to follow you around.

The exception becomes the rule

We will often see fallback options, where a particular security option is not possible.

In the case of passkeys, the fallback option tends to be a magic link sent to email or a code sent to email, and as soon as you introduce any complexity at all then the fallback option almost becomes the norm. The ecosystem complexity means that in order to make sure your app is usable cross-platform, or by devices which don’t support passkeys, you are pretty much forced to make fallback options a first-class citizen.

Kayak falls back to an email code or link as soon as something does not go smoothly with the passkeys flow. https://www.passkeys.io/ is entirely usable without passkeys, just email codes. https://passkeys.eu is entirely usable without passcodes, just email codes.

Now you might say, well I could use any app with standard authentication with just an email code if I activate the forgot password process. But there are two problems with that. Firstly, forgot password would (or should) be considered a non-standard login and cause noise, in this case the code/link login seems to be considered like any other login. Secondly, with standard authentication, if MFA is enabled then the forgot password process should not work just from an email link anyway.

Another fallback example I mentioned above was that on my Android phone I could use my phone pattern instead of a biometric so that eliminates the physical “biological” proof of presence and instead relies on the complexity of your pattern or your your PIN or whatever.

What does this mean for security

Well, basically this means that you are only as secure as your weakest fallback option. Passkeys don’t mean anything if the user’s email is compromised and that is the fallback option. Biometrics don’t mean anything if the fallback is using the phone’s PIN.

Passkeys are super secure but the current authentication flows using passkeys, not much more so than classic authentication flows. For example, the phishing resistance will also fail if a fallback can be used.

But the user experience is great, right?

In a simple scenario, the user experience is fabulous. Really simple flows and super easy to log in.

Even in complex scenarios, the user experience has significantly improved and works a lot more smoothly.

However, user experience is also a function of recovery flows or fallback flows and if you are too strict about enforcing pass keys, the necessary recovery flows are going to wreck user experience and possibly put a lot of strain on your user support function.

If you just see passkeys as a user experience improvement whilst also allowing flexible recovery flows then that will probably work out well for your, but you need to sure that this doesn’t damage your overall security level by slipping to fall back authentication too easily.

How much effort it all of this for developers?

Well, you could bring pay a 3rd party service to do this for you, but do you really want another 3rd party service? Odds are you are already using a 3rd party service for your authentication mechanism, maybe they support it?

I have a client using Google Identity Platform (which appears to be a souped-up version of Firebase Authentication). Now, Google have been major advocates for passkeys so I assumed that Google Identity natively supporting it would be a no-brainer.

Somewhere I found a support ticket explaining that this was not yet supported but I can’t find it now, probably because they are embarrassed, as well they should be.

So anyway, if your 3rd party provider supports it then maybe it is easier. If not, then there are going to be a lot of flows, edge-cases and management screens and functionality that your developers are suddenly going to have to deal with.

Discovering Google Identity Platform didn’t support it put the final nail in the coffin for me and this particular client, there was no way I was going to suggest my client to get bogged down in this or buy another 3rd party. 9 months on there is no real sign of this being implemented any time soon.

(Updated) In conclusion

My previous conclusion was that this is a really cool piece of tech but until the ecosystem gets itself together, it is going to be hard to justify the return on development investment.

I think the ecosystem has improved but there are certainly edge cases remaining where fallback options are going to be necessary.

The more I think about it, the more I think that the primary value proposition is user experience rather than security. To operate as an effective security improvement, I think there are several other considerations:

1. It will be necessarily to combine passkey implementation with a carefully thought out set of risk-based recovery flows. When I wrote the original article I had not seen much discussion of that, nor have I since then. I saw this blogpost which is a little salesy and disorganized but I think captures the point that there are pros and cons to different recovery mechanisms and that some form of adaptive recovery may be necessary.

   Whilst carefully thought out recovery flows would be good for passwords as well, I think it is more important with passkeys where there is a higher likelihood of the passkey being unavailable or losing it all together since it is less easily transferable and also a less familiar mechanism than a password. This would then potentially mean more use of recovery flows.

2. There seems to be a debate about whether passkeys on their own can be considered multi-factor authentication since they are not tied to a particular device and they do not absolutely require biometrics (see below). If passkeys are considered a single factor then another factor is still required.
3. There is also the fact that so much of the security around passkeys falls back on the security of the ecosystem where the passkey is stored. Again, this is a problem shared with passwords but has to be taken into account when trying to demonstrate the overall security uplift.

In my day job I work with developers to provide advice on building features securely and building security features. From what I have seen so far, the engineering effort for an application developer to implement something like this is not trivial, especially considering the recovery flows. This means a high cost to implement or alternatively paying the cost of using a 3rd party service/authentication provider to handle passkeys. Whilst the user experience improvement might help, I am not convinced that the security uplift alone justifies the cost at this point and I’d currently be hesitant to push this as a priority.

(new) Looking to the future

I think the usability aspect of passkeys is possibly the most compelling argument for using them, especially for apps which are looking for minimal user friction. Easy fallback means that the ecosystem aspects matter less for this.

For the largest app platforms who handle their own authentication (GitHub, Amazon, etc), it seems like they have the scale and the expertise to make implementing passkeys themselves worthwhile.

For any app which would consider Social Login (e.g. via your Google or Facebook account) as a viable authentication mechanism, I think it is hard to argue that implementing passkeys themselves will provide a security uplift.

For apps where social login isn’t appropriate, I think we are most likely to see apps adopt passkeys if they get it as a feature from their 3rd party authentication provider such as Auth0 or Descope.

Otherwise, I am not convinced at this point we will see widespread examples of other organizations implementing this themselves.