Passkeys have taken the online security world by storm since their inception in mid-2022, even if the underlying technology can technically be traced back to FIDO2 and its breakthrough onto the world stage in 2018. Popularity has no doubt exploded due to their widespread adoption by the world’s largest tech companies – who also happen to be the most used identity providers collectively – as millions of users begin to make the shift.
They are seemingly heading towards becoming the new de facto standard of secure authentication for both apps and websites alike. This is a massive leap forward for account security considering the underlying fundamentals are grounded in cryptography, which makes them extremely resilient to hackers and represents an approach that is magnitudes more secure than the traditional password.
Although the distinction between passkey and FIDO2 credentials is extremely subtle, and many will often use the terms interchangeably, it should be clarified that passkey can refer to both classic FIDO2 credentials that are strictly device-bound (such as with hardware security keys) or syncable credentials that reside across multiple devices, generally via a cloud service or identity provider.
But regardless of whether or not they are device-bound or syncable, passkeys are still a relatively new concept, and many software developers and security experts are scrambling to understand how to best integrate them into existing services and products (especially for those transitioning from password-based implementations). The nuances and best practices that lead to an optimised flow within a robust passkey implementation are still being fine tuned, and the most seamless UX possible may not yet be fully realised.
While the passkey landscape is nebulous and still evolving, the aim of this post is to highlight a few staple considerations to get the most out of any consumer-facing passkey implementation and guide towards winning ideas – some of which may even be applicable for enterprise use although that is not the intended audience.
- Give the user more authentication options, not less
As more and more implementations come online, it is equal parts interesting and perplexing, to see relying parties (or RPs for short) purposely limit the options users are afforded when choosing their passkey. For example, some relying parties will only permit the use of a platform authenticator, i.e. an authenticator which is physically integrated into a smart device, laptop or desktop computer. Others will only allow users to register a passkey originating from a particular type of device, or even worse, only when using a specific operating system.
These limitations really miss the whole point of passkeys being an open standard accessible by everyone. For example, not all users are on iOS, and some will occasionally login using their desktop and not just from their smartphone. Another group of users will prefer to use a roaming authenticator such as a hardware security key, to enable and manage their authentication. Users will always understand their own specific risks best, and giving them an easy to understand menu of options will more likely lead to the best level of protection.
Unless there is a very specific and valid reason for providing users fewer passkey options, it is best to enable the entire gamut and then empower users to take control of their own authentication. This will encourage wider passkey use as a means to replacing passwords due to usability, whilst enhancing account security.
- Consider how users can recover from the loss of an authenticator
When designing systems that incorporate passkey support, it is crucial to consider the one UX feature that really differentiates passkeys from traditional passwords. Unlike passwords, many passkeys cannot be copied or retrieved. Even within the set of cases where copies might exist, such as with syncable passkeys on the Apple iCloud keychain, there is a possibility that they will not be recoverable in the future due to users losing access to a cloud service or storage provider. For the case of device-bound passkeys in which the passkey is never copied off the device it was created on, a physical device may be simply lost or reset. Either of the two scenarios – losing a physical security key or encountering cloud-related issues – will obviously lead to unavailability of the passkey, resulting in frustration, loss of time and most likely, additional technical support.
Clearly indicating which passkeys were created as synced or are backup eligible during registration within the user interface will help inform good decisions concerning the availability of passkeys and alleviate some of the recovery issues from the get go. Further, always providing the option to create or modify passkey labels during and after creation will help users determine which one is the primary, which are indeed backups, and perhaps more importantly, which authenticators have been used.
Ultimately, incorporating support for multiple passkeys is essential. A bare minimum of two passkeys is imperative – a primary passkey for regular use and an all important backup for recovery and safekeeping. Allowing additional passkeys to be registered will make logon more convenient, especially if a user has multiple trusted devices.
It’s also important to allow users to delete these passkeys individually, in case a device is lost, or a synced passkey is shared inadvertently. This approach, combined with robust self-recovery and self-registration mechanisms, ensures users can maintain access to their accounts even when facing the loss of access to an authenticator, whilst simultaneously reducing friction and technical support overhead.
- Do not force the use of discoverable credentials
The term discoverable credential (formerly known as a resident key) refers to the ability of an RP to invoke a stored credential on an authenticator without the user having to specify a username. Conceptually, this facilitates an ideal passwordless user journey that really showcases the convenience and elegance of passkeys as an authentication mechanism.
The question then, if discoverable credentials present themselves as the purest form of passwordless but secure authentication currently available, why not implement it everywhere possible? There are actually a few valid reasons why they may not always be optimal or even necessary.
The most obvious drawback is related to privacy, especially if users are conscious about having their online movements revealed. Discoverable credentials may allow other actors – perhaps another person who has physical access to the authenticator and the PIN – to list and identify all discoverable credentials stored onboard an authenticator. This information could theoretically be used to track a user’s activity, and may therefore be more suited to personal or low-privacy websites or applications. Although it may only reflect a small percentage of the population, a simple example could be a journalist or activist at a border crossing where border agents have compelled said person to disclose their PIN purely to extricate and scrutinise information that should otherwise be secret.
Another reason is potentially limited secure storage capacity on the presented authenticator. For example, hardware security keys can store up to a certain amount of passkeys, and other devices may have similar limits based on the secure memory available. As passkey support for consumer services grows over time, storage limits will likely be reached. This, in turn, will force any new discoverable credential workflows to require the user to nominate a different device or remove an existing credential – neither of which is especially desirable and will lead to a poor UX.
Furthermore, different browsers can exhibit divergent behaviour when storage limits are reached, making it harder for developers to guide the user towards resolving the issue. For example, one browser may create non-discoverable credentials instead (without user notification), potentially causing confusion when users attempt to authenticate in the future. Another, on the other hand, may not even attempt to create a non-discoverable credential when the authenticator is at capacity, and will simply prevent the user from proceeding without providing a clear error message. It is difficult for browser developers to collaborate on every feature, and error handling is certainly no different, especially since the optimal flows aren’t yet standardised.
In some other cases still, the user may be presenting a FIDO2 authenticator that may not even support discoverable credentials, and is thus unable to comply if this flow is mandatory, leading to an abrupt end to the user journey.
It is therefore paramount to always provide alternate paths for users to initiate a passkey login – one via username and another affording the use of discoverable credentials. By setting discoverable credentials to “preferred” and not “required,” it allows a graceful fallback for both users and authenticators that may have a perfectly good reason to not pursue a discoverable credential route.
- Try to detect the level of passkey support from the browser or platform
Ideally, both the client and RP should attempt to detect whether or not the browser, platform and even authenticator support passkeys and a subset of its features, before specific user interface elements are displayed, and the logon flow altered to accommodate the result. In practice, however, this is problematic due to the difficulty in obtaining the required information.
While overall support for passkeys can generally be inferred from support for WebAuthn – more specifically, the creation and use of public key credentials – there are unfortunately, no reliable ways to determine complete end-to-end support encompassing authenticators and options such as credential management, user verification and the aforementioned discoverable credentials. As a starting point however, this code snippet could be used to at least detect WebAuthn support in the browser.
Of the very few methods that do exist to gather meaningful information, it is still important to acknowledge their unreliability, especially when used in isolation. User agent fingerprinting for instance, offers a relative degree of accuracy, but demands active maintenance of internal compatibility lists, which can lead to issues when browsers update their features. User agents can also be modified by the user or browser intentionally, which may ultimately limit the usefulness of user agent strings for determining passkey support.
But even with this information, an RP can only hope to discover the most likely browser or platform being used, and process the information as best as possible, since detecting specific passkey support across all browsers and platforms remains a challenge. Detecting support from an authenticator is next to impossible, since they are more or less a black box from the point of view of the RP.
The point is, despite the high degree of difficulty in gathering passkey support information through whichever combination of means is at the RP’s disposal during both the registration and authentication ceremonies, it can provide valuable information that can then be used by the RP to present relevant and informed passkey options to the user based on what their platform, browser and potentially authenticator supports, so it is certainly worth trying.
- Exercise caution when mandating any optional extensions or features
It’s important to understand that despite what arguments are passed during passkey registration and authentication, the end result doesn’t always equate to a credential that was created or asserted with the desired settings. It only means that a platform will try and perform an action on an authenticator with those settings. Thus, mandating a rigid flow or limiting services to only certain types of authenticators is likely not ideal when offering passkeys to users bringing their own devices, but is certainly a tool that may enable the alignment of your risk tolerance to certain authenticators that have been internally vetted or tested.
If compliance and risk are key concerns, attestation is the only way to achieve high confidence in determining what type of authenticator is being presented by the user, and ultimately the type of passkey created. For services that want to provide comprehensive information to users about their passkey, or need to be able to use information about the passkey to make risk-based decisions, it is advised to request attestation information during registration. It should be noted that only device-bound passkeys can provide meaningful attestation, and users do always have the option of declining to supply the attestation information should they not want to expose this.
The best way to determine how a credential has been created or used ultimately, is to evaluate the signals returned as part of the process, compare that with baseline requirements, and finally, inform the end user of the implications of the way their authenticator has actually processed the request. There is certainly room for any implementation to include discretionary functionality based on one of the many optional extensions or features under FIDO2, but never mandate its use until it has been universally adopted and verified or if you are willing to provide specific devices that support said feature to your users.
Be mindful that passkeys and their features are still evolving, which means that implementations need to remain agile, ready to incorporate changes, and above all, be flexible enough to afford user’s agency in any authentication decision. Empower users to take ownership of their digital identity and authentication, and not simply accept a given process due to a lack of alternate choices.
Preparing for a passkey future
In a world of increasing cybersecurity threats, passkeys have emerged as a promising authentication method leveraging FIDO as a foundation. However, supporting passkeys and detecting their compatibility across the entire gamut of browsers, platforms and authenticators remain complex tasks. But by supporting multiple passkeys per account, coupled with a well thought out UX based on real information and optionality, ensures user access even in spite of some of the most challenging scenarios.
While the road ahead for passkeys might be intricate, the importance of maintaining a proactive approach cannot be underestimated. Balancing user convenience against security will undoubtedly pave the way for more seamless online authentication experiences in the future, as the standards evolve and a more optimized approach is unlocked. Adapting authentication methods because of the ever-changing landscape remains a continuous endeavor, which means no implementation should remain static for too long.
For more information regarding this specific topic and even an in-depth look at passkey implementations in general, please head on over to Yubico’s Best Practices page. As passkeys evolve, so too will the information be updated and even additional resources and guidance added around passkey usage over time. Yubico also offers some other passkey resources, such as latest passkey eBooks here and here centered around enterprise usage.
