Reduce Passwordless Drop-Offs with A/B Tests and Insights

The movement towards a passwordless world has started offering great potential to alleviate one of the internet’s bigger security problems: stolen passwords. There are many different types of passwordless options available, each varying in security, complexity of configuration and rollout, and the end-user experience. Although all of them are more secure than the traditional username/password approach, they remain unfamiliar to most users.

The approach of using a username coupled with a password does have its advantages in how simple it is. It’s easy for users to understand what to do. Other common authentication options that applications typically use - such as federated logins - are generally straightforward, in part because they often rely on the same username/password format. MFA methods, for instance, using an authenticator apps or receiving a code via email or SMS, can be more complex for some users, but they are still relatively familiar.

Challenges arise for many users when adopting passwordless authentication such as Passkeys or other options that for example involve a hardware token or a FIDO-based authentication application.

The Migration

In order to make the passwordless migration as seamless as possible for users and customers, it is very important to consider several aspects: Who are the target users? Are they tech-savvy or not? Where are they geographically located and what type of device(s) are they using? etc.

All of this data will guide the design and orchestration of the authentication flow. There will not be one single lane journey for all users. It is very likely that several alternative options will have to be implemented depending on the type of user and other environmental factors. Contextual information will determine which specific flow the user ends up in.

Identity Proofing

If there is already an established user base with existing authentication mechanisms in place, then these can be used to identify the user when registering a passkey. However, it’s also important to account for the new user registration scenario. The Curity Identity Server has several supporting mechanisms to identify the user during registration/sign-up, ranging from different authenticators to more purpose-built authentication actions that are used for registration.

Fallback

Authentication options to fall back on are especially important when designing your passkey architecture. The traditional username/password approach basically works everywhere. Passkeys are only supported on certain platforms/browsers, and if the user needs to authenticate on an unsupported system, alternative authentication options must be available. The possible fallback options may vary depending on the context and might not always be the same for all users in all scenarios.

type: embedded-entry-inline id: 53TjLIgXmWsRVlaGZLHDD2

Passkey/Device Management

When using passwords, users have the option to reset them when forgotten or compromised. A similar process is necessary for passkeys. There can be different approaches, but one example is when you use a hardware FIDO device such as a YubiKey to store the passkey. If the device is lost the user needs to be able to invoke a flow that can handle creating a new passkey. Users will need to have some type of self-service portal or account management option where they can manage their passkeys and/or devices that hold passkeys.

A/B Testing

In order to determine the best possible approach for different types of users, it will be necessary to perform testing. This is obviously something that can be done before anything is deployed to production, but the testing here will be very limited. Real-life scenarios with different devices and/or browsers used by a multitude of different users will be very difficult to predict and test.

A/B testing will help realize what types of approaches and flows are more successful and work best for different user types under various circumstances. This will result in additional input data that will be used when designing the orchestrated authentication flow. This type of insight will be critical in driving the design decisions for the Passkey authentication journey in order to minimize user drop-off.

Conclusion

Implementing Passkeys is not always as straightforward as it initially looks. It's a simple authentication mechanism for users, but it involves a significant amount of complexity in its configuration in order to be as seamless as possible for the user. If there is too much friction in, for example, the registration flow, you might end up losing the user altogether. 

Using contextual information to determine who the users are, what device and browser they are using, options for identity proofing, fallback options, and device/passkey management can be designed. This, coupled with A/B testing, helps define the best possible options for various users in order to minimize friction and avoid drop-off.