A passkey can sign you in with a fingerprint, face scan, device PIN, or security key. The website never receives that biometric data. It receives a cryptographic proof tied to its own domain.
That distinction matters. Passkeys remove the shared secret that makes passwords so easy to phish, reuse, and steal. They also move part of authentication into the browser and operating system, where prompts, account choices, and recovery can feel opaque unless you know what is happening.
How browser passkeys work
Browser passkeys are built on the Web Authentication API, usually called WebAuthn. When you create one, an authenticator generates a public–private key pair. The website stores the public key. The private key stays with the authenticator.
During sign-in, the site sends a fresh challenge. Your authenticator signs it after you approve the request. The site checks that signature with the public key it already holds. There is no reusable password for a fake login page to collect.
The authenticator may be built into your phone or computer, stored in a credential manager that syncs across your devices, or carried on a hardware security key. The browser connects the website to that authenticator and shows which account and domain are involved.
Why phishing becomes much harder
A password can be typed into any box that looks convincing. A passkey is scoped to a relying party: the domain for which it was created. A credential made for example.com cannot simply be used by examp1e.com, even if the imitation page looks perfect.
The WebAuthn Level 3 specification makes this origin binding central to the design. It also prevents one relying party from learning whether you hold credentials for another. That separation reduces both phishing and cross-site correlation.
Passkeys do not make every account problem disappear. A compromised session cookie can still let an attacker act as you after login. A malicious service can still mishandle the profile data it already holds. Good authentication protects the door; it does not govern everything inside the room.
What a website receives
At registration, the site receives a public key, a credential identifier, and information needed to verify future assertions. It may also receive attestation information about the authenticator, depending on what the site requests and what the browser allows.
The private key is not sent to the website. Your fingerprint image, face image, or device PIN is not sent either. Those checks happen locally to unlock use of the credential. The site learns that the required user verification succeeded, not the biometric detail used to complete it.
Attestation deserves a closer look
Attestation can help a high-security service understand what kind of authenticator created a credential. It can also create privacy risk if authenticator information becomes unusually identifying. WebAuthn therefore includes privacy guidance designed to prevent certificates from tracking individual devices.
For an ordinary consumer account, you should not need to understand attestation formats. The practical point is simpler: a passkey prompt should name the service you intended to use, and the request should appear because you started a sign-up or sign-in action.
Synced passkeys and device-bound credentials
Some passkeys sync through a platform credential manager. Others remain on one device or hardware key. Sync makes everyday recovery easier: replace a laptop, sign in to your credential manager, and your passkeys may return. Device-bound credentials offer a different security and recovery trade-off.
Ask where your passkeys live before depending on them. Check whether your credential manager is protected by a strong account and recovery method. For a hardware key, register a spare and store it separately. For important accounts, keep more than one approved sign-in route.
This is the same practical discipline we recommend in our guide to browser password managers: security improves when storage, recovery, and device access are treated as one system.
What to check before creating a passkey
Read the domain in the browser
Start from the service's known website or app. Passkeys resist phishing because of domain scoping, but a clear look at the address still helps you understand which account you are creating and where recovery will happen.
Understand the account picker
A browser may show passkeys in an autofill-style menu. Choose only the account you expect. If a prompt appears without a sign-in action, cancel it and return through the site's normal login page.
Plan recovery before you need it
Find the account's security page and review backup options. Add a second authenticator where supported. Store recovery codes offline. Removing passwords too quickly can turn a lost device into a long support conversation.
Protect the signed-in session
Log out on shared machines and review active sessions periodically. Our explanation of private browsing is a useful reminder: closing a private window clears local session state, but private mode does not make an authenticated session anonymous.
A better default for browser authentication
Passkeys replace a transferable secret with a domain-bound proof. That is a meaningful security improvement, especially for people who reuse passwords or face convincing phishing messages. The browser's job is to make the boundary visible: which site is asking, which account will be used, and which device holds the credential.
Use passkeys where recovery is clear. Keep a second route for accounts that matter. Treat unexpected prompts as a reason to pause. Strong authentication should feel calm and deliberate, not mysterious.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.