A multi-device FIDO credential is a FIDO credential that is backed up (usually to the user’s platform account; e.g., Google Account or AppleID) in a manner that the user is then able to restore the credential to, and use it from, another device.

From a user experience standpoint, this will be very similar to how one interacts with a password manager today to help them securely enroll and sign into websites – only it will be far more secure as the server is issued a public key instead of a password.

A single-device credential is not backed up, and therefore can only be used as long as the device on which it was created is still available.

“Passkey” is a term that some parties are using to refer to multi-device FIDO credentials.

The exact user experience may vary from platform to platform, but usually, the user will authorize the use of the credential with a device biometric (TouchID, FaceID, Windows Hello, etc.), or by typing a device secret (screen unlock PIN, device login PIN, etc.)

Apple, Google and Microsoft have announced plans to implement multi-device FIDO credentials in their respective platforms.

An update to the Client to Authenticator Protocol (CTAP) called “caBLE” will leverage Bluetooth LE (BLE) to enable cross-device, cross-ecosystem credential usage. For example, a single- or multi-device credential could be presented from a phone in ecosystem A to a laptop in ecosystem B.

Today, Security Keys hold single-device credentials, as they are bound to the authenticator. Security Key vendors may decide to offer multi-device credential authenticators in the future.

We expect all platforms implementing multi-device credentials to adhere to FIDO’s Privacy Principles, including usage of personal data for the sole purpose of FIDO operations.

Yes, there are no changes to user verification methods or their security properties as part of the effort – and user biometrics will never leave the device.

FIDO Alliance’s mission is to help reduce the world’s over-reliance on passwords. It is true that some relying parties (and their users) get value out of hardware-bound credentials, and the FIDO standards still support this type of deployment.

But for many relying parties, the fact that FIDO’s approach required users to enroll each new device presents some customer usability challenges, and also limits their ability to replace passwords (as passwords frequently serve as a means to verify new authenticator enrollment).

As such, replacing the password with a challenge-response protocol based on asymmetric cryptography is a huge step forward in security, even if those cryptographic keys aren’t bound to hardware – as this helps RPs thwart the constant threats of phishing, credential stuffing and other remote attacks.

Each authenticator / platform may offer different experiences and controls. But a user can always register a second credential with a site and remove the first, effectively “moving” from one to the other.

Passwords and second-factors such as OTPs and Phone Approvals are inconvenient and insecure. They can be phished, and they are being phished at scale today. FIDO multi-device credentials are designed to solve this problem. They have three fundamental advantages over using passwords (even when used with traditional second-factors):

• Sign-in is easier for the user: It’s the same biometric or PIN users use to unlock their device. The user doesn’t need to deal with typing passwords or OTPs.

• Sign-in is fundamentally safer (phishing-resistant): Phishing-resistance of sign-in is a core design goal of FIDO and is built into every sign-in event that leverages FIDO. Furthermore, breaches of password databases (which can be an attractive target for hackers) no longer pose a threat.

Sign-in is more robust: Users often forget passwords and don’t set up backup emails and phone numbers. With multi-device FIDO credentials, the credentials are backed up and are therefore protected from loss. If the user gets a new phone the credentials can easily be restored to the new phone. When signing in from a new device, the existence of a multi-device credential is a powerful trust signal that websites can leverage to make recovering access to the account radically safer and simpler, since it means that the platform vendor has already verified the user.

Multi-device FIDO credentials will have built-in support in the main mobile and desktop operating systems and browsers, similar to the support which already exists for single-device FIDO credentials. Services would use the built-in WebAuthn and FIDO APIs to exercise FIDO credentials in the service’s websites and apps.

Device OS platforms are working on a feature by which the FIDO credentials on the device (for example, a mobile phone or laptop computer) are synced to the device’s cloud backup tied to the user’s platform account (eg, Apple ID for iOS/macOS, Google account for Android & ChromeOS, Microsoft account for Windows).

When a user creates a multi-device FIDO credential on any of their devices, it gets synced to all the user’s other devices running the same OS platform which are also signed into the same user’s platform account. Thus credentials created on one device become available on all devices.

Notably, if the user gets a new device with the same Platform OS and sets it up with their platform account, the FIDO credentials are synced to the new device and are available for sign-in to services on the new device.

This is best understood with an example: say the user has an Android phone where they already have a credential for the RP. Now they want to sign-in to the RP’s website on a Windows computer where they have never signed into the website before.

For existing devices, the user will point their browser to the RP’s website on the Windows computer. They see a ‘sign-in’ button on the login web page and hit that button.The user sees the option to add a new phone or use a previously paired one. If the user selects the paired phone and the phone is physically close (in BLE range) to the Windows computer the user sees a pop-up from the Android OS asking in essence “I see you are trying to sign-in on this nearby computer, here are the accounts I have.” The user chooses an account at which point the Android OS asks “Please perform your unlock to approve sign-in to the computer with this account”. The user performs the unlock and they are signed-in to the website

Alternatively, the user can use a security key that has been enrolled with the RP. In this instance, the user will point their browser to the RP website on the Windows computer. They see a ‘sign-in’ button on the RP’s login web page and hit that button. When the RP asks for FIDO authentication, the user is able to insert or tap their Security Key to unlock and they are signed-in to the website.

The flow described in this example would work regardless of the OS the user’s mobile phone is running and the OS and browser available on the target device for login (eg, computer, tablet, TV etc). The target user experience is very similar to that of a Phone Approval prompt commonly used today as a second-factor today. The crucial difference is that the approval is now phishing-resistant — this is because, when you approve a login on another device on a conventional phone approval, you don’t really know whether your other device is pointed to the correct website or a look-alike phishing site relaying information in real-time. In addition, the mobile phone approval also replaces the password (as opposed to being used as a second factor adjunct).

If the user still has their old device, they can use it to sign into their new device (using the above-mentioned caBLE protocol, which works across different platforms). If they don’t, then the RP can treat sign-in from the new device (which might be from a different vendor) as a normal account recovery situation and take appropriate steps to sign in the user. The RP would then usually create a new multi-device credential on the new device (which runs a different platform OS than the user’s previous device). If the user no longer plans to use their old device, they can let the RP know, and the RP can then delete the credential of the old device from their server records — thus, the credential on the old device will no longer be accepted for sign-in.

If the user is still in possession of their old device, the RP can also use the credential on that old device (say, an Android device) to sign the user into the new device (say, an iOS device) without going through an account recovery step. See previous question for more detail the old mobile can be used to sign-in to the new mobile in a simple phishing resistant way.

Additionally, a user can use a security key to securely authenticate to a new device.

The FIDO caBLE protocol uses Bluetooth to verify physical proximity and does not depend on Bluetooth security properties for the actual security of the sign-in. Instead, it uses standard cryptographic primitives at the application layer to protect data.

Multi-device FIDO credentials are present on a user’s devices (something the user “has”) and – if the RP requests this – can only be exercised by the user with a biometric or PIN (something the user “is” or ”knows”). Thus, authentication with multi-device FIDO credentials embodies the core principle of multi-factor security.

FIDO’s phishing-resistant sign-in capabilities are both built right into devices (platform authenticators) and are available in external authenticators (Security Keys). Platform authenticators which support Multi-Device Credentials will be built into the phones and laptops. Platform Authenticators when used cross device via caBLE are considered external authenticators to the platform the web browser is on. These authenticators will enable widespread adoption and will simplify the developer experience since the APIs are built into the platform.

Security Keys (external authenticators) are special-purpose authentication devices designed to cover a wide range of authentication use cases. The Security Key is also supported on these platforms and is designed to enable additional use cases for the RP. FIDO Alliance encourages RPs to enable both platform and external authenticators and to tailor the set of use cases specifically for the RP’s user population and design requirements.

Please send inquiries to info@fidoalliance.org, or to the public FIDO developer community at fido-dev@fidoalliance.org