When you create a passkey for a website, your device generates a public key and a private key as an asymmetric key pair. The public key is sent to the website and stored on its server, while the private key stays sealed inside your device's secure hardware and is never transmitted. The website uses the public key to verify signatures that only your private key can produce.
This split is the entire security model of a passkey. One half is designed to be shared openly; the other half is designed to never leave your control. Everything else in a passkey system is scaffolding around that single cryptographic fact.
The two keys and how they differ
The public key and private key are mathematically linked but computationally impossible to derive from each other. They are generated together by your device's authenticator, typically through the WebAuthn API, in a single operation measured in tens of milliseconds. The public key is a few dozen to a few hundred bytes, depending on the algorithm. The private key never appears in application memory in a usable form on well-built platforms.
The relationship is asymmetric in a specific way. A message signed with the private key can be verified by anyone holding the public key. A message signed with the public key cannot be verified by the private key. That one-directional property is what lets a server challenge you without ever knowing your secret.
Your device does not need to store the public key at all, because the website holds it. The private key is the only persistent secret, and it is bound to the credential ID the server also records. This means the server's database never contains anything that could be replayed to impersonate you.
What happens during registration
Passkey creation is a four-party exchange. The website (relying party) asks your browser to create a credential. The browser calls the platform authenticator, usually a secure enclave on your phone or a TPM chip on a laptop. The authenticator generates the key pair, keeps the private key, and returns the public key plus a credential ID to the browser, which passes them to the server.
The private key is held in hardware-backed storage. Apple's Secure Enclave, Google's Titan-class security chip, and Windows TPM 2.0 modules each isolate key material from the main processor so that even a compromised operating system cannot export it. Access requires a local user gesture, such as biometrics or a device PIN, before the key will sign anything.
Passkeys can be synced rather than device-bound. In that model, the private key is encrypted and replicated through a cloud keychain, such as iCloud Keychain or Google Password Manager, so it can be used on a second device. The public key on the server is unchanged; the private key is simply stored under end-to-end encryption in more than one place.
Why this beats passwords and shared secrets
Passwords are a shared secret. Both you and the server know the same string, so a server breach exposes every user. TOTP codes are also shared secrets, generated from a seed the server stores. A passkey inverts the model: the server holds only public material, so a full database dump yields nothing an attacker can use to authenticate.
The signature also binds to the origin. The private key will only sign an assertion for the exact domain that requested it, which closes the phishing channel that harvests passwords and one-time codes. An attacker who clones a login page gets a signature that the real server rejects.
Numbers matter here. Public-key signatures in WebAuthn typically use elliptic curve algorithms such as ES256 or EdDSA, with keys around 64 to 256 bits of security strength depending on curve and parameter choices. Verification on the server costs well under a millisecond in most implementations. The performance overhead is trivial compared with the security gain.
| Credential type | Server stores | Phishable | Breach exposes user secret | Replayable |
|---|---|---|---|---|
| Password | Password hash | Yes | Yes, often crackable | Yes |
| TOTP seed | Shared secret seed | Yes, via real-time relay | Yes | Within ~30 s window |
| Push approval | Device token | Partly, via fatigue attacks | Limited | No |
| Device-bound passkey | Public key | No | No | No |
| Synced passkey | Public key | No | No, key is encrypted | No |
Free free to note the counterintuitive detail: a stolen server backup of passkey public keys is worthless to an attacker, yet a stolen phone with a synced keychain can still be dangerous if the device unlock is weak. The threat shifts from the server to the endpoint.
The timeline of a single passkey
A passkey is not a static object. It is created, activated, used repeatedly, possibly synced, and eventually revoked. The table below traces that arc with realistic timing.
| Stage | What happens cryptographically | Typical time |
|---|---|---|
| Key generation | Device creates public and private key pair | 10-100 ms |
| Local user check | Biometric or PIN unlocks private key use | 0.5-2 s |
| Registration response | Server stores public key and credential ID | 100-500 ms round trip |
| Authentication | Private key signs server challenge, server verifies | Under 1 s end to end |
| Sync replication | Encrypted private key propagates via keychain | Seconds to minutes |
| Revocation | Server deletes public key record | Immediate on server side |
The syncing step is where most user confusion lives. Synchronization does not change the public key. It copies the encrypted private key. That distinction explains why a passkey can work on a new device without any re-registration with the website.
Edge cases that break the simple story
Hardware-bound passkeys die with the device unless you have a second one. If you register a single device-bound credential and the device is lost, the server's public key is useless to you and recovery depends on whatever fallback the site offers. Many sites now require at least two passkeys or a recovery code for this reason.
Synced passkeys have their own failure modes. Platform lock-in is real: a passkey synced through one vendor's keychain may not be exportable to another ecosystem, and cross-platform portability standards are still maturing. Some services also limit how many passkeys a single account can register, commonly between 5 and 10, which constrains recovery planning.
Algorithm support varies by authenticator. A site that only accepts ES256 will reject a credential generated with Ed25519, and some older security keys support only a subset of curves. The server must advertise acceptable algorithms in its registration options or the ceremony fails.
The professional caveat: passkey attestation is often disabled or best-effort. Enterprises that want to prove a key lives in approved hardware need attestation, but many consumer platforms decline to provide meaningful attestation statements to protect user privacy. You cannot always tell whether a given passkey is hardware-bound or synced.
Common misconceptions
The first misconception is that the private key is sent to the website and encrypted. It is not sent at all. Encryption in transit would still expose it to a compromised endpoint; not transmitting it eliminates that class of risk.
The second is that a passkey stores your biometric data on the server. Biometrics never leave the device. The local check produces a yes/no gate that unlocks the private key, and the server sees only the resulting signature.
The third is that passkeys are passwordless in every deployment. Many sites still require a password as a fallback or recovery factor, which can reintroduce phishing risk if that path is weaker. A passkey account is only as strong as its weakest recovery route.
The fourth is that the two keys are the same length or type. They are related but distinct values, and their security depends on the curve and the random number generation used at creation. Weak entropy at generation would undermine a theoretically sound scheme.
Practical actions
Register the passkey through the official website, never a link from an email. Confirm the address bar before the creation prompt appears, because the origin binding starts at that moment.
Create at least two passkeys per critical account, ideally on separate devices. This turns a lost phone from an account lockout into a minor inconvenience. Thresholds vary, but two independent credentials is the minimum defensible baseline for email, banking, and cloud identity.
Store recovery codes offline in a safe separate from the device. Prefer hardware-bound passkeys for high-value accounts where the site supports them. Keep device operating systems updated so authenticator firmware patches apply. Review registered passkeys every few months and remove stale devices. Test sign-in on a secondary device before relying on a new passkey.
Push back on any site that treats a passkey as a single factor and still allows a weak password reset. The passkey protects the login, but a reset channel protected by a texted code can be attacked independently.
Limitations of the model
The cryptography is strong; the ecosystem around it is uneven. Recovery still depends on each site's implementation, and some fallback flows reintroduce the very phishing the passkey was meant to stop. Syncing improves convenience but concentrates risk in the keychain account, which now becomes a high-value target.
Standards continue to evolve. The WebAuthn specification, maintained by the W3C and FIDO Alliance, defines the ceremony formats, but support for cross-ecosystem credential transfer is not universal. Where evidence about specific vendor behavior is thin, the safe conclusion is that portability is improving but not guaranteed.
The two keys are simple. The trust placed in devices, keychains, and recovery processes is not. A passkey moves the security question from what you know to what you hold and how well you protect it.