• Analysis of PSD2 & SCA Requirements
• What SCA Requirements Mean for Passkeys
• PSD3 / PSR Implications for Passkeys

In our prior passkeys PSD2 blog post, we discussed how passkeys are already in use by Fintechs like Revolut and Finom and how they improve the digital security of banking. Passkeys, with their inherent non-phishability, represent a major advancement in authentication technologies, offering a new method for implementing multi-factor authentication (MFA) in Strong Customer Authentication (SCA).

With this series of four blog posts, we want to analyze in depth how the different types of passkeys (device-bound vs. synced) comply with SCA & PSD2 requirements.

This first part of the series is all about understand the difference between device-bound and synced passkeys.

The second part explains what PSD2 and Strong Customer Authentication (SCA) means in an understandable way, also by laying out the historical development of it.

The third part of the series shows how the different types of passkeys comply with SCA and what this means for banks, fintechs and financial institutions who think of adopting passkeys.

The fourth and final part of the series concludes what PSD3 / PSR will mean for SCA and passkeys in the future.

Following the publication of our last blog post, we received a lot of follow-up questions regarding our stance on passkeys, specifically in relation to SCA under the PSD2 framework. There's a clear interest in understanding not just the application of passkeys, but also how they align with the Regulatory Technical Standards (RTS). Additionally, stakeholders are curious about the potential interpretations and guidance from regulators, including the European Banking Authority (EBA), on the use of passkeys.

Recognizing this, we aim to delve deeper into how passkeys can be integrated within the PSD2 directive, the RTS on SCA and providing clarity on our position into the use of this technology. We will also explore existing EBA questions and answers to shed light on how regulators and the EBA might perceive passkeys. This examination will not only address the distinctions between synced and device-bound passkeys but also their practical applications in enhancing both security and user experience.

By understanding the nuances, stakeholders can make informed decisions that not only comply with the stringent requirements of PSD2 but also leverage the latest authentication technology to secure digital transactions. Our discussion aims to further illuminate the path for integrating passkeys into authentication processes, ensuring that security measures keep pace with the evolving digital landscape.

Of course, every regulated entity that falls under PSD2 needs to make its own decisions on how to fulfill the regulatory targets, as every implementation has its own complexities. This individual approach acknowledges that while the regulatory framework provides a uniform standard, the practical application of these standards will vary significantly across different organizations due to their unique operational environments, technological capabilities, and user bases.

Thus, while our insights aim to guide and inform, they are not prescriptive. Each entity must consider its specific circumstances and challenges in integrating passkeys into their security and authentication protocols.

In order to understand the differentiation between device-bound and synced passkeys we will shortly explore how the ecosystem developed.

We start by looking at the history and evolvement of device-bound passkeys before taking a deeper look at their technical details.

Historically, authentication mechanisms within WebAuthn (the Standard underlying passkeys) were tightly coupled to physical devices: security keys (e.g. YubiKeys). Before the widespread adoption of passkeys, FIDO2 credentials bound to a single authenticator represented the gold standard in security. These credentials are linked to the device they reside on. The implication of this binding was significant: the credential could not be transferred or utilized beyond its original hardware.

This approach, while enhancing security by localizing the authentication process to a single device, inevitably encountered practical limitations that affected its widespread adoption, especially among general non-technical consumers. Users were forced to have their authenticating device available for every login attempt which not only constrained user mobility but also raised concerns in scenarios where the device was lost, damaged, or not immediately accessible.

Furthermore, there was also reluctance of consumers to invest in additional hardware. Historically, the ownership and usage of dedicated security keys has been very low among general consumers. The prospect of purchasing specialized hardware for authentication purposes, despite its enhanced security benefits, did not resonate well with the majority of B2C users, which at the same time are usually the target of broad phishing campaigns or credential stuffing attacks.

Device-bound passkeys are characterized by their specific categorization into discoverable and non-discoverable credentials, a distinction primarily defining their discoverability. But the key factor that distinguishes device-bound keys is encapsulated in the WebAuthn credential properties, particularly through the isBackupEligible and isBackupSynchronized flags. For device-bound passkeys, both of these fields are set to zero, indicating that the credentials are not eligible for backup or synchronization across devices. These characteristics underscores their intrinsic link to the physical device on which they were created, ensuring that the credential remains tied to and usable solely on that specific piece of hardware.

A notable example of device-bound credentials in practice is observed within the Windows ecosystem. To this date, both Windows 10 and Windows 11 operate with device-bound passkeys, as Microsoft has not yet implemented synced passkeys for Windows Hello credentials. This means that users leveraging Windows Hello for authentication are working with device-bound passkeys, which, by their very nature, cannot be transferred or synced to another device.

On the other hand, Google has articulated a clear stance regarding non-discoverable passkeys, indicating that existing non-discoverable passkeys will can remain non-synchronized in future implementations. This decision aligns with the broader principle that non-discoverable credentials play a crucial role in certain security contexts by remaining strictly device-bound and are not discoverable therefore cannot be used as passkeys.

Contrastingly, the approach taken by Apple with macOS and iOS differs significantly. Unlike the fixed, device-bound strategy observed with Windows and Google's non-discoverable keys, Apple's ecosystem is much stronger leaning into only allowing synced passkeys especially on iOS therefore making it impossible to create device-bound passkey via WebAuthn.

This segmentation of strategies across major platforms illustrates the diverse approaches to managing WebAuthn credentials, particularly when considering the balance between security, convenience, and user accessibility. While device-bound passkeys offer a high level of security by ensuring that credentials cannot be moved or misused outside of their intended device, the industry continues to evolve, seeking solutions that maintain security standards without compromising on user experience and mobility.

Also here, we take a look at the historical development of synced passkeys before analyzing the technical details.

Following the publication of the WebAuthn Level 2 and CTAP 2.1 specifications around mid to end of 2021, the WebAuthn working group launched a significant industry initiative aimed at overcoming the primary obstacles impeding the WebAuthn standard's ability to replace passwords and increase adoption. This initiative focused on two critical areas: eliminating the requirement for additional hardware security devices and mitigating the risk associated with losing the authenticator while keeping full backward compatibility with the existing standards.

The first challenge – eradicating the need for new hardware – was addressed through the utilization of built-in platform authenticators found in modern consumer devices (e.g. Touch ID, Face ID, Windows Hello).

Modern devices are increasingly outfitted with specialized security modules, such as the Trusted Execution Environment (TEE) on Android, Secure Enclave on iOS and macOS, and Trusted Platform Module (TPM) on Windows devices. These integral security keystores serve as a robust foundation for passkeys, effectively functioning as built-in "security keys." This approach allows for the widespread adoption of public key cryptography, a level of security previously attainable only through external hardware security keys (e.g. YubiKeys), and largely restricted to tech-savvy individuals or organizations within highly regulated industries.

By harnessing the capabilities of the TEE, Secure Enclave, or TPM, the WebAuthn protocols are empowered to provide strong, cryptographic user authentication mechanisms. Now, sophisticated authentication methods are made user-friendly and accessible to the general public, without the need for additional, specialized hardware.

This evolution is a very strong improvement in the approach to digital security, emphasizing the critical role that user-centric security solutions play in driving widespread adoption. By using security features of contemporary devices, the industry effort successfully addressed the initial hurdle of removing the necessity for external hardware.

This development was a crucial step in a new era of the digital authentication ecosystem, where the broad application of public key cryptography becomes directly applicable to a wide range of use cases and at the same time simplifies authentication for users.

In order to address the risk associated with losing the mobile phone and, by extension, the passkeys stored on it, the industry initiative focused on enabling the synchronization of discoverable credentials to the cloud. This approach effectively transformed credentials from being strictly device-bound to being multi-device and, more accurately, bound to the user's account with their cloud provider, such as iCloud for Apple devices or Google for Android devices.

This practical solution meant that even if a user's phone was lost or replaced, the credentials previously established wouldn't be permanently lost. Instead, these credentials could be retrieved from the user's cloud account and synced to a new device. This shift significantly reduced the inconvenience and security risks previously associated with the loss of a physical authenticator.

By leveraging cloud synchronization, passkeys could now seamlessly transition between a user's devices, maintaining their integrity and security regardless of the specific device in use. For example, when a user logs into a website from a new device, the credentials available in their cloud account could be auto-suggested for authentication. If necessary, these credentials could be transmitted to the new device, maintaining a consistent and secure authentication experience across different platforms and devices.

This transition to cloud-synced, account-bound credentials represents a pragmatic approach to digital security. It acknowledges the realities of modern device usage and the common occurrence of device exchanges, whether through loss, damage, or upgrades. By binding credentials to the user's cloud account – be it with Apple's iCloud or Google's cloud services – the solution not only mitigates the risk associated with losing a device but also enhances the user's ability to manage and recover their digital identity across multiple devices.

This development effectively broadens the applicability of WebAuthn's strong, cryptographic authentication mechanisms, making them more adaptable to real-world user scenarios. It also ensures that strong authentication is accessible and manageable, not just for those with a technical background or those in highly regulated industries but for the average user navigating the digital world with multiple devices.

Synced passkeys are also known as discoverable credentials or resident keys. These are distinguished from device-bound keys by two critical properties: isBackupEligible and isBackedUp have different values. For synced passkeys, the isBackupEligible flag is set to 1, indicating that these credentials are eligible for backup. Upon successful synchronization to the cloud, the `isBackedUp` flag is also set to 1, confirming that the credential has been properly synced. It's important to note that the status of synchronization can change over time, reflecting the dynamic nature of device usage and management.

When platforms request resident keys, by setting the “requireResidentKey” parameter to required or preferred, platforms that support cloud services automatically create synced passkeys. This process ensures that users can rely on their credentials being accessible across their various devices. However, as previously mentioned, this is not the case with Windows environments unless a third-party password manager(e.g. Dashlane, KeePassXC, 1Password) with passkey management capabilities is available. In such scenarios, the handling of the isBackupEligible and isBackedUp flags falls under the domain of the password manager's governance and is set to 1.

Furthermore, while it is currently still possible to identify the specific authenticator where the passkey has been stored, the absence of attestation for the majority of these credentials means their origin cannot be cryptographically verified. This aspect highlights a potential limitation in guaranteeing the security pedigree of synced passkeys solely through WebAuthn's standard mechanisms.

This development in synced passkeys essentially broadens the scope of discoverable credentials by integrating them into a cloud-based synchronization framework. By making these keys backup-eligible and ensuring their synchronization across a user's devices, WebAuthn addresses two of the main challenges in digital authentication: the risk of losing access due to lost devices and the inconvenience of managing multiple device-bound credentials.

The transition from device-bound to synced passkeys started a critical dialogue within WebAuthn working group, centering around the necessity for advanced security measures, the legal questions involved, and a compromise that was both consumer-friendly and secure.

The adoption of synced passkeys was celebrated for its promise to enhance user convenience and security through features like cloud synchronization and seamless multi-device functionality. However, it introduced some discomfort among some relying parties (RPs), especially regarding the implications for security and compliance in environments with elevated requirements. The essence of the debate was the requirement for a mechanism that ensured even synced passkeys retained a connection to specific devices, a concept crucial for relying parties dealing with sensitive transactions or operating under stringent regulatory standards.

For RPs unable or unwilling to adopt passkeys, the absence of a reliable method to bind these credentials to specific devices in critical applications posed a significant challenge. Such a mechanism was considered very important by some RPs. The lack of this device-binding capability, an expectation that was perhaps not explicitly stated but was certainly expected, represented a serious surprise and a breach of trust from their perspective.

The discussion concluded that there should be a harmonization of interests, but at first the greater good of spreading passkeys should take precedence. In the discussion the devicePubKey extension was seen as one way to address those concerns, but later was replaced with supplementalPubKeys that take a much broader approach into the current WebAuthn Level 3 draft. Unfortunately this approach was also discontinued in August of 2024.

Let’s analyze how the compromise with the supplementalPubKeys extension was formed and what this means technically.

The discussion surrounding the transition from the devicePubKey extension to the supplementalPubKeys extension highlights the dynamic nature of the WebAuthn specification. Initially, devicePubKey served to enhance security through device-bound public keys, but it was later replaced by the suggestion of supplementalPubKeys in the WebAuthn Level 3 Editor's Working Draft. This newer extension offers a more comprehensive solution by allowing for multiple keys to enhance authentication processes.

The core of the debate focused on balancing enhanced security measures with the broader adoption and practical utility of passkeys across different devices and platforms. The supplementalPubKeys extension represents a combination of these priorities, enabling stricter authentication. For example, it accommodates regulations requiring certain authentication standards by allowing additional “sub-keys” with attestation statements. These keys can signal compliance with authentication requirements, potentially reducing the need for additional sign-in challenges under certain conditions (even with passkeys).

An example directly from the WebAuthn draft:

“Say that a sign-in request appears at a website along with some geolocation signal that has not been seen for this user account before, and is outside of the typical usage hours observed for the account. The risk may be deemed high enough not to allow the request, even with an assertion by a multi-device credential on its own. But if a signature from a supplemental key that is device-bound, and that is well established for this user can also be presented, then that may tip the balance.”

During the discussion it was highlighted that these were only meant for RPs with extremely high requirements for security (e.g. in the government context).

By incorporating feedback and addressing specific use cases – also including regulated financial transactions and the need for device-bound signals in a multi-device credential environment – the WebAuthn community aimed to address both security and interoperability concerns. The supplementalPubKeys extension thus is an approach that seeks to provide robust security features while also supporting the seamless user experience and broad compatibility essential for the widespread adoption of passkeys. It is a completely optional extension that does not interfere with the passkey implementation that has already been seen the last 2 years.

This evolution towards a more inclusive and flexible framework underlines the WebAuthn community's commitment to improving web authentication methods even to stricter use cases.

The supplementalPubKeys extension introduced in WebAuthn allows for the use of additional keypairs alongside the primary credential.

Taken from the original GitHub issue

The image shows the concept of supplementalPubKey taken from the original GitHub issue (pk = passkey, pspk=provider supplemental key, dspk = device supplemental key).

Here's a breakdown of how it works and its intended use:

Purpose and Functionality of supplementalPubKey

• One central passkey credential remains: It is important to keep in mind that only one central passkey remains the primary method of user authentication, and the additional keys provide extra layers of security and assurance. This structure maintains the simplicity and efficiency of using a single, core passkey for authentication across multiple devices, ensuring a seamless user experience. The supplemental keys, meanwhile, serve to enhance the authentication context, offering the Relying Party (RP) additional signals about the security environment or compliance with specific authentication standards. These supplemental keys are not standalone authentication methods but rather augment the primary passkey, reinforcing its trustworthiness with evidence of device integrity
• Device-Bound Keys: These are tied specifically to one device. They can provide assurances that an authentication request is coming from a trusted device that has previously been authenticated. They will not be synched under any circumstance.
• Provider-Bound Keys: These keys have a "provider" scope, which means they can offer additional assurances based on the authentication provider's policies or the specific attestation of the provider. For example, a provider might only issue such a key after a user has completed a higher level of authentication (like 2FA).
• Multiple Public Keys: Unlike its predecessor, the devicePubKey extension, which allowed for only a one device-bound public key, supplementalPubKeys enables the inclusion of one or two supplemental key types. These keys can serve different purposes and scopes – namely, device-bound and provider-bound scopes.

Use Cases and Examples of supplementalPubKey

1. Enhanced Security: In situations where a website (relying party) must adhere to certain enhanced security standards for authentication, supplemental keys can be used to meet these requirements. If this supplemental key has been seen and verified by the site before, it could allow the user to bypass additional sign-in challenges as the device continuity can be confirmed by prior signals.
2. Risk Management: For sign-in requests that appear risky (e.g., coming from a new geolocation or at unusual hours), the presence of a device-bound supplemental key that has a history of use with the user's account could reduce the perceived risk and allow the request to proceed where it might otherwise have been blocked.

Technical Aspects of supplementalPubKey

• No Own Credential ID: Supplemental keys are not user credentials and they do not have their own credential IDs.
• Attestation Statements: Supplemental keys can optionally have an attestation. These are crucial for understanding the scope and security level of supplemental keys. An attestation can indicate the level of protection enjoyed by a hardware-bound key, or the policies for other types of supplemental key.
• Implementation for Relying Parties: Relying parties can request these supplemental keys as part of the authentication process. However, the complexity of dealing with multiple keys and attestation statements means that this extension is best suited for entities with specific security needs, such as banks or services operating under strict regulatory requirements.

It's crucial to note that, as of April 2024, the supplementalPubKeys extension has not been adopted by any major browser, and the WebAuthn Level 3 specification is still under development and subject to changes. Whether this feature will be included in the final version of the specification, and its potential future implementation and adoption, remains uncertain, as currently it is only in the Editor’s Draft.

As of August 2024, the supplementalPubKeys extension has been officially discontinued. The WebAuthn working group decided to remove this feature due to insufficient support. The deprecation of this extension also highlights a new direction. Currently, the FIDO Alliance is working on developing a different approach to support Relying Parties with high-security requirements. This upcoming solution is expected to address the gaps left by the discontinuation of supplementalPubKeys and offer new methods to strengthen authentication processes in scenarios where stringent security standards are critical.

For more details on the deprecation, see the official WebAuthn GitHub pull request.

In first part of our 3 part series, we have analyzed what the historical and technical differences of device-bound and synced passkeys are. Understanding these differences will help us to apply the requirements of PSD2 and SCA accordingly. Also we have taken a look into what the future might bring by taking a look into the latest changing in the still evolving Webauthn Level 3 Standard.

Here are the links to the other parts of our series:

• Part 2 “Analysis of PSD2 & SCA Requirements (SCA & Passkeys II)”
• Part 3 "What SCA Requirements Mean for Passkeys (SCA & Passkeys III)
• Part 4 "PSD3 / PSR Implications for Passkeys (SCA & Passkeys IV)"