In our previous articles, we talked about what passkeys are and how to incorporate them into a new or existing web application. However, a successful adoption of passkeys requires considering the larger product to ensure a smooth user experience as well as a secure design. 

‍

In this article, we’ll address the following questions that product owners need to consider. This will inform the user experience design and strategic approach: 

‍

• What will passkeys be used for– and what’s the risk profile?
  ‍
• How many of your customers have appropriate passkey capability? 
  ‍
• How will you ensure you create credentials for the right users? 
  ‍
• What is the recovery strategy (or, what happens when someone’s credentials don’t work for some reason)?
  
      · Will you fully retire passwords, and if so, when? 

How are you using passkeys – and what are the related risks?

Passkeys are an authentication mechanism, and we addressed earlier how they are generally less risky than passwords. By less risky, I mean specifically that it is much easier to steal someone else’s username and password to be used for authentication, and much more difficult to access someone’s private passkey to fraudulently authenticate. In fact, passkeys were initially very attractive to financial institutions and other organizations where stolen credentials were very risky: if a passkey can’t leave a device, it’s almost impossible for a malicious actor to steal the passkey and use it to authenticate– therefore it’s much harder for someone to, say, log on and drain your bank account. But that’s only device-bound passkeys. Passkeys stored in a password manager (for example, Apple’s passkey implementation stores credentials in the iCloud keychain) are easier to steal. If a malicious actor can get into your iCloud account (and therefore your keychain), they can access your passkeys, and any accounts those passkeys protect. 

‍

To be clear: passkeys are more secure and less risky than passwords, full stop. However, as an organization, you may want to treat device-bound passkeys (those that are stored on the physical device and never copied elsewhere) differently than synced passkeys (those that are stored in a password manager and shared across devices). Prove has designed our passkey solution to support you in this differentiation. 

‍

Since you have a choice about how passkeys are created and stored, if your product is something that is less risky, you may choose to allow passkeys that can be synced and not biometric protected, because that will offer a better user experience. On the other hand, for financial-related products, you may want to require passkeys to be created on device-bound passkeys protected with biometrics for a lower risk of compromise. 

‍

Fun fact: Prove’s passkey implementation is designed to handle the distinction between device-bound and synced passkeys– even if a user’s platform creates synced passkeys, we can detect if the user is authenticating from a device we’ve seen before– and therefore we can trust more.
‍

How many of your users have passkey capability? 

An important aspect of adopting a new technology is understanding your customer base and what technology they have access to. The wonderful thing about passkeys is that it is a standard built into web browsers, so if your customers have access to a modern web browser, they likely can use passkeys. However, what’s less clear is if your customer’s passkeys are device-bound or not; or if they can be protected by a biometric (Face/Touch scan) as opposed to a PIN. If your user base has access to the newest technologies, your passkey adoption strategy can move faster. In any case, you need to scaffold your passkey adoption strategy with passwords, as there are still many users who will need time to adapt, but by encouraging passkey adoption you reduce the attack surface in the meantime. 

‍

Non-mobile devices such as laptops or other computers may have more variability in terms of which authenticators are connected, as well as if they are protected by biometrics. More mobile devices have the hardware and software capabilities to support passkeys. If that is a significant issue for your user base, one thing to keep in mind is that passkeys on mobile phones can be used to authenticate on other devices. Prove has built this into our passkey solution as well.
‍

How will you ensure that you create a passkey for the right person? 

One thing is clear: once passkeys are created, they provide a secure authentication mechanism, far more so than passwords. If you’re building a product from scratch, using passkeys will be easy. Users creating new accounts will create passkeys instead of passwords. However, if you have an existing user base currently using passwords, they will have to go through a process of creating new passkeys. This generally looks like asking the user to create a passkey after they log in with a password (or your trusted authentication flow) that gets attached to the account as an alternate way to log in. 

‍

Prove’s authentication capability can help ensure that passkeys are created for the right person, rather than by someone who has stolen a username and password.
‍

What’s the recovery strategy? 

Even though passkeys are managed by computers on devices that customers tend to not lose, users can lose access to their passkeys. Remember, passkeys can live either on a single device (“Device bound passkey”) or can be shared across devices via a password manager. The risk with device-bound passkeys is easily imagined: perhaps someone loses their device, whether it’s their Yubikey, phone, or laptop; or maybe they get a new device. But it could also be that the device is stolen, and in that case, the path to reset access to someone’s account might be a little different. 

‍

One thing that will help is to try to keep track of where the private passkey lives for the user. For example, when credentials are created, have the user provide a useful description that you can attach to the public passkey (that you store). For example, if you store passkeys with a description such as “Passkey created on my iPhone 14”, the user knows that they can use a passkey stored on that device (or, really, in the iCloud account associated with that device) to authenticate on their account. Also, if they lose a device associated with that iCloud account, the user can revoke those credentials– then a malicious actor can’t access the account from a stolen device. 

‍

The original approach to protecting access to an account via passkeys has been to encourage the user to create multiple sets of credentials on different devices. For example, I might create one set of credentials on my personal laptop, my work laptop, and my phone. Then, if I lose access to one of them for some reason, I have a backup. While that might work for people with access to all these different devices, it’s a big lift to create multiple credentials for all my accounts on all these devices and keep them up to date. 

‍

The recovery strategy helps establish new passkeys for existing users. Identity verification can be leveraged to have confidence that the user is who they say they are. Prove’s identity verification can help ensure that passkeys are created for the right person and on the right phone. We also can help manage the trustworthy movement of credentials to new devices.
‍

Conclusion

As you can see, one of the trickiest things about adopting passkeys is the decision-making about strategic adoption and user experience. There can be lots of “gotchas,” especially as we are starting to transition from our default familiarity with password-based systems to new, more secure passkeys. However, you can feel confident that Prove is an expert in this space. We’ve built consideration for all of these challenges into our passkey product.

‍
Reach out to your Prove representative for us to help you develop your passkey implementation plan.