Passkeys: Definition, How They Work, and Where You’ll See Them

Passkeys are a passwordless sign-in method designed to reduce phishing and credential theft. Instead of typing a reusable password, you authenticate with a device-bound cryptographic key using FIDO2/WebAuthn—often unlocked with Face ID, fingerprint, or a device PIN.

How passkeys work (registration + authentication)

At a high level, passkeys shift authentication from “something you know” (a reusable password) to “something you have” (a private key) plus local user verification (biometric/PIN). The key security property is that the private key never leaves the authenticator; only signed challenges and public keys are shared.

1) Registration (creating a passkey)

When you “Create a passkey” for a site/app:

1. Relying Party (RP) (the website/app) initiates registration and sends a challenge plus metadata (e.g., RP ID / domain).
2. Your authenticator (phone, laptop, or hardware security key) generates a new key pair (public + private) scoped to that RP.
3. The authenticator returns: - the public key - an attestation statement (optional; depends on policy and device) - metadata needed to reference the credential later (credential ID, algorithm, etc.)
4. The RP stores the public key and credential data. No password is stored or created.

Why this matters: Attackers can’t steal a server-side password database and reuse it elsewhere—there is no password. Even if an attacker gets the RP’s stored public keys, public keys aren’t secret.

2) Authentication (signing in with a passkey)

When you “Sign in with passkey”:

1. The RP sends a fresh, random challenge and indicates acceptable credentials (or lets the authenticator discover them).
2. The authenticator checks RP ID binding (domain matching) and prompts the user to unlock (biometric/PIN) if required.
3. The authenticator signs the challenge with the private key and returns: - the signed assertion - a counter / authenticator data (varies by authenticator)
4. The RP verifies the signature using the stored public key for that credential.

Phishing resistance: The authenticator won’t sign for the wrong domain. A fake lookalike site typically can’t get a valid assertion for the real domain.

3) Where biometrics/PIN fit in

Biometrics (Face ID, fingerprint) and device PIN are usually local unlock mechanisms for the private key. They are not sent to the service. In most deployments, the service learns only that the authenticator performed user verification (UV) successfully.

4) Sync vs device-bound passkeys (operational nuance)

Some ecosystems support synced passkeys (credentials replicated across a user’s devices through a cloud account) and device-bound passkeys (credential stays on one device or one security key). Security teams should understand which model they’re enabling because it affects:

• Account recovery (easier with sync, riskier if cloud account is compromised)
• Device lifecycle (what happens when devices are replaced)
• Incident response (how to revoke credentials and validate access paths)

What admins actually configure (WebAuthn/FIDO2 settings)

Most orgs “enable passkeys” by enabling WebAuthn/FIDO2 in an identity provider (IdP), SaaS app, or custom login service.

Typical knobs you’ll see:

• Require user verification (UV) vs allow user presence (UP) only
• Allow platform authenticators (built-in) and/or roaming authenticators (USB/NFC keys)
• Attestation policy: none vs enterprise attestation (rare outside regulated environments)
• Backup/recovery factors and step-up rules

Example WebAuthn server-side concepts you’ll handle (names vary by library):

Registration:
- rpId: "example.com"
- challenge: random bytes
- user: id, name, displayName
- pubKeyCredParams: algorithms (e.g., ES256)
- authenticatorSelection: userVerification="required|preferred|discouraged"
- timeout, excludeCredentials, attestation

Authentication:
- rpId
- challenge
- allowCredentials or discoverable credentials
- userVerification setting

Log patterns to look for when troubleshooting:

- "webauthn ceremony started" / "challenge issued"
- "origin mismatch" or "rpId mismatch" (often proxy/domain issues)
- "invalid signature" (stored key mismatch or data corruption)
- "user verification required" but authenticator returned UV=false
- "credential not found" (wrong account, deleted passkey, or allowList mismatch)

Where you’ll encounter passkeys

Passkeys are showing up across consumer and enterprise sign-in flows, especially where password phishing and reset costs are high.

User-facing scenarios

You’ll commonly see:

• “Use a passkey” buttons on sign-in pages alongside password and MFA options.
• “Create a passkey” prompts after a successful login (a migration path away from passwords).
• Cross-device sign-in flows where you approve a login on your phone to sign in on a different device (often via a QR code).
• Passwordless onboarding for new accounts, where the first credential is a passkey rather than a password.

Practical tip for users: If a service supports passkeys, enable at least two recovery methods (a second device passkey, a hardware security key, or an approved recovery workflow) to avoid lockouts. If you still manage a lot of apps that require passwords, using a reputable password manager can reduce reuse risk while you transition—many teams use 1Password to store remaining credentials and secure notes (Try 1Password →).

Admin/IT scenarios

Admins and IT teams encounter passkeys when:

• Reducing phishing risk for executives, finance, admins, and privileged roles.
• Replacing SMS OTP and push approvals that are vulnerable to phishing, SIM swap, and prompt bombing.
• Lowering helpdesk load by reducing password resets and account lockouts.
• Implementing conditional access: e.g., require phishing-resistant auth for admin portals, external access, or high-risk sign-ins.
• Hardening SSO: enabling WebAuthn at the IdP level so downstream apps inherit stronger authentication.

Key operational considerations:

• Device fleet reality: Not every endpoint supports every authenticator type equally. Plan for mixed OS versions and browser constraints.
• Shared workstations / kiosk mode: Platform authenticators may be inappropriate; roaming hardware keys may be better.
• Break-glass accounts: Keep at least one strongly protected, offline-stored recovery path (e.g., hardware key in a safe) with tight controls.
• Revocation & lifecycle: Define how passkeys are removed when a device is lost, an employee leaves, or suspicious activity occurs.

If you’re deciding what to standardize alongside passkeys (e.g., for residual password-based apps), see our guide: best password manager for small business 2026.

Troubleshooting passkeys: quick validation steps (browser + TLS + domain)

Many “passkey doesn’t work” issues are environmental. Checklist:

• HTTPS is required for WebAuthn on real domains (localhost is a special case for dev).
• Confirm the effective domain (RP ID) matches what the authenticator expects (watch for login pages hosted on a different subdomain).
• Ensure proxies or WAFs aren’t rewriting Origin/Host headers in a way that breaks validation.

Example: checking certificate and host alignment from a client machine:

# Verify the service is presenting the expected certificate and hostname
openssl s_client -connect login.example.com:443 -servername login.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates