Change Management Required to Gradually Adopt Passkeys
The end-to-end process to implement support for passkeys requires careful change management. Anticipating this from the start of your process can help to remove barriers that cause re-work or frustration. This requires teams to be capable of managing change. For example, change management capabilities include bridging communication silos that might exist between departments or disciplines, understanding and helping to define the dependencies between departments or disciplines, cross-departmental budgeting, and cross-departmental collaboration.
Organizational buy-in
The Roll-Out Guide - Gradually Adopt Passkeys is designed to mitigate common barriers to organizational buy-in for passkeys. Many passkey project leads are able to receive buy-in from their organization to proceed with this strategy because it does not require the amount of effort that other strategies require. The other strategies require multiple presentations and follow-up conversations with multiple departments in various regions. However, this strategy requires little to no buy-in or approvals from marketing because no coordinated marketing campaign accompanies the initial launch of passkeys. This strategy requires little buy-in from product and user experience teams because the product changes are minimal and isolated to the user's Account Settings interface as defined in the design pattern: Create, View, and Manage Passkeys in Account Settings.
One way to simplify organizational buy-in is to limit initial passkey implementation to a single important use case on a particular operating system. For example, some online services may want to start with the use case “I want to leverage passkeys to help users with new iPhones painlessly sign in to my app or website”. For this use case, the only surface where passkey implementation is needed is for iPhones.
This tactic keeps costs and scope for initial launch minimal yet still allows your organization to measure and compare actual passkey-related benefits in your unique business context. Later, support for more use cases on additional operating systems can be added.
For many organizations, the individual who first investigates this guide can also approve the project. If this is not the case for your organization, you need to complete a process to identify the decision-maker who can approve the passkey implementation project. There might be a single decision-maker or a committee of decision-makers that needs to approve the passkey project.
Cross-organizational planning
By design, this guide allows a single team within a single department to complete all of the major tasks the integration requires. Minimal cross-organization planning is required for this guide. For example, the team will require little to no collaboration with the risk and fraud departments because existing authentication methods remain in place. The team does not require collaboration with marketing departments because this strategy has no major marketing campaign. This strategy is only applicable to a single region, with a limited use case, and requires no collaboration with departments in other regions of the world.
Compliance and legal
Passkeys introduce a new authentication modality to your environment, and there are tasks you need to complete to manage compliance, risk, and legal changes regarding digital identity and authentication. Inform your compliance and legal team early in your investigation that your organization is evaluating the use of passkeys. If they are not yet familiar with passkeys, suggest that they read Giving NIST Digital Identity Guidelines a Boost, the National Institute of Standards and Technologies (NIST) guidance for passkeys. NIST guidance states that synced passkeys meet Authentication Assurance Level 2 (AAL2). While not all organizations are required to follow NIST guidance and NIST is a function of the United States government, companies in most regions of the world and in various industries regularly reference NIST as an authoritative source.
It is common for legal teams to require that their users be able to remove a passkey from their account. FIDO Alliance recognizes this and has created a design pattern for the removal of passkeys. This design pattern is backed by user experience research and has proven to be a reliable user experience model to achieve this legal requirement when needed. In addition to fulfilling the common requirement from legal teams, this design pattern increases user trust and satisfaction by empowering people to control their security settings and remove passkeys. It can lower support costs and resources required to handle requests related to forgotten, lost, or compromised passkeys.
Information technology (IT)
This roll-out strategy requires minimal IT architecture changes because all existing authentication technology infrastructure remains in place and is unchanged.
You need to plan for the addition of a FIDO Certified server and code base to the support the two FIDO Get Started design patterns for passkeys.
As you plan the technology requirements, consider the long-term vision for your authentication architecture with passkeys. One consideration is to learn how passkeys are scoped to specific domains. Even if your initial launch exists on a single domain, you might have long-term requirements for multiple domains. For example, marketing initiatives might launch micro-sites using subdomains, or occasionally launch new domains, and some of those micro-sites might require authentication services with passkeys. While this is just one of the many IT considerations when implementing support for passkeys, the breadth of IT change management for this strategy is relatively small.
Authentication policy
Some organizations use technologies to assess the risk of authentication events. Telemetry signals (such as IP address, operating system version of the authenticating device, Wi-Fi fingerprints) about the identity seeking to sign in are processed by a set of business policies that determine the next step for a user. The technologies might allow them to sign in, might require them to perform additional steps to sign in, or might block them from signing in, while simultaneously recording this data for further analysis. The set of technologies and systems used to perform this work is commonly called a risk engine.
Because passkeys have unique security characteristics, such as phishing resistance, companies can choose to integrate passkeys with risk engine policies. For example, if a user creates a passkey, but then attempts to authenticate using a password and a device the risk engine has not previously seen this user use, then the risk engine could place limits on what kinds of transactions the user is approved to carry out until they are identified as the correct account holder. This is just one example of risk engine policy enhancements that can be made with the introduction of passkeys. There are many policy enhancements that can be made by following many different approaches.
This strategy assumes that no initial changes to risk engine policies need to be made. However, after the initial launch and over time, risk policies can be enhanced for user accounts that have registered passkeys.
User experience
The effort of change management required to optimize the user experience for the gradual roll-out strategy is significant. If not managed well, the user experience will be negatively impacted.
For example, there are passkey workflows engineers understand, but UX designers or content strategists might not. It is possible that the engineers might not have enough time, user experience knowledge, or user experience research insights to optimize the user experience of the workflows.
For most roll-out strategies, the change management effort required to optimize the user experience is significant. Individuals who do not specialize in user experience will need to make decisions that will have direct impact on the user experience. If this is not managed well, the user experience will suffer.
Another example is that changes to the authentication policy and decisions around technical architecture can affect the user experience. Also, users on different operating systems will have different experiences with passkeys, which also affects the user experience.
This is why it is important to consider whose job it is to understand, document, and resolve user experience topics that require collaboration between product, engineering, content strategy, IT, legal, and user experience design teams. You should plan for this job to be nuanced and time-consuming. You will need to communicate user experience decisions to the organization and properly solve them throughout the organization.
To help with this work, team members working on passkeys should read and follow the Design Guidelines.
As you work through the build and test phase, you will discover inconsistent technology between browsers, operating systems, and credential managers (password managers). You will encounter barriers to some passkey use cases and discover unhappy paths in the user journey. To understand these challenges in advance, reference Troubleshooting before, during, and after this phase. The Troubleshoot section contains learnings and guidance from FIDO Alliance member companies from their implementation of support for passkeys and will save you time during your own implementation.
User education
With this roll-out strategy, your organization does not proactively educate users about passkeys. Instead, users learn about the option to use a passkey organically when they visit their Account Settings. This dramatically reduces the amount of change management required to rapidly educate your users about passkeys.
