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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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 optimised 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.