Passkeys 101: What They Are, How They Work, and Why They Beat Passwords

Passwords have been the go-to technology for authenticating a user for over 65 years. We kept tinkering around the edges to try and beef up their security, but in today's cybersecurity landscape usernames and passwords are considered fundamentally flawed and obsolete.

Their time is up. They get stolen, phished, reused, guessed, and tricked out of us by fake websites and other sophisticated methods. They cannot provide the security we need in the next revolution, one that includes AI and quantum computing. Passkeys are the replacement that fixes most of these problems at once.

In many of the engineering gigs I am engaged in, I find a lot of confusion around passkeys. This is my plain-English guide to what a passkey is, how they work, and why it is harder to attack them than the trusty old password you are probably still using.

I want to encourage people to use them, implement them, and get away from passwords that - even with MFA - are not up to the job of protecting your digital assets.

TL;DR

A passkey is a login credential that lives on your device and replaces your password. Instead of you typing a secret that a website has to store and check, your device proves who you are using a piece of cryptography that never leaves your control. There is nothing to remember, nothing to type into a fake site, and nothing useful for an attacker to steal from the website's servers.

If you have ever unlocked your phone with your face or fingerprint, you already understand the experience. That same gesture is all it takes to sign in.

A password or passphrase is known as a secret, because for it to work it has to be shared with the service you are going to use it with. Anyone who overhears or guesses it can pretend to be you. Worse still, most people have shared that same secret with every website they use, so copies of it sit on servers all over the internet, waiting to leak.

A passkey works differently. Think of it as a matched lock and key. The website has the lock. Your device keeps the key, and the key never leaves your pocket. When you sign in, the website holds up its lock, your device quietly proves it has the matching key without sending the key to the website, and you are in. The key itself never travels across the internet, so there is nothing for anyone to intercept.

So where does your fingerprint or face fit in? Picture the key being kept in a small safe. Your biometric is the combination that unlocks that safe, and your face or fingerprint's only job is to convince your device that the right person is controlling it. Once the safe opens, the key inside does the real work of signing you in.

Your face or fingerprint never leaves your device. The match happens inside your device's secure hardware, and nothing about your biometric is ever sent across the internet. What travels to the website is proof that your device holds the matching key, and it is that proof, not your biometric, that the website checks and trusts. The lock on the safe is also interchangeable: swap the biometric for a PIN and the safe, the key, and every step of the login work exactly the same. It is also why a thief with your phone still cannot use your passkey. They can hold the safe, but they cannot open it.

The diagram below traces the whole journey. The thing to notice is the red line. Your biometric stays on your side of it, and only the cryptographic proof ever crosses to the website.

Zoom Two locks, two jobs: the biometric unlocks the safe, the passkey does the signing.

What actually happens under the hood

Passkeys are built on something called public key cryptography, which sounds intimidating but rests on the idea that keys come in matched pairs. When you create a passkey for a website, your device generates two keys that belong together.

• A private key, which stays locked on your device and is never shared with anyone.
• A public key, which is sent to the website and stored there. On its own it is useless to an attacker.

Zoom A passkey is one half of a matched pair: the private key never leaves the device.

The clever part is that a message scrambled by one key in the pair can only be checked using the other. So when you sign in, the website sends your device a one-off puzzle (a random "challenge"). Your device signs that challenge with the private key it has been guarding, and sends the signed answer back. The website checks the answer against the public key it stored earlier. If it matches, you must be holding the real private key, so you are let in. No secret is ever transmitted, which means there is nothing for an eavesdropper to grab.

This is the real break from passwords. A password is a shared secret. The actual secret has to travel to the server and be stored there, which is exactly why password databases are such a prize when they leak. A passkey removes that target completely, because the thing on the server is only ever the useless public half.

Why passkeys beat passwords

To understand why the industry is moving so quickly to passkeys, it helps to see the size of the problem. There are billions of leaked usernames and passwords circulating on the dark web, and because so many people reuse the same password across accounts, one leak can unlock many doors. According to the FIDO Alliance's 2025 consumer research, more than a third of people had at least one account compromised in the prior year because of weak or stolen passwords. Passkeys remove that entire category of risk rather than just reducing it.

They cannot be phished

Phishing is simple. An attacker sends you a link to a site that looks exactly like the real one, you type your username and password, and now they have them. A passkey shuts this down. Thanks to the origin binding we cover below, your device will not even offer the passkey on a lookalike domain, and there is no password to type anyway, so there is nothing to hand over. A pixel-perfect copy of your bank's login page gets the attacker nothing.

This is also where passkeys beat the second factors people already rely on. A one-time code by SMS or from an authenticator app can still be phished, because a convincing fake site just asks you to type that code in too. A passkey has nothing you can be tricked into typing.

There is nothing worth stealing on the server

We touched on this above, and it is worth stating plainly as a benefit in its own right. The server only ever holds your public key. When a company gets breached, that is what walks out the door, and on its own it is worthless. There is no secret sitting there to steal.

There is nothing to remember or reuse

Passkeys cannot be forgotten, cannot be written on a sticky note, and cannot be reused across sites the way people reuse passwords. Each one is unique to its website and generated automatically. The mental load that password managers tried to ease simply disappears.

One step instead of two

Because a passkey already proves both that you have your device and that you passed a biometric or PIN check, it can replace the password and the second-factor step in a single action. You get stronger security and a faster login at the same time, which is a rare combination.

Two flavours of passkey

Not all passkeys are stored the same way, and the difference matters for how you recover access if you lose a device.

Synced passkeys are backed up and copied across your devices through a credential manager, such as your operating system's keychain or a password manager. Create one on your laptop and it is available on your phone. If you lose a device, you sign in to your credential manager on a new one and your passkeys come with you. This is the convenient, everyday choice for most people.

Device-bound passkeys are locked to a single piece of hardware, typically a physical security key, and cannot be copied off it. They can still be used across different computers, but you have to physically connect the key each time. If the key is lost, you fall back to a backup key or an account recovery process. This is the high-assurance option favoured in government and high-security enterprise settings, where the inconvenience is the point.

Both flavours are equally phishing-resistant. The choice is about the trade-off between convenience and how tightly you want the credential pinned to one object.

At a glance, the two share the same cryptographic floor and differ only in whether the private key can be copied. The graphic below is the quick way to see it: shared traits in the overlap, and the trade-offs that actually drive the decision - recovery and vendor lock-in included - out on each side.

Synced vs device-bound passkeys: identical phishing-resistant cryptography in the overlap, a different trust and recovery model on each side.

Now let's get technical

So far we have talked about a passkey as if it were a single object, but it is more accurate to think of it as a small bundle of related parts. A single passkey is really one half of a pair, plus the rules and processes that make it usable.

A few terms you will need to know before we start

The anatomy of a passkey

As you learnt above, the passkey assertion is just a cryptographic payload that is sent to a relying party (RP). If you are curious what actually lands on the server when you sign in, the diagram below is a labelled reference of the assertion. It lists the JSON the browser posts to the RP, the decoded challenge and origin, the decoded authenticator data with its full flag byte, and the digital signature. Nothing in it is a secret anyone could reuse.

The browser posts a small JSON object holding a credential ID (which tells the server which stored public key to use), the authenticator data, the client data, and a digital signature.

If we decode the client data you find the one-time challenge and, critically, the origin - the real web address that the browser itself filled in rather than the web page. The signature is computed over the authenticator data joined to a SHA-256 hash of the client data, using the private key that never leaves the authenticator. This hashing and cryptography ensures that the sent data has not been changed in transit and can only be verified by the correct private key.

The server verifies the signature against the public key that was stored when you first registered the private key. If it checks out, the server knows the genuine private key signed the challenge for the site, and no reusable secret ever crossed the wire.

Zoom A WebAuthn authentication assertion, field by field. None of it is a reusable secret.

Reading the diagram in sections:

1. The PublicKeyCredential posted to the web server contains id, rawId, type, and a response object with authenticatorData, clientDataJSON, signature and userHandle, plus clientExtensionResults. The signed input is the authenticatorData concatenated with a SHA-256 hash of the clientDataJSON.

2. The authenticatorData, when decoded, holds the rpIdHash, a flag byte, a signCount, attested credential data (present only when the AT flag is 1) and extensions (present only when the ED flag is 1). AT is always 0 in an authentication assertion.

3. The flags are a single status byte, and every bit attests one fact the server can check:

   • Bit 0 - UP (user present): set when a physical gesture such as a tap took place.
   • Bit 1 - RFU: reserved for future use, always 0.
   • Bit 2 - UV (user verified): set when a biometric or PIN check passed.
   • Bit 3 - BE (backup eligible): set when the credential is allowed to be backed up or synced, which is what makes it a multi-device (syncable) passkey.
   • Bit 4 - BS (backup state): set when the credential is currently backed up or synced.
   • Bit 5 - RFU: reserved for future use, always 0.
   • Bit 6 - AT (attested credential data present): always 0 in an authentication assertion, because attested credential data is only included at registration.
   • Bit 7 - ED (extension data present): set only when extensions were used.

   The two backup bits are the ones people usually mean when they ask how "syncing" works. BE is a permanent property fixed when the passkey is created - it tells you whether the credential is the kind that can be synced at all. BS can change over time and tells you whether that credential is synced right now. Read together, BE set with BS set describes a synced, multi-device passkey, whereas BE unset describes a single-device, device-bound passkey. One caveat: BE indicates eligibility, not a guarantee that a copy exists elsewhere, and the WebAuthn specification is explicit that the presence of these bits does not let a relying party prove where a key physically lives.

4. The clientDataJSON decodes into type, challenge, origin and crossOrigin.

So how is a password different from a passkey?

It is worth seeing what a password-based login looks like by contrast. A password login uses an HTTPS POST to send the actual secret across the internet. On the server, where it is stored (hopefully as a salted hash), it is now checked: the server runs an algorithm across the submitted secret and checks whether it matches the saved hash. It carries no binding of which origin asked for it, and it does not know whether it was sent by the owner of the secret. That is what makes passwords - or any shared secret - both breachable and phishable, because a lookalike site gets a secret it can reuse. A password login looks something like this:

Zoom A password login posts the username and password directly, with no challenge, origin or signature.

You can see the benefit of the passkey assertion model, which carries a signature instead of a secret and is bound to the origin (the website URL) it can be used with.

WebAuthn - the standard that makes it all work

You will hear the word WebAuthn the moment you start reading about passkeys, so it is worth a plain explanation. WebAuthn, short for Web Authentication, is the open standard that lets a website ask your browser to create and use a passkey. It is maintained by the W3C, the same body responsible for the core standards of the web, and it is already built into every modern browser and operating system.

The neat way to think about it is that WebAuthn is the common language all web systems speak. Before it existed, any website wanting passwordless login had to deal with a patchwork of incompatible, bespoke gadgets and proprietary systems. WebAuthn gave everyone a single agreed set of rules and vernacular, so a passkey created in Chrome on a Windows laptop behaves the same way as one created in Safari on an iPhone. That shared language is the reason passkeys work across the whole industry rather than locking you into one vendor - and why they are being adopted so rapidly.

In practice WebAuthn defines two processes, which the standard calls ceremonies. Registration is when your device creates a new passkey for a site and hands over the public key. Authentication is when you later sign in and your device signs the site's challenge. Both run through the same WebAuthn machinery in your browser, and both come down to that one tap that starts with your face, fingerprint, or PIN unlocking access to your passkey.

Now, WebAuthn does not work entirely alone. It sits inside a larger family of standards from the FIDO Alliance, the industry body whose members include Microsoft, Google, Amazon, Meta, Intel, Yubico, Cisco and Apple. The combination of WebAuthn (the part the browser speaks) and a companion protocol called CTAP (which lets your browser talk to external authenticators such as a phone or a plugged-in security key) is together known as FIDO2. You do not need to know those acronyms, or how their inner workings behave, to use a passkey. The single thing worth remembering is that passkeys rest on open, shared standards rather than any one company's product, which is what gives you interoperability, portability and choice.

And reassuringly, all of this complexity is hidden. You will never interact with WebAuthn directly. It hums away in the background, and all you ever see is the prompt asking you to confirm it is you.

How signing up and signing in actually work

By now you have the pieces, so here are the two ceremonies end to end. The diagrams put all four participants in their own lane, which makes it easy to see who talks to whom and, more to the point, what never moves.

Registration ceremony

Registration is where the key pair is born. Your device creates it for that specific site, sends only the public key, and locks the pair to the site's domain. The private key never appears in a single message.

Zoom

The passkey registration ceremony across the User, Authenticator, Browser/Client and RP Server lanes. Only the public key is ever sent.

Authentication ceremony

Signing in is the mirror image. The server sends a one-time challenge, you approve with a biometric or PIN, and your device signs the challenge with the private key it has been holding. The signature also proves the request came from the genuine site, and the server checks it against the public key it stored at registration.

Zoom

The passkey authentication ceremony. No shared secret is ever transmitted.

On many modern sites, your saved passkeys appear right in the login box as autofill suggestions, so you can pick your account and authenticate in a single tap. The industry calls this "conditional UI," but to you it just looks like the site already knows which passkeys you have.

Discoverable credentials and how the authenticator selects them

There is one more structural distinction worth drawing out, because it quietly shapes the login experience.

A discoverable credential (WebAuthn previously called these "resident keys," and the term still appears in the API) stores everything needed to sign in - including the private key material and your user handle - directly on the authenticator. Because the authenticator holds this extra information, the website does not need to know who you are before asking for a login. It can send a request with an empty list of allowed credentials, and your authenticator simply looks up whatever passkeys it holds for that site's domain (origin) and offers them to you. This is what makes a login with no typed username possible, and it is the machinery behind the autofill experience where your passkey appears in the login box before you have entered anything.

A non-discoverable credential works differently under the hood. The authenticator does not store the private key at all. Instead, it retrieves the passkey on demand using the credential ID that the website supplies. That is why the site must identify you first, typically by asking for a username, so it can send back the credential IDs it has stored against your account. Nothing is stored on the authenticator, so it can support an effectively unlimited number of non-discoverable credentials. This design dates from earlier standards when security keys were used as a second factor after a password, where identifying the user first was already part of the flow.

The distinction matters more than it first appears, because in current implementations and usage, a passkey is a discoverable credential. The standards state that relying parties implementing passkey login should always create credentials as discoverable, and the account pickers shown by browsers and operating systems will only ever surface discoverable credentials. For developers, this is the residentKey: "required" setting at registration.

How the discoverable flow differs

The sequence below shows the WebAuthn authentication ceremony as it runs with a discoverable credential. The differences from the basic authentication ceremony above are at the start and the end:

• The server sends an empty allowed-credentials list rather than looking your account up first; the authenticator finds its own matching passkeys by domain; and you pick your account from the browser's list.
• The signed response carries your user reference so the server can work out which account just signed in.

The difference is purely who identifies whom, and in which order. The origin check, the user verification and the signature itself are unchanged, so nothing about the security model is weakened.

Zoom

A discoverable-credential WebAuthn login: the empty allow-list and the returned user handle are the only real differences.

Support for passkeys

Support is now broad across the mainstream platforms, with the usual caveat that exact behaviour can vary by device maker and version.

Zoom Passkey support at a glance: platforms, desktop browsers, the gap between ecosystems, and hardware-key slot limits.

Apple

In the Apple ecosystem, passkeys arrived with iOS and iPadOS 16 and macOS 13 Ventura, stored and synced through iCloud Keychain, with Safari 16 on iOS and 16.1 on macOS carrying the browser side. From iOS 17, third-party password managers can act as the passkey provider. macOS can use passkeys held in iCloud Keychain.

Android

On Android, support runs from Android 9 upwards through the Credential Manager framework with Google Password Manager as the default store, and from Android 14 users can select a third-party password manager as their passkey provider instead. Samsung Internet supports passkeys from version 21 with syncing through Samsung Pass.

Browsers

On the desktop, Chrome and Edge picked up passkey support from version 108. Firefox added passkey support, including the autofill picker, in Firefox 122 in early 2024.

Windows

Windows has supported passkeys from Windows 10, with the full native experience - including passkey management through Windows Hello - arriving in the Windows 11 2023 update (23H2).

Linux

Desktop Linux has no native platform authenticator, so Chrome and Firefox on Linux cannot create passkeys locally. The cross-device QR flow with a phone, or a hardware security key, are the working paths for the OS.

Cross-platform support

Passkeys do not sync between ecosystems - a passkey in iCloud Keychain/Passwords does not sync or appear in Google Password Manager, or vice versa. This is where cross-platform password managers, or the QR-based cross-device flow, come in.

Hardware security keys

Each passkey consumes a small amount of storage on the authenticator, and on hardware security keys that storage is finite. Devices like YubiKeys can hold between 25 and 100 discoverable credentials depending on the version of the key. If you are keeping passkeys on a hardware key for high-assurance accounts, the slot count is worth knowing before you commit to it broadly.

Using your phone as a passkey: the QR code and the Bluetooth handshake

Several times above - on Linux, in the gap between ecosystems, when signing in on a borrowed computer - we leaned on "the cross-device QR flow" without opening it up. It deserves a proper look, because it is the one corner of the passkey story where the tidy "it just works" experience quietly depends on your hardware, and occasionally on configuration an administrator has to get right.

The scenario is this. You are sitting at a computer - call it the host - that does not hold your passkey. Perhaps a Linux box, a hotel PC, a colleague's laptop, or a locked-down virtual desktop. Your passkey lives on your phone, and you want to use the phone to sign in on the host. FIDO calls the machinery that makes this work hybrid transport, though you will still see its old codename, caBLE, in older write-ups. It was standardised in CTAP 2.2, the protocol that lets a browser talk to an external authenticator.

When you pick "use a passkey from another device," the host shows a QR code. You scan it with your phone, approve with your face, fingerprint or PIN, and you are signed in on the host. Simple on the surface. Underneath, that one action uses three completely different channels, each doing exactly one job.

Three channels, three jobs

1. The QR code is a one-way visual bootstrap. The host draws it, the phone reads it with its camera, and that is the whole of the QR's job. It is not the login. It carries a short-lived setup bundle - an ephemeral public key and a shared secret - that lets the two devices recognise each other and agree how to talk securely. It travels as light, from one screen into one camera, which is precisely why it never crosses the internet.

2. Bluetooth Low Energy proves the phone is in the room. The instant your phone has read the QR, it broadcasts a small, encrypted BLE advertisement, and the host sits there listening for exactly that beacon. Because the advert is derived from the secret embedded in the QR code, only a phone that has just scanned this host's QR can produce one the host will accept. This is the step most people never realise is happening, and it is the reason the flow will not complete with Bluetooth switched off.

3. An encrypted internet tunnel carries the actual data. This is the part that surprises people. The passkey traffic - the challenge, the signature, the WebAuthn assertion - does not travel over Bluetooth. It flows over the internet through a tunnel service operated by the phone's vendor, such as Google or Apple. That relay shuttles encrypted bytes between the host and the phone but cannot read them, because the two devices stand up an end-to-end encrypted channel over the top of it, keyed partly from material exchanged in the QR and the BLE beacon. Your private key never leaves the phone, exactly as in every other passkey ceremony.

So Bluetooth is not the pipe. It is the proximity sensor. The QR code starts the conversation, Bluetooth proves the two devices are physically together, and the internet carries the load.

Why proximity over Bluetooth is good security

It is fair to ask why the designers bothered with Bluetooth at all, when the data already moves over an encrypted internet tunnel. The answer is that a QR code, on its own, is trivial to relay, and relaying one is a genuine attack.

Picture a phishing page that shows you a QR code and says "scan to sign in." Nothing physically stops an attacker from taking a real QR code generated by their login session on their machine, dropping a screenshot of it onto a page in front of you, and hoping you scan it. If scanning were enough, your phone would cheerfully authorise the attacker's session on the other side of the world.

The BLE beacon shuts that door. After you scan, your phone broadcasts its little encrypted advertisement into the air immediately around it, and the host has to hear that beacon to carry on. Bluetooth Low Energy only reaches a short distance - a handful of metres in practice - so "the host can hear the beacon" is a physical proof that your phone and the host are in the same place. An attacker relaying a QR code from a data centre or another city is nowhere near your phone, hears nothing, and the ceremony stops dead. And because the advert is cryptographically tied to the specific QR you scanned, a stray Bluetooth device nearby cannot forge it either.

This is why the proximity check is more than a box-ticking nicety - it is load-bearing. The material carried in the beacon also feeds the keys that bring up the encrypted tunnel, so a host that never heard a valid, nearby advert cannot finish the handshake in the first place. Proximity is not checked once and then taken on trust. It is baked into the cryptography.

This is why passkeys sometimes need device-level configuration

Here is the practical sting for engineers, and the thing a password-era mental model tends to miss. A password asks nothing of the device but a keyboard. A passkey, and the phone-based QR flow in particular, is coupled to the host's hardware and configuration. On a physical laptop that means a working, switched-on Bluetooth radio. Turn Bluetooth off for policy reasons, or sit at a desktop with no Bluetooth adapter at all, and the QR route to your phone simply will not complete, because the second channel in the diagram above is missing.

The problem sharpens in virtual desktops. In Azure Virtual Desktop, Windows 365 or any RDP session, the "host" running the browser is a virtual machine in a data centre. That VM has no Bluetooth radio, and it is certainly not in the room with your phone, so the QR and BLE flow cannot originate from it. Left to its own devices, in-session passkey sign-in is dead on arrival.

Microsoft's answer is a device-level feature called WebAuthn redirection. With it enabled, WebAuthn calls made inside the remote session are redirected back down the RDP connection to your local device, which then handles them with its own authenticator - Windows Hello, a plugged-in FIDO2 key, or the local machine's Bluetooth radio for the phone flow. The tell that it is working is a Windows Security prompt appearing on your real machine, overlaying the remote session.

The catch is that this is configuration, not magic:

• It is governed by the RDP property redirectwebauthn:i:1 on the host pool, or the Device redirection control in the Azure portal, and it can be independently allowed or blocked by Intune or Group Policy through the Do not allow WebAuthn redirection setting. Where those disagree, the most restrictive setting wins, so a single mismatched policy can silently switch passkey sign-in off for an entire host pool.
• The Windows App or Remote Desktop client, and the platform it runs on, have to support redirection in the first place.

Azure Virtual Desktop does enable this redirection by default on new host pools, but "by default" is not "guaranteed." It is one policy toggle away from off, and it is exactly the sort of setting that turns "passkeys don't work on our VDI" into a half-day of head-scratching. The wider lesson holds well beyond Microsoft: because passkeys lean on device hardware - a Bluetooth radio, a secure element, a camera - and on session plumbing like redirection that passwords never touched, rolling them out is partly an endpoint-configuration exercise, not purely an identity one. It is worth auditing Bluetooth policy, VDI redirection settings and client versions before you promise your users a passwordless future.

Common questions

Do I have to use my fingerprint or face to use a passkey?

No. Biometrics are the default on most devices because they are quick, but a device PIN or passphrase works just as well for the verification step. Whatever you choose, the biometric itself stays on your device and is never sent to the website. Just remember that a biometric unlock is generally stronger than a short PIN or passphrase.

What if I lose my phone?

1. If your passkeys are synced through a credential manager, you can sign in to that credential manager on a replacement device and your passkeys are still accessible.
2. If you used device-bound passkeys on a hardware key, you will need to rely on a backup key or the site's account recovery capabilities.

This is why thinking about recovery up front is worth some effort.

Can my family or team share one passkey?

Passkeys are designed for individual sign-in, because the private key is tied to a specific device or vault. They are meant to identify an individual or a single system, and they are not designed to be passed around like a shared password.

Are passkeys locked to Apple or Google?

They do not have to be. If you store them in your platform's own keychain, they live in that ecosystem. If you store them in a cross-platform password manager instead, they travel with you when you switch between iPhone, Android, Windows, and macOS. And even within a platform keychain, a QR-code flow lets you use a passkey from your phone to sign in on a nearby computer that does not have it.

Will passkeys replace passwords entirely?

Eventually, almost certainly. Adoption is growing quickly across major platforms and services. For now we are in a transition period, where many sites offer passkeys alongside passwords and let you choose, but the direction of travel is very clear.

Common misconceptions

A few reasonable-sounding beliefs about passkeys come up again and again. Each contains a grain of truth, which is what makes them sticky, so it is worth walking through them.

"A strong password in a synced credential manager is about as good as a passkey"

This is the one worth slowing down for, because on the surface it seems fair. The reasoning goes something like this:

My password is long, unique and random, it lives in the same synced vault a passkey would, and I unlock that vault with my fingerprint. Same place, same gesture, so surely they are roughly the same?

They are not, and it has nothing to do with how strong the password is. A password is a bearer secret. Whoever presents the right string is let in, and that string is handed to the server on every login. Strength only changes how hard it is to guess. It does nothing about the fact that the secret is transmitted across the internet and stored on the server, which is what makes even strong passwords phishable and breaches damaging.

A passkey simply does not have that issue. The private key is never sent, and the signature it produces is bound to the real site's origin, checked by the browser on your device rather than by you. That origin binding is the whole difference. A perfect clone of your bank's page can still defraud a careful person out of a password, because the password neither knows nor cares which site it is typed into. A passkey knows.

So this is not two points on one scale; the two work in different ways. A synced vault makes a password nicer to manage, but it cannot hand the password the properties that make a passkey phishing-resistant - origin binding and a non-transmitted cryptographic credential.

"If I keep everything in one vault, a passkey is no safer than a password there anyway"

There is a legitimate point hiding in this one, but it is about a different thing than it first appears. If you store both your passkey and your one-time-code (TOTP) seeds in the same synced vault, then a compromise of that single vault would expose both at once, whereas a separate authenticator app on a different device would give you an independent second anchor. That is a sound observation about not concentrating all your credentials in one basket, and it is worth recognising.

But notice that this is a point about where you store your credentials, not about how strong passkey authentication is compared to password authentication. Spreading your credentials and recovery options across more than one store is good practice whatever technology you use. It does not close the gap between a bearer secret (passwords) and an origin-bound key (passkeys). Keep the two questions separate and the "no safer anyway" conclusion falls away. The storage concern is real, and the authentication advantage of the passkey is still intact.

"A passkey and a hardware security key are the same thing"

They are related but not the same, and mixing them up causes real confusion. A passkey is the credential - the key pair scoped to a website. A hardware security key is just one place that credential can live. The same kind of passkey can sit in your phone's secure hardware, your laptop, or a password manager instead. In other words, a hardware key is one kind of authenticator, and a passkey is the thing an authenticator holds. You do not need to buy any special hardware to use passkeys, though a hardware key is there if you want a credential pinned to a single physical object for high-security systems.

"It is a biometric passkey, so my fingerprint or face is the passkey"

You will sometimes hear passkeys described as "biometric passkeys," and the phrase quietly plants a wrong idea that your face or fingerprint somehow is the credential, or that it gets sent to the site to log you in. Neither is true, and the distinction matters.

The passkey itself is purely cryptographic. It is the private and public key pair we have been describing, and it has nothing to do with biology. What your fingerprint or face actually does is unlock the private key locally so it can be used to sign the challenge. It is the gesture that authorises the authenticator to act, not the thing that proves your identity to the website. The biometric is the lock on the safe the key is kept in, not the key itself.

Two things follow from that, both worth understanding:

• First, your biometric never leaves your device and is never sent to the website. The site only ever receives the signature and learns, through the flags in the authenticator data, that a verification check passed.
• Second, biometrics are not compulsory. A device PIN or local password unlocks the passkey as well, which is why passkeys work fine on hardware with no fingerprint reader or camera.

So a passkey is not "a biometric" - it is a cryptographic key that a biometric, or a PIN, happens to unlock.