In this article, we'll air the 5 most common fallacies we keep running into when it comes to implementing passkeys into the (existing) authentication process, and use a sample calculation to show why it makes sense to look for a specialized provider who really knows their way around passkeys.

Passkeys are beautiful. For the first time in authentication history, not only the security for users but also the convenience is majorly improved. Today, most people are used to unlock their phone with their face or fingerprint. Bringing this user-friendly future to the web is just the logical next step. Together with the underlying public-key-infrastructure that leverages asymmetric cryptography, passkeys seem like the perfect solution. That's true from an end user perspective, but for organizations, implementing this new authentication standard in-house is a huge effort that involves high risks and costs. This article explains the most common fallacies about passkeys and how to mitigate them.

First of all, passkeys are based on open standards defined by the FIDO (Fast Identity Online) alliance where all major tech players, like Microsoft, Apple, Google and others like PayPal, eBay or Visa belong to.

However, these open standards are poorly documented, making implementation into existing systems and integration into user flows challenging in practice. It requires to come up with defining user flows as well as technical integrations from scratch. To add passkeys to your existing system, the basic documentation and implementation is just not enough practice if you already have authentication for your existing users in place.

Moreover, the struggle really begins if you have users from different platforms (iOS, Android, Windows) using multiple devices as passkeys are (partially) device-bound. The implementation as well as the user experience varies depending on the platform, making it a complex endeavor to offer passkeys as the preferred login method to all your users. Especially nowadays, where many users have more than one device, it is essential to properly support all devices and operating systems.

Theoretically, this is correct but there are inherent costs, especially for the integration and maintenance. Initially, you need to work on a concept for process flows and UX which is usually executed by 1-2 product managers . This can take up to 2 months and, depending on the experience of the product managers, can cost up to $30,000 alone. Once this is done, system architects, product managers, and developers who integrate this solution are required. Then, you have maintenance efforts, e.g. for running the FIDO2 server. Moreover, you need to take care of a smooth user transition in order not to overwhelm your users, which is very complicated to design and implement internally, and thus costly.

Additionally, you need to run the infrastructure: servers and databases are not for free today. Especially, if you need them securely and reliably running with great availability at such a critical point in your application. This all costs a lot of money that you better want to spend on your core features.

Furthermore, other external players to provide the surrounding (fallback) systems like email or SMS services need to be selected, managed, and monitored. Of course, you can also do that on your own, but your users expect blazingly fast delivery of transitional emails and high availability. Trust us, you do not want to optimize email delivery on your own. These services are not for free and add to the costs.

When talking to customers, this is probably the most common misconception and the true struggle of authentication. Offering passkeys for a new greenfield application can be done pretty straight forward. The tricky part is transitioning existing users to passkeys. Most of the time, the user base is quite heterogeneous as there are early adopters who would love to drop their passwords better yesterday than today and go for passkeys as soon as possible. On the other hand, you have people who like to stick to their passwords. Coming up now with different individual flows while smoothly and smartly taking all users towards passkeys is the real challenge.

After the initial integration, many people think that passkeys just work on their own and that the adoption will come by itself. That's another common misconception as passkeys are a security-critical feature bringing many risks. This means they need to be monitored and the team monitoring them needs to be experts in security with a lot of experience.

Moreover, the adoption of passkeys needs to be continuously monitored to detect potential issues in the transition phase that require changes in the implementation.

Before even thinking about the technical implementation of passkeys and getting down to coding, a lot of conceptual work must be done first. Especially, when it comes to integrating a new technology like passkeys, where the quality and quantity of existing best practices and documentation is low, many conceptual processes need to be considered. Among the most important are:

1. Scribbling down the entire sign-up and login process: When designing the flow from the beginning of sign-up or login to successful authentication, countless process steps run in the background. These need to be modeled and structured in complex logic trees. The design of the standard cases alone is a complicated task, which is absolutely not comparable to the even much greater effort required to cover all possible edge cases. Ultimately, there must be an authentication process that works in every potential scenario and authenticates the user.
2. Taking care of cross-platform usage: It is crucial to make sure that users can use passkeys both cross-device and cross-platform while smoothly guiding them through the authentication processes even when passkeys are not yet available.
3. Ensure backwards compatibility: To promote the use of passkeys, it is necessary to develop a mechanism that not only automatically detects the passkeys-readiness of all devices the user wants to authenticate with, but also notices whether the users want to log in with passkeys in the first place. If users, instead, prefer to continue with current login options like passwords, social logins or SSO, hybrid authentication needs to be run in parallel.
4. Providing recovery services: It may sound obvious, but coming up with a flow for self-service password resets and possible fallback options in case of errors is one of the most challenging tasks as you need to guarantee that users can authenticate in case they have forgotten their password or never set one.
5. Designing a great UX: UX is much more than just creating a user-friendly interface. For software in general, device and user preference management, user communication, and customizable design for your CI play a major role. Since passkeys are device-bound, companies need to focus primarily on device management to ensure that the use of passkeys works flawlessly for all their users' devices. When it comes to user communication it is necessary to educate your users with predefined and tested user messages.

All these steps require product managers and developers many hours and is often swept under the table in software development.

The build-versus-buy software debate is anything but new. When deciding on this, you must take many factors into account. The key factor for any company is the cost block that comes from developing or purchasing the software. When software solutions, e.g. for passkey authentication, are purchased, the argument is often made that the upfront costs are very high. However, companies usually forget that homemade development is at least as expensive, since its costs depend, for example, on the complexity of the software itself, the product management, the UX/UI design, the development team and often many hidden costs (especially maintenance and updates).

To shed some light on the cost of developing authentication software, here's a basic calculation for a company with an in-house authentication team that offers their services for desktop, mobile and native app users. Besides email/phone number and password authentication, they also have social logins:

• 2 backend developers: $126,000
• 1 frontend developer: $60,000
• 1 iOS developer: $60,000
• 1 Android developer: $68,000
• 2 product managers: $170,000
• 1 project manager: $85,000

Please note that these are total annual salaries and are based on average salaries by industry standards according to Glassdoor, excluding non-wage labor costs.

• Duration: 1.5 months
• Stakeholder of software development team: 2 product managers, 1 project manager
• Total costs (salary): $31,875

Desktop/Mobile)

• Duration: 3.0 months
• Stakeholder of software development team: 2 product managers, 1 project manager, 2 backend developers, 1 frontend developer, 1 iOS developer, 1 Android developer
• Total costs (salary): $143,750

Total software development costs: $175,625

Of course, this is a simplification that does not take into account many costs, such as transition or training costs. In case you need extra infrastructure like servers and databases or cloud services you will be hit by additional costs. Especially for authentication software that needs to protect personal data to the maximum, the costs are probably significantly higher, so it is worth using dedicated passkey providers like Corbado.

To sum it up: passkeys are an open standard that anyone can integrate for free. But this is very short sight. When taking a closer look at the implications of passkey usage, it becomes obvious that using a passkey provider like Corbado is the much more intelligent and cost saving way. Especially, as authentication is rarely a core feature and more a commodity that needs to be done in a modern product, leveraging the know-how and capabilities of an external expert is just clever.

Still not convinced? Try Corbado's solution for free and without any risk today.