---
url: 'https://www.corbado.com/blog/device-bound-synced-passkeys'
title: 'Device-Bound vs. Synced Passkeys (SCA & Passkeys I)'
description: 'Explore synced passkeys & device-bound passkey, their differences & learn about the role of hardware security modules (secure enclave, TEE, TPM).'
lang: 'en'
author: 'Vincent Delitz'
date: '2024-04-15T18:59:30.003Z'
lastModified: '2026-10-05T07:58:10.135Z'
keywords: 'device-bound passkey, synced passkey, passkey device, syncable passkeys'
category: 'Passkeys Strategy'
---

# Device-Bound vs. Synced Passkeys (SCA & Passkeys I)

## Overview: Strong Customer Authentication with Passkeys

- Analysis of [PSD2](https://www.corbado.com/blog/psd2-passkeys) & SCA Requirements
- What SCA Requirements Mean for Passkeys
- [PSD3](https://www.corbado.com/blog/psd3-psr-passkeys) / [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) Implications for
  Passkeys

## 1. Introduction: Device-Bound vs. Synced Passkeys

In our prior passkeys [PSD2](https://www.corbado.com/blog/psd2-passkeys) blog post, we discussed how passkeys are
already in use by Fintechs like [Revolut](https://www.corbado.com/blog/revolut-passkeys) and
[Finom](https://www.corbado.com/blog/finom-passkeys) and how they improve the digital security of
[banking](https://www.corbado.com/passkeys-for-banking).

Passkeys come in two major forms: **synced passkeys** and **device-bound passkeys**. While
synced passkeys allow users to authenticate across multiple devices seamlessly,
**device-bound passkeys** are strictly linked to a passkey device like a hardware
[security key](https://www.corbado.com/glossary/security-key) or local [authenticator](https://www.corbado.com/glossary/authenticator).

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](https://www.corbado.com/blog/psd2-passkeys)
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](https://www.corbado.com/faq/sca-psd2-importance) (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](https://www.corbado.com/blog/psd3-psr-passkeys) /
[PSR](https://www.corbado.com/blog/psd3-psr-passkeys) will mean for SCA and passkeys in the future.

## 2. Strong Customer Authentication, PSD2 and Passkeys

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](https://www.corbado.com/blog/passkeys-stakeholder) 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](https://www.corbado.com/faq/are-passkeys-device-specific)
but also their practical applications in enhancing both security and user experience.

By understanding the nuances, [stakeholders](https://www.corbado.com/blog/passkeys-stakeholder) 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.

[Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc)

## 3. From Device-bound Passkeys to Synced Passkeys

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

### 3.1 What are Device-Bound Passkeys (Single-Device Passkeys)?

We start by looking at the history and evolvement of
[device-bound passkeys](https://www.corbado.com/faq/are-passkeys-device-specific) before taking a deeper look at
their technical details.

![Device-Bound Passkey](https://www.corbado.com/website-assets/device_bound_passkey_effe25ab99.png)

#### 3.1.1 History of Device-bound Passkeys

Historically, authentication mechanisms within WebAuthn (the standard underlying passkeys)
were tightly coupled to physical devices: security keys (e.g.
[YubiKeys](https://www.corbado.com/glossary/yubikey)). Before the widespread adoption of passkeys,
[FIDO2 credentials bound to a single authenticator represented the gold standard](https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn)
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](https://www.corbado.com/glossary/phishing) campaigns or
[credential stuffing](https://www.corbado.com/glossary/credential-stuffing) attacks.

#### 3.1.2 Technical Details of Device-Bound Passkeys

**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. [Windows Hello](https://www.corbado.com/glossary/windows-hello) credentials on Windows 10 and
[Windows 11](https://www.corbado.com/blog/passkeys-windows-11) remain
device-bound—[Windows Hello](https://www.corbado.com/glossary/windows-hello) itself does not yet
[sync passkeys across devices](https://www.corbado.com/blog/passkeys-sharing). However, Microsoft has taken a
significant first step by
[introducing passkey saving and syncing in Microsoft Edge](https://blogs.windows.com/msedgedev/2025/11/03/microsoft-edge-introduces-passkey-saving-and-syncing-with-microsoft-password-manager/)
(starting with Edge 142). This browser-level sync via Microsoft
[Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers) enables passkeys to sync across
Windows devices when using Edge, similar to how
[Google Password](https://www.corbado.com/blog/how-to-use-google-password-manager) Manager enables passkey sync
in Chrome browser on Windows. This represents an important advancement in Windows passkey
capabilities, though it's specific to the Edge browser rather than the
[Windows Hello](https://www.corbado.com/glossary/windows-hello)
[platform authenticator](https://www.corbado.com/glossary/platform-authenticator).
[Windows Hello passkeys](https://www.corbado.com/blog/windows-hello-passkeys-replace-passwords) remain
device-bound, but this Edge integration provides a practical path toward synced passkeys
on Windows while the [platform authenticator](https://www.corbado.com/glossary/platform-authenticator) itself may
evolve to support sync in the future.

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](https://www.corbado.com/blog/webauthn-errors)
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](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/)
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](https://www.corbado.com/faq/are-passkeys-device-specific) 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.

### 3.2 What are Synced Passkeys (Multi-Device Passkeys)?

Also here, we take a look at the historical development of synced passkeys before
analyzing the technical details. Sometimes synced passkeys are also referred to **syncable
passkeys**.

![Synced Passkey](https://www.corbado.com/website-assets/synced_passkey_042125aca6.png)

#### 3.2.1 History of Synced Passkeys

Following the publication of the WebAuthn Level 2 and
[CTAP](https://www.corbado.com/blog/passkeys-explained-clearly) 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](https://www.corbado.com/glossary/authenticator) while keeping full backward
compatibility with the existing standards.

##### 3.2.1.1 Utilization of Platform Authenticators as Secure Hardware Modules

The first challenge – eradicating the need for new hardware – was addressed through the
utilization of built-in platform [authenticators](https://www.corbado.com/glossary/authenticator) found in modern
consumer devices (e.g. Touch ID, [Face ID](https://www.corbado.com/faq/is-face-id-passkey), Windows Hello).

![Hardware Security Modules HSM TPM TEE Secure Enclave](https://www.corbado.com/website-assets/hardware_security_modules_hsm_tpm_tee_secure_enclave_11118d359e.png)

Modern devices are increasingly outfitted with specialized security modules, such as the
Trusted Execution Environment (TEE) on [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android),
[Secure Enclave](https://www.corbado.com/glossary/secure-enclave) on [iOS](https://www.corbado.com/blog/webauthn-errors) 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](https://www.corbado.com/glossary/public-key-cryptography), a level of security
previously attainable only through external
[hardware security keys](https://www.corbado.com/blog/best-fido2-hardware-security-keys) (e.g.
[YubiKeys](https://www.corbado.com/glossary/yubikey)), and largely restricted to tech-savvy individuals or
organizations within highly regulated industries.

By harnessing the capabilities of the TEE, [Secure Enclave](https://www.corbado.com/glossary/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. Organizations that combine synced passkeys with optimized
[passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) and
[passkey login](https://www.corbado.com/blog/passkey-login-best-practices) flows see the highest adoption rates.
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](https://www.corbado.com/glossary/public-key-cryptography) becomes directly applicable
to a wide range of use cases and at the same time simplifies authentication for users.

##### 3.2.1.2 Synchronization of Passkeys to the Cloud

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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/digital-identity-guide) 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.

#### 3.2.2 Technical Details of Synced Passkeys

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. On Windows, synced passkeys are now available
through Microsoft Edge/Microsoft [Password Manager](https://www.corbado.com/blog/passkeys-vs-password-managers)
(browser-level sync), while Windows Hello
[platform authenticator](https://www.corbado.com/glossary/platform-authenticator) credentials remain
device-bound. Third-party password managers (e.g. [Dashlane](https://www.corbado.com/blog/dashlane-passkeys),
[KeePassXC](https://www.corbado.com/blog/keepassxc-passkeys),
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)) with passkey management
capabilities also provide sync across platforms. In scenarios where synced passkeys are
used, the `isBackupEligible` and `isBackedUp` flags are set to 1, indicating backup
eligibility and successful synchronization.

Furthermore, while it is currently still possible to identify the specific authenticator
where the passkey has been stored, the absence of [attestation](https://www.corbado.com/glossary/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.

### 3.3 Single-Device-Binding of WebAuthn Credentials Sacrificed for the Greater Good

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](https://github.com/w3c/webauthn/issues/1658) 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](https://www.corbado.com/blog/passkeys-prf-webauthn)
draft. Unfortunately this approach was also discontinued in August of 2024.

### 3.4 Best of Two Worlds: Passkeys and supplementalPubKeys Extension \[deprecated as of August 2024]

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

#### 3.4.1 From devicePubKey to supplementalPubKeys Extension

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](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension).
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](https://www.corbado.com/glossary/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](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension):

“_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](https://www.corbado.com/passkeys-for-public-sector)
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.

#### 3.4.2 Technical Details of supplementalPubKeys

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

![Supplemental Pub Key Chart](https://www.corbado.com/website-assets/supplemental_public_key_chart_2026_b9b17742a0.png)_Based
on the original [GitHub issue](https://github.com/w3c/webauthn/pull/1957)_

The image shows the concept of **supplementalPubKey** based on the original
[GitHub issue](https://github.com/w3c/webauthn/pull/1957) (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](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/psd2-passkeys/are-passkeys-two-factor-authentication)).
- **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](https://www.corbado.com/blog/passkeys-prf-webauthn)
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.

#### 3.4.3 Deprecation of supplementalPubKeys in August 2024

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](https://github.com/w3c/webauthn/pull/2109).

## 4. How Corbado can help

The distinction above is the easy part to learn and the hard part to apply, because which
of the two your own users hold keeps moving as platforms and password managers change
their behavior. [Corbado Observe](https://www.corbado.com/observe) is the
[authentication observability](https://www.corbado.com/blog/authentication-observability) layer, and it derives
that split from the credential data itself instead of from what a user believes they use.

### Passkey Type Visibility across your User Base

The Authenticator Inventory view classifies every credential in your user base as a synced
passkey, a device-bound passkey or a roaming [security key](https://www.corbado.com/glossary/security-key). The
classification runs on signals the ceremony itself produced: the transports the credential
reported, the backup state bit stored when the credential was created and the
[AAGUID](https://www.corbado.com/glossary/aaguid) looked up in two separate catalogs. The FIDO Metadata Service
is the hardware one and covers security keys.
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) and the third-party
managers, which is where most consumer credentials sit, come from a platform-authenticator
catalog of their own. An [AAGUID](https://www.corbado.com/glossary/aaguid) in neither is shown truncated, and
credentials whose signals do not resolve stay labelled unknown, so a sparse older record
does not silently become a statistic.

[Video: Authenticator inventory](https://www.corbado.com/videos/features/authenticator-inventory.mp4) ([See Authenticator Inventory in Corbado Observe](https://www.corbado.com/observe/authenticator-inventory))

The same view carries an "MDS FIDO Certified L1+" share over the population, with the
L1/L2/L3+ breakdown sitting in a view of its own rather than as a headline number, plus a
monthly registrations chart you can group by model, certification or registration path.
That chart is what makes a population drifting from device-bound credentials towards
synced ones visible while nobody on your side changed anything. Section 3.4 explains why
supplementalPubKeys was withdrawn. The practical consequence is that backup eligibility
and backup state are the strongest per-credential signal left, and both are persisted at
enrollment, then decoded client-side from the raw ceremony JSON when you open a flow in
User Search or a flavour in Passkey Errors.

### What this gives you for the SCA Discussion

Passkey type is an input to a risk assessment, and an assessment needs evidence under it.
Be careful with the [user verification](https://www.corbado.com/blog/webauthn-user-verification) bit here. User
Search decodes UV, UP, BE and BS from one flow's raw ceremony JSON and Passkey Errors
decodes UV, BE and BS, but the login path writes all four as false on the backend, so "a
biometric or a PIN was performed" is a reading you take per flow rather than a cohort
number you can query.

Acting on the difference at prompt time is [Corbado Connect](https://www.corbado.com/connect)'s job, and its
decision knows more than the raw client environment. The detection object handed to the
rules carries tags for what this environment already holds: a local platform passkey, a
synced platform passkey, a cross-platform one or one living in a
[password manager](https://www.corbado.com/blog/passkeys-vs-password-managers), alongside the recent history of
completed passkey logins and aborted appends here. What it cannot know before a credential
exists is the vendor, since [1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)
against [Bitwarden](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) is resolved
from the [AAGUID](https://www.corbado.com/glossary/aaguid) afterwards.
[Gradual rollout](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption) is the narrower of the
two: its rulesets read client information only, web against
[native app](https://www.corbado.com/blog/native-app-passkeys), [WebView](https://www.corbado.com/blog/native-app-passkeys), platform
and version, browser, device brand and model, so they control which cohorts reach the
passkey flow at all without ever looking at the credential.

> **Corbado's Position on PSD2/SCA and Passkeys:** Passkeys (both device-bound and synced)
> can be SCA-compliant. Each institution must own its SCA risk assessment, but the
> evidence is clear: passkeys inherently provide two SCA factors, possession (private key
> in hardware security module or cloud keychain) plus inherence (biometric) or knowledge
> (PIN). The "possession" debate is nuanced but resolvable, and the industry is landing on
> three approaches: (1) **Passkeys as-is** (e.g. [Revolut](https://www.corbado.com/blog/revolut-passkeys),
> [Finom](https://www.corbado.com/blog/finom-passkeys)), inherence plus possession via the device holding the
> private key, (2) **Passkeys + cookie/session binding** (e.g.
> [PayPal](https://www.corbado.com/blog/paypal-passkeys), Comdirect), an extra possession signal for a
> conservative interpretation, (3) **Cryptographic binding (DBSC/DPoP)**, hardware-bound
> proof of possession and the strongest guarantee. No single "correct" interpretation
> exists yet. An outcome-based approach to SCA is needed, focusing on demonstrable
> [phishing](https://www.corbado.com/glossary/phishing) resistance rather than rigid factor categorization.
> [Dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) remains a separate requirement for
> [payments](https://www.corbado.com/passkeys-for-payment) even with passkeys.

## Frequently Asked Questions

### How do device-bound passkeys enhance security?

Device-bound passkeys are WebAuthn credentials strictly tied to the device on which they
were created. Unlike synced passkeys, they remain on a single device, making them
inherently more secure for certain use cases:

- **No credential stealing**: The private key never leaves the device, so attackers cannot
  intercept credentials.
- **Prevention of unauthorized access**: Authentication only happens from the specific
  device where the passkey was created.
- **No cloud dependency**: Eliminates risks associated with cloud data breaches or account
  takeovers.
- **High-security compliance**: Meets strict device-bound authentication requirements for
  regulated industries like [financial services](https://www.corbado.com/passkeys-for-banking) (AAL3).

The main downside is limited portability. If the device is lost, the passkey cannot be
recovered unless the user registers a new one on another device.

### Why were synced passkeys introduced and what are their benefits?

Synced passkeys (multi-device passkeys) were introduced to solve the usability challenges
of device-bound passkeys, particularly the lack of portability and potential account
lockout if a device is lost. Key benefits include:

- **Multi-device authentication**: Access accounts from multiple devices without manually
  registering a new passkey for each one.
- **No risk of losing access**: Credentials are backed up to the cloud (e.g.
  [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain),
  [Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)), ensuring recovery
  if a device is lost.
- **Improved UX**: Eliminates friction by removing the need to manually transfer or
  recreate credentials.
- **No additional hardware required**: Unlike
  [hardware security keys](https://www.corbado.com/blog/best-fido2-hardware-security-keys), synced passkeys use
  built-in device security modules.
- **Strong security with cloud convenience**:
  [End-to-end encryption](https://www.corbado.com/faq/end-to-end-encryption-passkey-sync) ensures the private key
  never leaves the device in unencrypted format.

## 5. Conclusion

In the first part of our 4 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](https://www.corbado.com/blog/passkeys-prf-webauthn) 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](https://www.corbado.com/blog/psd3-psr-passkeys) / [PSR](https://www.corbado.com/blog/psd3-psr-passkeys) Implications
  for Passkeys (SCA & Passkeys IV)"