Passkeys and Passwords: A Balanced Assessment
For roughly sixty years, the password has been the default way a person proves who they are to a computer. It is also among the most criticized technologies in everyday use. Passkeys, built on the FIDO2 and WebAuthn standards and supported by the major operating system vendors, promise to replace shared secrets with public-key cryptography. This essay argues that passkeys are a substantial improvement in security and usability, but that their benefits depend on recovery, portability, and governance questions that remain unsettled. The case for and against deserves equal rigor, because a login method is infrastructure: once it is adopted at scale, its flaws become everyone’s problem.
How passwords work, and why they persist
A password is a shared secret. The user memorizes a string, the service stores a transformed version of it, and each login compares the two. The design dates to early time-sharing systems in the 1960s, when a handful of users sat at terminals connected to one machine. Its appeal is easy to state. It requires no special hardware, works on any device with a keyboard, can be created in seconds, and can be changed at will. A person who understands the concept needs no further training.
Those strengths explain why passwords have outlasted every proposed successor. They are universal, they are portable in the most literal sense because they live in a person’s memory, and they place the user in control without depending on any particular vendor. A password written in a notebook can be carried to a new phone, a new country, or a new operating system. No other mainstream method matches that independence.
The weaknesses of shared secrets
The difficulty is that a shared secret must be guarded by both parties, and the user is the weaker guardian. People reuse passwords across services because memorizing dozens of unique strings is unrealistic. When one service is breached, attackers try the leaked credentials elsewhere, an attack known as credential stuffing. Passwords can also be phished: a convincing fake login page captures whatever the user types, and the user has no reliable way to distinguish the fake from the real page by eye.
Server-side storage adds another layer of risk. Well-run services store salted, deliberately slow hashes rather than the passwords themselves, but not every service is well run, and a stolen database of weak hashes can often be cracked at scale. Defenses such as password managers, length requirements, breach checking, and one-time codes sent by text message or generated by an app each close part of the gap. Yet each also adds friction, and codes delivered by text message can be intercepted through SIM swapping, while codes typed into a fake page can be relayed to the real one in real time.
What passkeys change
A passkey replaces the shared secret with a key pair. When the user registers with a service, the device generates a private key that never leaves it and gives the service the matching public key. At login, the service sends a challenge, the device signs it after the user unlocks the device with a fingerprint, face scan, or PIN, and the service verifies the signature with the public key. The biometric or PIN is checked locally; it is not sent to the service.
Two consequences follow, and they are the heart of the case in favor. First, there is nothing reusable to steal from the service. A breached database contains public keys, which are useless to an attacker. Second, the credential is bound to the legitimate website’s domain, so a phishing site on a different domain cannot obtain a valid signature even if the user is fooled by its appearance. The user is no longer asked to be the last line of defense against deception, which is a task that humans perform poorly under time pressure.
There is a usability argument as well. Unlocking a phone with a fingerprint is faster than typing a long string, requires no memorization, and is the same gesture the user already performs dozens of times a day. For services that adopt passkeys well, the login flow becomes shorter rather than longer, which is unusual for a security improvement.
The case for passkeys
The strongest argument is that passkeys remove entire categories of attack rather than raising the cost of each. Credential stuffing fails because no credential is reused. Server breaches yield nothing directly usable. Phishing fails because the cryptographic check includes the site’s identity. In a field where defenders usually add layers that attackers then work around, eliminating the underlying weakness is rare and valuable.
A second argument concerns who bears the burden. Password security has long been framed as a user responsibility, with advice to choose longer strings, avoid reuse, and stay alert. That framing places a continuous cognitive load on people who have other things to do. Passkeys shift the burden to software and standards, where it can be engineered once and applied consistently. A third argument is accessibility in the broad sense: many people struggle with complex passwords, forget them, and rely on reset emails that are themselves a security weakness. A method that depends on a device unlock the person already uses may serve those users better.
The case against, or at least for caution
The weaknesses of passkeys are practical rather than cryptographic, and they are not trivial. The first is recovery. A private key lives on a device, and devices are lost, broken, and stolen. To mitigate this, major platforms sync passkeys through a cloud account, which means the security of the passkey now depends in part on the security of that account and its own recovery process. If an attacker can take over the account that syncs the keys, the strength of the underlying cryptography matters less. The recovery path becomes the new weakest link, and many services still fall back to email resets or support calls, which reintroduces the problems passkeys were meant to remove.
The second concern is portability and lock-in. A password can move anywhere. A passkey stored in one vendor’s ecosystem may be awkward to use on a device from another, and although standards work and password-manager support have improved the situation, moving credentials between providers has not been uniformly smooth. A user who leaves an ecosystem may find that part of their digital identity is tied to the one they left. Critics reasonably worry that a login method controlled by a few large platforms concentrates power in those platforms, including the power to change terms or lock accounts.
The third concern is adoption and the long tail. A passkey is only useful where a service supports it, and many services will keep passwords for years as a fallback. While both options exist, an attacker can simply target the weaker one. Security gains arrive only when the password path is closed, and closing it harms users who cannot or will not use the new method, such as those with older devices or shared computers. Shared and public machines are a particular difficulty, since a passkey usually assumes a personal device that the user trusts.
A fourth point is comprehension. Many people understand a password because they can picture it. A passkey is an abstract object, and users may not know where it lives, how many copies exist, or what happens when they replace their phone. Confusing interfaces and inconsistent naming across vendors have slowed trust. Technology that people cannot explain tends to produce errors at the margins, and the margins are where support burdens and security incidents accumulate.
Weighing the arguments
The two sides are not symmetrical in kind. The case for passkeys is mainly about the cryptographic design and the attacks it prevents. The case against is mainly about deployment: recovery, portability, concentration of control, and the transitional period. Both are legitimate, and neither refutes the other. A well-designed protocol can still be undermined by a poor recovery process, and a messy rollout does not make the underlying protocol unsound.
It helps to separate the question of whether passkeys are better than passwords in principle from the question of whether a given deployment is better in practice. On the first, the evidence from the structure of the attacks is strong: phishing resistance and the absence of reusable server-side secrets are real properties, not marketing. On the second, the answer varies. A service that offers passkeys with a rigorous recovery process, clear explanations, and an actual path to retiring passwords delivers most of the promised benefit. A service that adds passkeys on top of passwords, reset emails, and text-message codes may deliver little more than a convenience feature.
Password managers deserve mention as a middle path. They address reuse and weak choices while keeping the portability of a shared secret, and many now store passkeys too. For a user who is not ready to depend on a platform account, a manager that exports its data in open formats offers some of the benefits of both approaches. It does not stop a user from typing a password into a convincing fake page, however, so it only partly closes the phishing gap.
Implications for developers and organizations
For those building services, the practical lesson is that adopting passkeys is as much a product and support decision as a technical one. The login flow is easy to add; the recovery flow is where the work lies. Organizations should decide in advance how a user regains access after losing every device, how that process resists social engineering, and whether passwords will eventually be removed. Without answers, the new method inherits the old method’s weaknesses through the back door.
For individuals, a sensible approach is incremental. Enable passkeys where they are offered by services that matter most, such as email, banking, and primary accounts, and keep recovery options current. Treat the account that syncs the keys as critical infrastructure and protect it accordingly, with strong authentication and recovery contacts the user actually controls. Continue to use unique passwords, ideally from a manager, wherever passkeys are not yet available.
Conclusion
Passkeys are a genuine advance on a technology whose flaws have been understood for decades. They remove reusable secrets from servers, resist phishing by construction, and can make logging in faster. Their limitations, though, are real: recovery that can reintroduce old weaknesses, uneven portability, dependence on a small number of platforms, and a long transition during which passwords will persist. The reasonable position is neither enthusiasm nor dismissal. It is to recognize that the cryptography has largely solved the problem it was designed to solve, while the surrounding human and institutional systems still have work to do. Judged by that standard, the passkey is best seen as a strong foundation that is not yet a finished building.
GenM Software Team
