Passwords have been doing a lot of heavy lifting for a long time, and not especially well.
The usual conversation tends to focus on password strength: make them longer, make them more complex, do not reuse them, add a second factor. But that does not address the core weakness of the model. Passwords still depend on people recognising the right service, protecting a secret that can be copied and entering it in the right place every time, which leaves them vulnerable to phishing, reuse and sharing.
That is what makes passkeys interesting. They shift authentication away from shared secrets and towards something that is harder to phish, harder to reuse and less dependent on people remembering and managing credentials manually.
At a high level, the difference looks like this:
Instead of asking people to carry more of the burden themselves, passkeys move more of that work into systems that are better placed to enforce stronger defaults, which gives teams a different starting point, even though it does not remove the need for careful implementation.
Passkeys are not new cryptography. They are a new way of using it
One of the most useful ways to think about passkeys is as public key cryptography for the masses. The underlying model is not new, and variants of it already exist in contexts such as SSH and TLS. What is new is the usability layer, which makes it workable for ordinary users without asking them to understand the mechanics underneath.
That matters because passkeys shift more of the burden away from human memory and behaviour and onto devices and authenticators that are better placed to handle it. They are often described as a replacement for passwords and, in some cases, for the second factor as well, but that is an ambitious claim. To understand what they actually change, it helps to first get clear on what makes a passkey a passkey.
What makes a passkey a passkey
All passkeys are FIDO2 credentials, but not all FIDO2 credentials are passkeys. That might sound like a narrow technical distinction, but it has practical consequences, because passkeys are not simply a new label for the same thing. They refine the model in ways that change how authentication works for both users and services, particularly when discoverability, synchronisation and the possibility of usernameless sign in begin to shape the experience more directly.
In simple terms, the difference looks like this:
What matters most here is that passkeys change both usability and flow. Discoverability enables usernameless sign in, while synchronisation makes strong authentication easier to use across devices. That is what makes them feel like more than a standards update.
Under the surface, the model changes in an important way
The most important technical shift with passkeys is that they replace a shared secret with a key pair. The authenticator generates a public and private key, the public key is registered with the service and the private key stays on the device. That means the service no longer stores something equivalent to a reusable secret, and the private key never leaves the authenticator.
Authentication then works through a challenge and response model. The service generates a unique challenge, the authenticator signs it and the service verifies the result, checking both that the challenge matches and that the request comes from the right origin. That is what makes replay attacks far harder and helps bind the credential to the legitimate domain, which is also why passkeys are much harder to phish than passwords.
That only works if a few parts of the implementation are handled carefully:
- The challenge needs to be unique and tied back to the right request.
- The origin and relying party checks need to be verified properly.
- The server-side verification should rely on well tested libraries rather than custom logic wherever possible.
The theory is straightforward enough once you have the mental model, but the verification logic is still easy to get subtly wrong, which is why established libraries are usually the safer choice.
The real work starts when you try to use passkeys in a live service
Understanding the protocol is one thing. Introducing passkeys into a live service with real users and existing sign in flows is where the more important decisions begin.
For most teams, passkeys and passwords will need to coexist for a while, so adoption is rarely a matter of turning one thing off and another on. Conditional mediation, sometimes described as passkey autofill, helps by surfacing a registered passkey as a user begins interacting with the sign in flow, making that transition easier to manage.
There are also decisions to make about what a particular action actually needs to prove. User presence and user verification are not the same thing, and that distinction matters when teams decide how much assurance different parts of a service require.
That leaves teams needing to make deliberate decisions about:
- How passkeys are introduced into an existing sign in journey.
- When users are prompted to use them and what fallback routes still exist.
- What level of assurance different actions within the service actually need.
The protocol can support a lot, but it does not make those judgments for you.
Good passkey UX depends on things you do not fully control
One of the more unusual things about passkeys is that the relying party does not control the whole experience. Much of the interaction sits with the browser or operating system, so the credential picker, prompts and surrounding UI are shaped by the platform rather than by the service itself. That is part of the privacy model, but it does have consequences for teams designing and supporting the journey.
The same sign in flow can look and behave differently depending on the device, browser or operating system a user is on, which makes support content harder to write and issues harder to diagnose. At the same time, for users who stay within one ecosystem, that platform-level consistency can also become a strength because the interaction starts to feel familiar across different services.
That creates a slightly different design challenge. Rather than trying to control every part of the sign in flow, services need to think more carefully about how passkeys are introduced, how the surrounding journey sets expectations and how support works when the UI may vary by platform. That is why passkeys are also a service design question, not just a security or engineering one.
Passkeys do not remove trust. They move it
One of the most important things to understand about passkeys is that they do not remove trust from the authentication model. They move it.
With passwords, more of the trust sits with the service, which stores a secret or a hash derived from one and checks what the user submits. With passkeys, some of that trust shifts towards the authenticator, the device, the operating system and, in many cases, the platform provider responsible for synchronising credentials across devices. The service still verifies the result, but it is no longer the place where every important part of the authentication story lives.
For most consumer services, that is a sensible trade. The point is not that passkeys eliminate risk, but that they change where the important risks sit and often reduce the ones that have caused the most persistent problems for years, particularly phishing, password reuse and shared secret exposure.
That becomes more significant in higher assurance contexts, where teams may care much more about exactly what kind of authenticator is being used, whether credentials are device-bound and how much confidence they can place in the surrounding platform. Once the discussion moves there, the question is no longer simply whether passkeys are better, but what level of trust a particular service actually needs to establish.
Whether passkeys replace MFA depends on what you need them to prove
One of the most common questions about passkeys is whether they can replace multi-factor authentication altogether. The honest answer is that they can, in some contexts, but not in a way that makes the question disappear.
A passkey with user verification can satisfy two factors in a single interaction. There is the authenticator itself, which is something the user has, and there is the biometric or PIN-based check used to unlock it, which is something the user is or knows. On that basis, it is reasonable to say that passkeys can meet a two factor standard without requiring a separate second step in the way many password-based systems do today.
The complication is that both of those factors may sit on the same device. Some security policies will accept that, especially where the main goal is to reduce phishing and remove reliance on shared secrets. Others will want a clearer separation between factors, particularly in environments where stronger device or possession guarantees are required. That means the real question is not simply whether passkeys count as MFA in theory, but what the service actually needs the authentication event to prove.
That becomes even more important when different actions within the same service carry different levels of risk. In some cases, a passkey may be sufficient on its own. In others, a service may still want some form of step up or additional control.
When stronger guarantees are needed
Not all passkey implementations offer the same level of assurance. A synchronised passkey on a mainstream platform may be entirely appropriate for one service, while another may need stronger guarantees about the device, authenticator or provenance of the credential being used.
That is where concepts like attestation start to matter more. In simple terms, attestation is about how much the authenticator tells the relying party about itself when a credential is created, and tools like the FIDO metadata service can help services check whether that authenticator maps to a known and trusted device.
As assurance requirements rise, the real question becomes what kind of trust the service needs to establish. The broader point is not whether one feature is present in isolation, but whether the overall trust model fits the environment the service operates in.
What passkeys really offer
The strongest argument for passkeys is not that they make authentication perfect. It is that they improve some of the weakest parts of the model we have relied on for years.
Passwords ask too much of users. They ask people to create secrets, remember them, protect them, spot when a site is fake and avoid reusing the same details elsewhere, while services continue to carry the risk that comes with storing shared secrets or hashes derived from them. Passkeys change that model by binding authentication to real devices and real domains, which makes phishing much harder, reuse largely irrelevant and credential theft from server side storage far less useful.
They also offer more than a security upgrade on its own. By shifting more of the burden away from memory and manual credential handling, passkeys fit more naturally with the way people already use devices in everyday life. That does not remove the need for judgment, but it does move the model in a direction that is both stronger and more usable.
