Enroll passkeys on security keys

Overview

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

Allow people to enroll security key as a second factor and enroll additional keys (immediately or at a later time), for account recovery.

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.

• Encourage the use of multiple keys.
• Support updating, adding, and the removal of keys.
• Reiterate the value proposition of using a security key.
• Add the ability for the user to add a nickname.
• Consider the optional attestation step.
• Consider the optional user verification step.
• Display enrollment success or error messaging on the security key enrollment landing page.
• At multiple touch points, inspire users to add a second security key for account recovery and backup.

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

Flow

Add security key

Allow people to name their security key before adding it.

Success

Confirm success and prompt to add another.

Step 1: allow people to name their security key before adding it.

• Allow people to exit the enrollment process. 
• Include a security key icon or image.
• Include messaging that describes security keys as a second-factor authentication method.
• Require that people name the security key before adding it.
• Specify that the security key name is only visible to the user (i.e., is not equivalent to a password that needs to be secure).
• Remind people that the nickname serves the purpose of reminding the user which security keys they have registered at a later point in time.

Step 2: confirm success and prompt to add another.

• The user-defined, security key nickname
• A reminder to keep the security key easily accessible for sign-in
• A reminder that only one key is registered and a recommendation that users add more than one security key in case one is lost or stolen
• A directive to keep one security key easily accessible and another stored in a safe place
• Primary action buttons that should be binary responses to the question, “Would you like to add another security key?” Include two equally prominent action buttons, including the option (Yes, add another).
• A “Done” action button as the default, as most users are unlikely to have another security key handy to enroll
• Iconography and text to indicate enrollment was not successful
• Explicit action buttons to re-initiate the security key enrollment or cancel

Additional recommendations

• Encourage the use of multiple keys: At multiple touchpoints, strongly encourage users to add more than one key for account recovery and backup.
• Support updating, adding, and the removal of keys: For every authentication method, including security keys, provide an explicit affordance for updating existing authentication information (e.g., a “change” or “update” button), for removing authentication methods currently in use (e.g., a “remove” button), or adding new authentication methods to the user’s profile (e.g., an “add” button).
• Reiterate the value proposition of using a security key: e.g., “A security key allows you to complete two-step verification conveniently and more securely when signing into DigitalBank.”
• Add the ability for the user to add a nickname: To begin enrollment, require users to enter a nickname of their choice that can be used to recognize the registered key at a later point in time. Specify that the nickname is only visible to the user (i.e., is not equivalent to a password that needs to be secure) and serves as a future reminder to the user of which keys they have registered.
• Optional attestation step: As part of the security key enrollment process, your organization may configure your site to require attestation (i.e., asking the user’s permission to share manufacturer information with your site, such as make and model of their security key). If details are available from the security key manufacturer, requiring attestation will allow for the make and model to be displayed to the user after a security key is enrolled with their account. FIDO Alliance does not recommend adding this attestation step for consumer user cases, because it requires a user to grant permission to your site via an extra dialogue during the security key enrollment process. If your organization opts for a simpler registration process, attestation can be turned off, bypassing the permission dialogue. With this option, details around the make and model of the key would be unavailable to the customer at a later date. Adding this additional attestation step may be valuable for security key enrollment for workforce scenarios.
• Optional user verification step: As a part of the security key enrollment process, your organization may also choose to configure your site to require user verification, meaning asking the user to add a PIN or fingerprint to authenticate with a security key. This optional verification step was out of scope for the research related to these UX Guidelines.
• Display enrollment success or error messaging on the security key enrollment landing page. If security key enrollment is successful, display a success message, with a security key icon and a visual indicator of success (such as a checkmark next to the security key icon). If security key enrollment fails, display an error message to help users understand that enrollment failed and allow them to reinitiate the enrollment process.
• At multiple touch points, inspire users to add a second security key for account recovery and backup. Prior to security key enrollment, provide messaging on the Security and Privacy settings page, encouraging users to add multiple keys. Immediately after security key enrollment, strongly recommend and offer an opportunity to add a second security key, in a manner that requires the user to pause and consider this recommendation. On the “Key successfully added” screen, use multiple strategies for emphasizing that two or more security keys should be used: Headlines: Create a headline emphasizing in bold that “Only one security key is registered.” Text: Explicitly recommend adding at least two security keys in the event that one security key is lost or stolen. Illustrations: Use illustrations to emphasize the state of only one security key being registered and the desired state of two security keys being registered. “Add a second key” option: Offer two action buttons (“done” vs. “add a second key”) that are equally visible and accessible, with “done” as the default action, as most participants likely won’t be ready to add another security key immediately.

Content

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

UX Research

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.

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

Related

• Get answers and join the FIDO-dev group powered by Google Groups.
• Making FIDO Deployments Accessible to people with Disabilities
• FIDO Figma UI Kit
• FIDO Alliance Privacy Principles