Sign in with passkeys on security keys

Table of contents

Overview

Topics: consumer, passkeys on security keys, device-bound passkeys, security key, sign in
Relevant moments in the customer journey: Awareness > Consideration > Enrollment > Management > Authentication
Created: 14 May 2022

Allow people to sign in with security keys as a second factor after entering a username and password.

NOTE: this pattern was originally published in 2022.
Also see the 2024 Design Pattern for Passkey management UI: best practices for combining all passkey types.

  • After security key enrollment, do not alter the first factor (i.e., username and password)sign-in experience
  • Preserve secondary non-FIDO security key sign-in paths: Offer “Switch user” and “Sign in another way” links to preserve multi-user access and other secondary authentication methods the user has registered with the account.
  • After username and password is entered, prompt the user to connect their security key when ready: Offer an option (e.g., a “use a security key” button) for the user to initiate connecting the security key rather than automatically launching the browser dialogue for connecting a security key. User initiation of connecting a security key does introduce an additional click but it helps ensure that the browser dialogue doesn’t time-out if the user doesn’t have their security key handy. 
  • Once users have enrolled a FIDO security key, ensure they can sign out of your website using the same UI they used previously with only their username and password.

Outcomes

  • A measure of the strength of an authentication mechanism and, therefore, the confidence in it, as defined in [NIST SP 800-63-3] in terms of three levels: AAL1 (Some confidence), AAL2 (High confidence), AAL3 (Very high confidence). Most device-bound hardware security keys conform to AAL3. 
  • Phishing resistant authentication
  • Build trust from people who seek to protect valuable assets
Customer journey for security keys.

Flow

Step 1

After security key enrollment, the sign-in UI for username and password entry should be consistent with pre-enrollment.

Step 2

Connect your security key prompt, as a second authentication factor at sign-in

Step 3

After security key enrollment, the sign-out UI should be consistent with pre-enrollment.

  • Step 1: After security key enrollment, the sign-in UI for username and password entry should be consistent with pre-enrollment.
  • Step 2: At sign-in, after the user has entered their username and password, display a “Connect your security key” page with a security key icon.
    Allow the user to initiate connecting their key with a “Use security key” button. Include a cancel option. Include a “Sign in another way” option to ensure the user can utilize a back-up method if their key is unavailable.
  • Step 3: After security key enrollment, the sign-out UI should be consistent with pre-enrollment.

Content

Copy and edit user tested content examples to suit your needs.


To set up new sign-in options, visit Security and Privacy after signing in.


When you’re ready to authenticate, click “Use the security key” button.

UX Research

User research suggests that updating the homepage to communicate that a security key had been added to the account was viewed as a privacy and security violation.

The OS/browser dialogs which prompt people to insert their security key are a necessary part of the authentication journey. However, our research suggests that launching directly into the OS/browser dialogues created some anxiety for users who might not have their security key within reach. Users also felt frustrated when retrieving their security key caused the browser dialogue to time out and required the user to restart the authentication process. To mitigate this, after username and password is entered, prompt the user to connect their security key when ready: Offer an option (e.g., a “use a security key” button) for the user to initiate connecting the security key rather than automatically launching the browser dialogue for connecting a security key. 

Our research indicates that the resemblance of a security key to a USB drive leads some prospective users to worry that security keys could contain malware or a virus that might automatically infect a machine when the user inserts the security key into it. Demystifying how security keys work and distinguishing them from USB drives in the “Learn more” text can reassure users and remove that barrier to adoption. Prepare customer support with knowledge about: How to enroll and authenticate with FIDO security keys, which security keys are FIDO Certified and compatible for use with your site, and why FIDO security keys are a safe, secure, and convenient alternative for authentication with your website

The principles in this document were developed following multiple (N = 68) sessions of moderated and unmoderated consumer research conducted by Blink, in collaboration with FIDO UX Task Force members. User research participants included consumers who owned and used security keys, primarily for work, as well as prospective security key users, who used two-factor authentication for personal online banking but had no experience with security keys prior to their research session. Note that our research scope did not include strategies to entice prospective users to purchase keys. In addition to user research, security key second-factor authentication experiences currently in the market were reviewed by the FIDO UX Taskforce and served as input during the research and evaluation process

These recommendations represent perspectives from the FIDO Alliance’s UX Task Force on how to implement MFA for FIDO security keys as a second factor on desktop/laptop for prosumers. For this document, a “prosumer” refers to a security- and privacy-conscious consumer who is an early adopter of security and privacy technologies and services in their personal lives.

Rollout strategy

  • Lead with familiar authentication language and symbols: rather than explicitly promoting the unfamiliar concept of security keys, promote the availability of alternatives to password-only sign in using the familiar fingerprint icon (if biometrics are supported) or other imagery that represents authentication, such as a lock and asterisks for a PIN.
  • Promote the Security and Privacy settings page as the on-site hub for managing and learning about account security in general and security keys specifically: encourage users to visit the Security and Privacy settings page to facilitate the discovery of security keys as a sign-in option. Create a context where users can learn about the nature and advantages of security keys and take action to identify a security key to purchase and/or enroll a security key.
  • Prepare customer support with knowledge about: How to enroll and authenticate with FIDO security keys, which security keys are FIDO Certified and compatible for use with your site, and why FIDO security keys are a safe, secure, and convenient alternative for authentication with your website
  • Strongly encourage users to enroll multiple security keys, to help ensure users are not blocked from accessing their account if a security key is lost or stolen.

Ecosystem

  • This pattern was originally published in 2022. See the 2024 Design Pattern for “Passkey management UI: best practices for combining all passkey types.”

Security

  • This document provides the user experience (UX) guidelines and best practices for relying parties and implementers seeking to enable multi-factor authentication (MFA) with FIDO security keys as a second factor, based on a regulated industry (e.g., banking or healthcare) use case. These guidelines aim to accelerate decision-making during FIDO implementation and specify what information and controls should be given to users. Note that these UX recommendations are optimized for browser-based sites accessed on desktop/laptop computers, rather than mobile apps or mobile web. The guidelines do not, however, include recommendations about security policies or account recovery. 

Code

Passkeys.dev contains the basics to get started with passkey development as well as links to several tools, libraries, references, and demos.

It’s created by the W3C WebAuthn Community Adoption Group and members of the FIDO Alliance.

https://passkeys.dev