Lately, I've started seeing the "Sign in with Passkey" option on many platforms. Initially, like with any new technology, I approached it with some distance, wondering if it was just a passing fad. But my quest to improve the user experience in my own side projects, combined with security dilemmas in the corporate projects I work on, pushed me to look deeper into this topic. Especially with the increase in phishing attacks over the last few years and the inadequacy of multi-factor authentication (MFA) in certain scenarios, Passkeys have shown me why they can be an important solution.
Many times, I've seen that password management can turn into a real nightmare for users. Complex passwords, regular password changes, different passwords for different sites – even the most well-intentioned user ends up resorting to weak or reused passwords. This situation also makes it impossible to enforce corporate security policies. Passkeys aim to break this cycle, both increasing security and offering a much easier login experience for the user. In this post, I will start with the basic logic of Passkeys, then touch upon the adaptation challenges in both the individual and corporate worlds, and my practical experiences on this topic.
The Core Logic of Passkeys and Their Superiority Over Traditional Methods
Passkeys are a passwordless authentication method based on the WebAuthn standard developed by the FIDO Alliance and W3C. At its core lies public-key cryptography. This means that when a user creates a Passkey for a service, a private key is generated on their device (phone, computer, hardware security key) and a public key pair on the service side. When logging in, your device generates a signature with the private key and sends it to the service, and the service verifies this signature with the public key. This mechanism, unlike classic passwords, never sends a secret (password) to the server, thus showing natural resistance to phishing attacks.
In traditional password-based systems, your username and password are stored as hashes on a server. In the event of a data breach, these hashes can be stolen, and your passwords can be cracked through various attacks (rainbow table, brute force). With Passkeys, only the public key resides on the server, and the private key never leaves your device. This ensures that your private key remains secure even if there's a server-side breach. Furthermore, while even two-factor authentication (2FA) can be bypassed through SIM swap attacks or malicious applications, Passkeys significantly reduce such risks because they are tied to your device. In my own Android spam application, I am seriously considering Passkeys as an alternative to reduce the constant password reset requests from users. Considering the burden on a system that receives an average of 15-20 password reset emails per day, the convenience brought by Passkeys would be a huge gain for both the user and the operational team.
ℹ️ Private Key Security
The private key in Passkeys is stored in your device's secure hardware (Trusted Platform Module - TPM, Secure Enclave) and is not directly accessible. This makes it difficult even for malicious software to steal the private key. Additionally, to ensure the private key is useless on its own, it must be protected by an additional factor such as biometric verification (fingerprint, facial recognition) or a PIN. I liken this structure to a classic HSM (Hardware Security Module) logic, but on a much more widespread and accessible scale.
My Passkey Experience in Individual Use
I have actively started using Passkeys in my own individual digital life. Especially within the Google, Microsoft, and Apple ecosystems, this transition has been quite smooth. First, I secured my Google account with a Passkey. Being able to log in within seconds using the fingerprint reader on my phone eliminated the hassle of classic password and 2FA code entry. I no longer experience those "oh no" moments I used to have when I forgot my phone or when the 2FA app code didn't arrive. The login flow ending with just biometric verification incredibly speeds up and simplifies the user experience.
When designing user login for my side product's financial calculators, I piloted Passkey integration. My goal was to minimize friction in the user registration and login processes. While I observed an average abandonment rate of 15% for traditional email/password-based logins during initial registration, with Passkeys, in my first trials, this rate dropped below 5%. The main reason for this was that users were freed from the burden of thinking of a new password, remembering it, and then forgetting it again. Especially on mobile devices, logging in with a single tap and biometric verification increased user interaction with the application. Creating a Passkey took an average of 12 seconds for a user, while traditional password and 2FA setup could take an average of 45 seconds. This time difference is quite significant, especially for mobile users. Of course, this data comes from a small sample size, but the potential is huge.
💡 Passkey Synchronization
Most Passkey providers (Apple Keychain, Google Password Manager, Microsoft Authenticator) offer the ability to synchronize your Passkeys across devices. This means that even if you lose one device, you can access your Passkeys from another secure device. For me, this feature provides great convenience, especially when I constantly switch between different devices. However, it's important to remember that this synchronization also has its own security risks; how secure the synchronization service is, is an important question.
Challenges of Corporate Adaptation: Initial Hurdles and Trade-offs
While Passkeys offer a great experience in individual use, the adaptation process in the corporate world is much more complex. When evaluating a Passkey integration project for an ERP system in a manufacturing company, the first obstacle we encountered was our existing identity management infrastructure. Most corporate structures use Active Directory, LDAP, or custom Identity Providers (IdPs) based on SAML/OAuth2. Seamless integration of Passkeys into these existing systems requires significant architectural work. Extensive updates are needed for existing "fat client" applications, remote desktop connections, or legacy web-based systems to support Passkeys.
In our scenario, we had a Vue frontend integrated with a PostgreSQL-based ERP backend via FastAPI. While using WebAuthn APIs on the frontend was relatively easy, the backend needed to manage this Passkey verification flow and map it to existing user tables. Our existing user tables contained password hashes and 2FA settings, so we needed to add new "credential_id" and "public_key" fields for Passkeys. Additionally, we had to design a "recovery" mechanism for users who lose their Passkeys or change devices. This recovery mechanism itself can pose a security risk, so it needs to be planned very carefully. For example, we had to make a trade-off: allowing a user who loses their Passkey to be verified with an existing email/SMS-based 2FA to create a new Passkey. While this partially reintroduced the phishing risk, it prevented the user from completely losing access to the system.