A passkey can unlock an account with a fingerprint, face scan, device PIN, or security key. That makes it feel as though the website receives something deeply personal. It does not. The biometric check normally stays with the device, while the site receives cryptographic proof that the right authenticator approved the sign-in.
That separation is the point. Passkeys replace a reusable secret with a key pair tied to one service. To judge the privacy trade-off, it helps to see exactly what stays on the device, what reaches the website, and what may be synchronized elsewhere.
Passkey privacy starts with a site-specific key pair
Passkeys use WebAuthn, the web standard for public-key authentication. When you create one, an authenticator generates a private key and a matching public key. The private key remains protected by the authenticator. The website stores the public key with your account.
The MDN guide to passkeys explains that the site uses the public key to verify a signed assertion during login. The private key is not sent to the site. A database breach exposing the public key therefore does not provide the secret needed to sign in.
What the website actually receives
During registration, the website sends a random challenge and information identifying itself. Your authenticator creates the credential after you approve. The response includes the public key, a credential identifier, and data that lets the server validate the ceremony.
During sign-in, the server sends a fresh challenge. The authenticator signs it with the private key after local approval. The site receives the signature and supporting data, then verifies them against its stored public key. It does not receive your fingerprint image, face map, or device PIN.
Local verification is not biometric upload
A fingerprint or face scan can be the local gesture that unlocks the authenticator. The operating system tells the authenticator that verification succeeded; the website gets a cryptographic response. This is closer to a locked key approving a request than to sending biometric identity across the internet.
A site may still collect other information through its ordinary login page, analytics, or account profile. Passkeys improve the authentication channel; they do not erase the rest of a service’s data practices.
Why passkeys resist phishing
A passkey is scoped to a relying party, usually the service’s domain. A convincing fake login page on a different domain cannot ask your authenticator to use the genuine site’s credential. The W3C WebAuthn specification states that credentials are scoped to a specific relying party and that other relying parties cannot discover them.
This differs sharply from passwords. A person can type the same password into a fake page because the string has no built-in sense of origin. The browser and authenticator enforce a passkey’s domain boundary before producing a signature.
Still confirm the account and domain shown in the browser’s sign-in sheet, particularly when login starts inside an embedded frame or follows an unexpected link.
Can one site see passkeys for another?
WebAuthn is designed to prevent that form of cross-site discovery. A malicious site should not be able to query your authenticator and learn which banks, social networks, or work services you use. Credential identifiers and public keys are meaningful only in their intended relying-party context.
The standard also uses user mediation so a site cannot silently use a credential’s existence to identify you. Browser interfaces matter here. A good prompt names the service and waits for your choice.
Connect every prompt to an action you deliberately started. Our browser permissions guide applies that habit across sensitive browser capabilities.
Where synchronization changes the picture
Some passkeys stay on one device or hardware security key. Others synchronize through a platform credential provider so they work on your phone and computer. Synchronization improves recovery and convenience, but it adds another system that stores encrypted credential material and manages device access.
Ask who operates the sync service and how you recover access if every trusted device is lost. Review that provider’s security documentation before making synced passkeys your only route into an important account.
For high-value accounts, keep more than one recovery method. A second passkey on another trusted device or a hardware security key can be cleaner than depending on SMS. Store recovery codes offline and review registered passkeys from the account’s security page.
Passkeys do not make a session private
A safer login does not stop a website from seeing activity after you sign in. Cookies, account histories, analytics, and server logs still follow the service’s policies. Private browsing does not make an authenticated session anonymous; see what private browsing actually changes.
Passkeys also do not grant a site access to local documents. Authentication and file permissions are separate boundaries. Our explanation of File System Access API privacy shows why each capability deserves its own decision.
A practical passkey checklist
- Confirm the domain. Approve a passkey only for the service you meant to visit.
- Know where it lives. Check whether it is device-bound, on a hardware key, or synchronized.
- Add a backup. Register a second trusted authenticator for essential accounts.
- Remove old devices. Review both the site’s passkey list and your credential provider after replacing hardware.
- Protect recovery. Your device account and screen lock become important parts of passkey security.
The useful privacy boundary
Passkeys are not magic anonymity. They are a better authentication design. The site gets a public key and signed proof, while the private key and biometric verification stay under the authenticator’s control.
That narrower exchange removes the reusable secret that phishing pages and password breaches exploit. Use the improvement deliberately: verify the site, understand synchronization, and maintain a recovery route you trust.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.