Use Passkeys for Painless Strong Customer Authentication

Key Takeaways

  • SCA requires multiple authentication factors — knowledge (password), possession (device), or inherence (biometric) — and passwords alone don't meet the bar.

  • Passkeys solve both security and UX — they use WebAuthn/FIDO2 standards to combine strong cryptography with a simple, guided user experience.

  • Phishing-resistant by design — private keys never leave the device and are never typed in, so they can't be captured through phishing.

  • Per-site key pairs prevent cross-site compromise — a stolen key for one website can't be reused against another.

  • Two simple ceremonies drive the experience — registration (create and register a key pair) and authentication (approve via device + second factor).

  • Account recovery is straightforward — users can repeat the registration ceremony to add a new passkey if one is lost.

  • Easy to integrate via existing OAuth infrastructure — rather than building custom cryptographic verification, teams can activate passkey support directly in an authorization server already running a code flow.

On this page

When building digital services, organizations often have to meet a strong customer authentication (SCA) requirement as part of their data protection. Yet the best ways to meet this requirement are often misunderstood. When suboptimal choices are made, you introduce complexity that can damage the user experience. 

Yet, the best all-around SCA solution for most organizations is available right now. In this article, I provide some background on traditional ways of achieving strong customer authentication. Then, I explain how passkeys improve on these methods, to provide a modern blend of security, user experience, and reliability.

Multi-Factor Authentication (MFA)

Strong customer authentication requires the user to provide more than one authentication factor, as explained in our introduction to MFA. When these factors are difficult for an attacker to forge, they provide a high level of assurance (LoA). Usually, you choose from two of the following factors:

  • Knowledge factors (something the user knows, like a password)

  • Possession factors (something the user owns, like a keyfob)

  • Inherence factors (something the user is, like a fingerprint)

A common knowledge factor is a password, which in and of itself is insufficient to meet SCA requirements. Passwords can be captured by phishing attacks that trick the user. Users often share passwords across websites, so security weaknesses in other sites could compromise your application. If servers store user passwords insecurely, you also face risks of server breaches that could reveal the passwords of many users.

Therefore, you might combine passwords with something the user owns, like an SMS message sent to the user’s mobile device, or a mobile authenticator app that provides a time-based one-time password (TOTP). Both of these introduce second factors that an attacker cannot easily provide. 

MFA User Experience

Yet, MFA can also make user logins more difficult. If MFA fails, users may fail to register or get locked out. Login user experience (UX) is critical to your digital services. In fact, when users onboard, your login screens are typically their very first experience. If this process is difficult, users are likely to abandon your product. A poor login UX can, therefore, be a barrier to adoption. 

If you had to choose the ideal SCA solution, you would want it to combine security with a slick user experience. You would likely look for behaviors like these:

  • The platform on which your applications run provides a strong credential automatically

  • Any user actions should result in a simple experience that avoids confusion

  • The solution is reliable, with support for account recovery and roaming across devices

You get these behaviors when using passkeys, which are MFA credentials used with the WebAuthn standard. WebAuthn is a core component of the FIDO2 project and is overseen by the FIDO Alliance, which also publishes UX Guidelines.

Passkey Security Behaviors

Passkeys use strong, asymmetric cryptography. When a user first uses a passkey to sign into an application, a device creates a key pair and stores the private key. The public key is registered with the application’s server, which is typically a website. To authenticate, the user sends a digital signature to the server to prove ownership of the private key. Once the server has validated the digital signature using the registered public key, the user is authenticated.

In this article, I focus only on platform passkeys, where the operating system acts as the device. Technology support was added to all of the main desktop and mobile operating systems and browsers around October 2022. It was then backported to older platforms, such as Android 9 and Windows 10, using security patches. Since many digital users run on fairly up-to-date platforms, this means passkey logins usually do not require difficult prerequisites.

Since cryptographic keys are never input directly, phishing attacks cannot capture them. Instead, the operating system uses the key to produce a digital signature that is sent to the server. Also, a distinct key pair must be used for each website. So, even if a private key for one website is somehow stolen, it can never be used against a different one.

The main authentication factor is the strong cryptography-based credential. The second factor is a gesture that proves user presence and prevents automated attacks. Typically, the user provides a knowledge factor like a PIN, or an inherence factor like a mobile touch service that verifies their fingerprint. 

Passkeys User Ceremonies

Passkeys are designed to remove almost all human error. There are two ceremonies, for registration and authentication. The registration ceremony creates a key pair and registers the public key on the server against the current user’s account for that particular website. Some form of user authentication is needed so that this is done correctly. A method such as email verification is often sufficient. When a passkey ceremony begins, browser or operating system dialogs are invoked:

create-1

The authentication ceremony provides a slick user experience, for all future logins. The user simply follows the dialogs, approves the use of their device credential, and then provides the second factor when prompted:

register-1

You can also quite easily recover from scenarios where users lose their passkeys by allowing users to repeat the registration ceremony and register an additional public key at the server.

How to Integrate Passkeys

To integrate passkeys into an application, you might start by writing a few lines of JavaScript code. Yet there are some challenging areas:

  • You need to provide a server component that uses cryptography to verify digital signatures and store public keys against user accounts.

  • Your solution must deal with user experience, reliability, and account recovery, and it should support storing multiple passkeys against user accounts.

  • Once passkey authentication has completed, you need to ensure that the application has a correct API message credential with which it can call APIs.

Yet, you can use an out-of-the-box server component that implements all of these behaviors for you. If you use OAuth-based security, you are already running a code flow. You just need an authorization server that implements passkeys with the above behaviors. The only step needed to integrate a tested passkey implementation is to activate it in your authorization server.

curity-blog-passkeys

Conclusion

Passkeys are likely to be the simplest and best way to meet your SCA requirements because of their phishing-resistant qualities that other SCA options lack. Users are becoming accustomed to the passkeys user experience in other applications. Therefore, consider making a great user impression in 2024 by adding passkeys to your authentication options.

Related resources

Frequently Asked Questions

How long does a typical passwordless/passkey migration take for an organization with an existing user base?

Migration timelines vary significantly based on user base size, the diversity of devices/platforms in use, and how many alternative authentication flows need to be designed and tested. Organizations often approach this as a phased rollout rather than a single cutover.

How do passkeys work across different browsers and operating systems — is there a compatibility standard?

Passkeys are built on the FIDO2/WebAuthn standards, which are broadly supported across major browsers and operating systems, though support levels and specific behaviors (like cross-device syncing) can vary depending on the platform and vendor implementation.

What happens if a user loses access to all their passkey-holding devices simultaneously?

This scenario requires a robust account recovery process, typically involving identity verification through alternative means (e.g., email verification, support-assisted recovery, or backup codes) since there's no "password reset" equivalent for passkeys.

What percentage of users typically abandon registration during a passkey rollout, and how does this compare to traditional password signup?

Drop-off rates depend heavily on the friction in the specific registration flow, device support, and user familiarity with passkeys. This is exactly the kind of metric A/B testing is designed to uncover, though the article doesn't provide baseline figures to compare against.