Passkeys

Passkeys

/ˈpasˌkēs/
noun
Based on FIDO standards, passkeys are a replacement for passwords that provide faster, easier, and more secure sign-ins to websites and apps across a user’s devices. Unlike passwords, passkeys are always strong and phishing-resistant.​

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

Why passkeys?
Passwords are a problem.

Knowledge-based

Hassle to use and remember

Easy to phish, harvest, replay

Knowledge-based

Hassle to use and remember

Easy to phish, harvest, replay

of organizations experienced a phishing attack in the past year.*

of organizations experienced a phishing attack in the past year.*

 *HYPR, 2022 State of Passwordless Security Report – Download the Report here.

Legacy authentication solutions don’t address the security problem and/or are not usable enough for large-scale consumer utilization.

Passkeys optimize access and usability for FIDO Authentication

Organizations can deploy FIDO sign-ins with passkeys across a variety of use cases. Passkeys enable users to access their FIDO sign-in credentials on many of their devices, even new ones, without having to re-enroll every device on every account. Alternatively, device-bound passkeys that are bound to a FIDO security key or platform are an option for organizations that do not require syncing.

How do users use passkeys?

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 that the user has to unlock the device (phone, computer or security key). The app or website can use this mechanism instead of the traditional (and insecure) username and password.

Here’s what this means for…

Download our passkey logo style guide files

FAQ’s

What is a Passkey?

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”.

What are the use cases for 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.

How does a user experience Passkeys?

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.

Is the user’s biometric information safe?

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.

Why are passkeys better than password + second factor?

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”.

Isn’t it unsafe for passkeys to leave the device and be synced to other devices?

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.

How can an online service (aka “Relying Party [RP]”) use a passkey for authentication?

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.

What is the availability of passkeys across various OS platforms?

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.

How does a passkey become available across a user’s devices?

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.

How does the user sign-in if a passkey for the RP is NOT already available on the 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.

Is it safe for the user to do a FIDO sign-in on a nearby device using Bluetooth?

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.

Are passkeys considered multi-factor authentication?

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.

How can the user switch to a new mobile platform as the sign-in device (eg, from Android to iOS or vice versa)?

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.

Can FIDO Security Keys support passkeys?

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.