Any passwordless FIDO credential is a passkey.

Passkeys are a password replacement that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are resistant to phishing, are always strong, and are designed so that there are no shared secrets.

They simplify account registration for apps and websites, are easy to use, work across all of a user’s devices, and even other devices within physical proximity.

From a technical standpoint, passkeys are FIDO credentials that are discoverable by browsers or housed within native applications or security keys for passwordless authentication. Passkeys replace passwords with cryptographic key pairs for phishing-resistant sign-in security and an improved user experience. The cryptographic keys are used from end-user devices (computers, phones, or security keys) for user authentication.

Passkeys that are managed by phone or computer operating systems are automatically synced between the user’s devices via a cloud service. The cloud service also stores an encrypted copy of the FIDO credential. Passkeys can also by design be available only from a single device from which they cannot be copied. Such passkeys are sometimes referred to as “single-device passkeys”. For example, a physical security key could contain multiple single-device passkeys.

The word “passkey” is a common noun; think of it the way you would refer to “password”. It should be written in lowercase except when beginning a sentence. The term “passkey” (and plural form “passkeys”) is a cross-platform general-use term, not a feature tied to any specific platform.

When delineation is required, passkeys that are synced between user’s devices via a cloud service are generally referred to as “synced passkeys”, and those that never leave a single device (including those on UAF apps) are referred to as “device-bound passkeys”.

The primary use-case for passkeys is replacing the password as the first/primary factor for account authentication.

For example, a user could sign in to web services using a passkey — instead of a password — on their mobile phone. Since phone based passkeys sync across all of a user’s devices, the process of upgrading to a new mobile phone is a seamless transition.

When a user is asked to sign in to an app or website, the user approves the sign-in with the same biometric or PIN or on-device password that the user has to unlock their device (phone, computer, or security key). The app or website can use this mechanism instead of the traditional username and password.

Yes. There is no change to the local biometric processing that the user devices (mobile phones, computers, security keys) do today. Biometric information and processing continues to stay on the device and is never sent to any remote server — the server only sees an assurance that the biometric check was successful.

For years, passwords have been subject to phishing attacks and credential stuffing attacks, due to the prevalence of password reuse and database breaches.

Because the primary factor — the password — is fundamentally broken in multiple ways, the industry has seen widespread adoption of layering on an additional second factor. But unfortunately the most popular forms of second factors — such as one time passwords (OTPs) and phone approvals — are both inconvenient and insecure. They can be phished, and they are being phished at scale today.

Since passkeys are FIDO credentials, we now have a primary factor that — standing alone — is more secure than the combination of either “password + OTP” or “password + phone approval”.

Passkey syncing is end-to-end encrypted and sync providers have strong account security protections.

Furthermore, syncing is critically important for FIDO to achieve its mission, which is to make sign-in easier and fundamentally safer by replacing passwords in as many places as possible.

This is because replacing passwords means “competing” with passwords across three dimensions:

• Speed: should be faster than creating or using a password.
• Convenience: should be at least equally as convenient — if not more convenient — than using a password.
• Security: should be phishing-resistant, and should be guaranteed to be unique per app/website/service.

Speed
Creation of passkeys eliminates the need for users to comply with password complexity requirements. Registration is as simple as a biometric auth or entering a PIN code, and subsequent sign-in attempts with a passkey again only require a biometric authentication or PIN code — both faster than typing in a password.

Convenience
The usability of a password replacement must compete with the convenience of passwords, and one of the primary usability benefits of passwords is that they can be used from any device.

Syncing means that passkeys are available from all of a user’s devices using the same sync provider. And just like passwords, visiting a website from another device does not require going through a credential registration/creation flow — cross-device sign-in is supported via an enhancement to the FIDO Alliance Client to Authenticator Protocol (CTAP) that uses Bluetooth Low Energy (BLE) to verify physical proximity.

If the cryptographic key is bound to the user’s computer or mobile device, then every time the user gets a new device, the RP would have to fall back to other methods of authentication (typically a knowledge-based credential such as a password). In practice, this often means that the first sign-in on a new device will be both inconvenient and phishable.

Passkeys solve this issue because they are available on the user’s device if and when the user needs them — starting from the very first sign-in to a website from that device. Last but not least, users often forget passwords and don’t set up backup emails and phone numbers. With passkeys, as long as the user has their device, they can sign in; there is nothing to forget. Because passkeys can be backed up, they can be better protected from loss.

Security
Passkeys, which are FIDO credentials, allow relying parties (which face a constant threat of phishing, credential stuffing, password database breaches, etc.) to replace passwords with FIDO credentials. FIDO offers relying parties a challenge-response authentication protocol based on asymmetric cryptography. This means phishing-resistance, and the elimination of sensitive secrets on the server, resulting in a huge step forward in security.

Phishing-resistance is a core design goal of FIDO Authentication. This goal is achieved at sign-in whether or not the cryptographic keys are bound to hardware. Furthermore, breaches of password databases (which can be an attractive target for hackers) no longer pose a threat as there are no passwords to steal.

RPs will use the built-in WebAuthn (for websites) and platform FIDO APIs (for apps) to exercise passkeys for sign-in. Passkeys will have built-in support in the main mobile and desktop operating systems and browsers.

Availability of built-in passkeys that automatically synchronize to all of a user’s devices is arriving now and in the near future:

• Apple has announced support in iOS 16 in Sep 2022, and iPadOS 16 and macOS Ventura in Oct 2022.
• Google has announced support in Android starting October 2022 and plans passkey support in ChromeOS by 2023.
• Microsoft has announced passkeys support within Windows Insiders Builds and is expected to deliver broader passkey support later in 2023 and throughout 2024.

Most platforms already support sign-in with a passkey from a nearby device such as a mobile phone or security key. These include:

• Microsoft Edge and Google Chrome on Windows
• Edge, Safari and Google Chrome on macOS
• ChromeOS

Please also see the next two questions for more information.

Passkeys are accessed using the same WebAuthn API which has been available across all the platforms and browsers since 2018. The cross-device sync of passkeys is managed transparently by the OS.

Device OS platforms are implementing a feature by which the passkeys on the device (for example, a mobile phone or laptop computer) are synced to the device cloud tied to the user’s platform account (eg, Apple ID for iOS/macOS, Google account for Android & ChromeOS, Microsoft account for Windows). Syncing of passkeys is end-to-end encrypted.

When a user creates a passkey 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 passkeys 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 user’s passkeys are synced and available for sign-in on the new device.

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

The user visits the RP website on the Windows computer. They then see a ‘sign-in’ button on the RP’s login web page and push that button. The user now sees the option to use another device to sign-in to the RP.

When the other device (say, their phone) is physically close (in BLE range) to the Windows computer, the user sees a pop-up from the Android OS. The pop-up asks (in essence) “I see you are trying to sign-in to the RP 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 device that has been enrolled with the RP with a very similar flow. In this instance, the user will visit the RP website on the Windows computer. They see a ‘sign-in’ button on the RP’s login web page and push that button. When the RP asks for authentication, the user is able to insert their security key device and unlock the security key with biometric or PIN and they are signed-in to the website.

The flows described in this example above would work regardless of the OS that the user’s mobile phone is running and the OS and browser available on the target device for login (e.g. computer, tablet, TV, etc.) or what model of FIDO-compliant security key the user has.

The flows described are available now for Google Chrome and Microsoft Edge on Chrome OS, Windows, Mac and Linux.

The FIDO Cross-Device Authentication flow, which leverages CTAP 2.2, uses Bluetooth Low Energy (BLE) to verify physical proximity, but does not depend on Bluetooth security properties for the actual security of the sign-in. The CTAP transport, named ‘hybrid’, uses an additional layer of standard cryptographic techniques — on top of standard Bluetooth security properties — to protect data.

Passkeys are kept on a user’s devices (something the user “has”) and — if the RP requests User Verification — can only be exercised by the user with a biometric or PIN (something the user “is” or ”knows”). Thus, authentication with passkeys embodies the core principle of multi-factor security.

RPs may be concerned that a passkey could be made available to an attacker through a single factor (say, a password) from the platform vendor account. In practice, however, this is not usually the case: platform vendors consider multiple signals beyond the user’s password — some visible to the user, some not — when authenticating users and restoring passkeys to their devices.

Note that some regulatory regimes still have to evolve to recognize passkeys as one of the officially listed forms of multi-factor. This is an area of active engagement for the FIDO Alliance.

If the user is still in possession of their old device, the user can use the passkey on the old device (say, an Android device) to sign the user into their account on the new device (say, an iOS device). Once signed in, the user can create a passkey in the new platform account.

If the user has a FIDO Security Key, they can use it to securely authenticate on the new device.

If the user does not have their old device or a security key, 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 get the user signed in.

Yes, FIDO Security Keys today support single-device passkeys and have done so since 2019, when FIDO2 added support for passwordless sign-ins via discoverable credentials with user verification. All the client platforms and browsers have native support to exercise security keys already. Security key vendors may choose to support passkey synchronization in the future.

Web services can leverage passkeys to support a range of use cases. For example, if the user gets a new computer, they can present their security key in proximity (e.g. by plugging into USB or tapping for NFC) to the computer and sign-in to their online account.

Since all passkeys are FIDO credentials, a web service implementing support for FIDO will be able to support all passkey implementations.

Specific environments with particular compliance needs may be required to guarantee there is only one copy of the cryptographic key available. Passkeys on FIDO Security Keys are a great solution for such use cases.

Also, in scenarios where a user has lost access to all of their other mobile and other devices where their passkeys have been synced, such FIDO Security Keys can act as a recovery credential.