What if we finally got rid of the password, but kept all the vulnerabilities that came with it?
Passkeys are no longer just a lab experiment. By May 2026, the FIDO Alliance estimates the number of passkeys in circulation worldwide at 5 billion. 75% of consumers have activated at least one, and Microsoft, Google, and Apple have made them their default login method. On paper, the password is disappearing.
Yet, in the corporate world, 57% of organizations still rely on passwords for their employees' primary login, and identity fraud is not declining. The problem isn't the technology. It's what we expect from it.
This article shows what passkeys really solve, what they leave out, and why the real question is no longer "how to log in" but "who is logging in."
The promise: a secret that can no longer be stolen
The password has a design flaw that nothing can fix: it is a shared secret. The user knows it, the server stores it (as a hash), and anyone who obtains it can use it. Phishing, database leaks, reuse across multiple sites: all classic attacks exploit this same principle. The CNIL points this out in its 2022 recommendation on passwords : it is the easiest authentication method to deploy, but also one of the most fragile.
The passkey breaks this model. It is based on the W3C WebAuthn standard and on a pair of cryptographic keys: the private key remains on the user's device; the server only knows the public key. There is nothing left to steal on the server side, nothing left to type on the user side, and the key is bound to the legitimate domain, which makes classic phishing ineffective.
This is a real breakthrough. Regarding authentication itself, the passkey is more secure, faster, and simpler than anything that came before it. On the corporate side, the FIDO Alliance reports 45% faster logins and 32% fewer phishing incidents. Furthermore, the ANSSI recommends, in its guide on multi-factor authentication, to prioritize factors based on cryptography. The problem is that passkeys are often presented as the end of fraud, when they only cover part of it.
What passkeys don't solve: 3 blind spots
If passkeys aren't enough, it's not a flaw in the technology. It's because they answer one specific question while we are asking them three others.
1. The recovery process remains the weak link. A user loses their phone, switches devices, or loses access to their cloud account. You have to allow them to get back in. In most cases, this recovery still relies on an email, an SMS, or an answer to a security question. The attacker no longer needs to steal the passkey: they just need to go through the back door and enroll a new one.
2. The synchronized passkey depends on the account that synchronizes it. For the sake of convenience, most passkeys are synced via iCloud, Google, or a password manager. Their security therefore depends directly on the security of that account. They can even be shared voluntarily with others. For a bank or fintech company, this raises a question that the PSD2 has not yet fully resolved: does a key that travels between devices still prove the "possession" required by strong authentication? The European Banking Authority clarified in 2019 that possession is not limited to a physical object, but the case of synced keys remains debated. In the United States, NIST even dedicated a specific supplement to its guidelines in 2024.
3. A passkey authenticates a key, not a person. This is the most significant blind spot. A passkey proves that the device connecting holds the correct key. It says nothing about the person holding that device or how the account was created. This is the entire difference between identity verification and authentication. If the onboarding process was fraudulent, the passkey perfectly protects... the fraudster's account.
These three blind spots have one thing in common: none of them are flaws in the passkey itself. They exist around it—at account creation, during recovery, and in the link between the key and the human. The cryptography is solid, but everything surrounding it still relies on weak evidence.
This is what makes the subject deceptive. You can deploy passkeys everywhere, show record adoption rates, and remain exposed to the exact same fraud scenarios as before. The risk is no longer in the password; it has shifted to identity.
The new paradigm: linking the key to a verified identity
The current model works like a keychain: we verify that the right key opens the right door. The new paradigm adds a question that the key cannot answer on its own: does this key actually belong to the person we identified?
In practical terms, this means anchoring the passkey in a verified official identity and requesting this proof of identity at times when the key alone is no longer sufficient.
For a product decision-maker, the question changes. It is no longer a matter of asking "should we switch to passkeys?", since the answer is yes. The question becomes "at what points in the user journey do we need to prove that it is the right person, and not just the right device?"
Four moments come up consistently: enrolling the first passkey, adding a new device, account recovery, and sensitive operations (transfers to a new beneficiary, changing contact details, unusual amounts). These are precisely the points where attackers focus their efforts because the passkey provides no guarantee of identity there. This is the principle of recurrent authentication : trust is verified when it matters, not just once.
Passkeys for everyday use, identity for key moments
The goal isn't to add friction everywhere. The passkey remains the default login method: fast, invisible, and passwordless. Identity verification only kicks in when the risk level justifies it. Standard login: passkey only. New device or recovery: biometric verification with liveness detection, linked to official identity. Sensitive operations: strong authentication proportional to the risk, with the dynamic linking to the transaction that PSD2 technical standards require anyway.
What this means for product teams
Three design choices have no universal answer: the level of proof required at enrollment (declarative, KYC, official identity), the recovery policy (what replaces email and SMS), and the management of synced passkeys in regulated journeys. These choices depend on the context, as illustrated by the two following cases.
Concrete examples
The hijacked recovery : an attacker obtains a duplicate of their victim's SIM card. They claim to have lost their phone, receive the recovery code via SMS, and enroll a new passkey on their own device. From that point on, every one of their logins is technically perfect: phishing-resistant, passwordless, and cryptographically validated. The system sees nothing abnormal, as everything is working as intended.
What this implies: a passkey is only as strong as the process used to create a new one. If recovery relies on SMS, the actual security of the account is that of an SMS. Requiring identity verification linked to an official document every time a device is added closes this loophole without penalizing the user in their daily experience.
The borrowed account : a user opens an account by passing KYC with their real documents, enrolls a passkey, and then hands over their device or shares their passkey with a third party. This third party uses the account to move funds. Every login is authenticated, and every transaction is signed with a valid key. For the platform, it is still the original client acting.
What this implies: a passkey proves possession of a key, not the presence of a person. KYC verified an identity on the day of opening; the passkey verifies a device at each login, but nothing verifies that the two are still the same person. A biometric confirmation linked to the verified identity, triggered for sensitive operations, fills this exact gap.
The passkey is a key, not an identity
The passkey marks the end of the password as a shared secret. It does not mark the end of identity fraud.
The question is no longer whether the user can log in without a password, but whether the person logging in is who we think they are. As the previous examples show, attacks no longer target the login itself; they target what surrounds it—namely, enrollment, recovery, and the link between the device and the human.
Adopting passkeys is a necessary step. Stopping there just shifts the problem without solving it. Truly robust authentication combines both: the key for fluidity, and identity for trust.
The real question for product teams is therefore to determine at which points in their journey a key is no longer enough. Answering this means building authentication that holds up—not just at login, but at every moment where identity truly matters.
That is precisely what ShareID has built: an MFA 3.0 that links authentication to a verified official identity, reusable for enrollment, recovery, and every sensitive transaction, with no friction for the legitimate user, no stored data, and no compromise on compliance. Not just another key, but an identity behind every key.
.png)