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

Passkeys are a phishing-resistant way to sign in without a password, built on FIDO2/WebAuthn and public key cryptography. Instead of typing a shared secret, users approve a login with a device authenticator (biometric or PIN) and the server verifies a cryptographic signature—no password is transmitted.

How passkeys work

At a practical level, passkeys shift authentication from “shared secret” (password) to “proof of possession” (a cryptographic private key) plus local user verification (biometric/PIN). The website/app only stores a public key and verifies cryptographic signatures.

1) Registration (creating a passkey)

When a user chooses “Create passkey” (or “Use passkey”), the service initiates a WebAuthn registration ceremony:

• Server generates a challenge (random nonce) and WebAuthn options (relying party ID, user handle, algorithms, etc.).
• Client (browser/app) calls WebAuthn to create a credential using a platform authenticator (built into the device) or a roaming authenticator (e.g., hardware security key).
• Authenticator creates a key pair:
• Private key is stored in secure hardware or OS keystore.
• Public key is returned to the server along with attestation data (optional / policy-driven).
• Server stores the public key, credential ID, and metadata (e.g., sign counter, transports).

Result: the account now has an associated credential that can be used without a password.

2) Authentication (signing in with a passkey)

On login, the service initiates a WebAuthn authentication ceremony:

• Server sends a challenge and allowed credential IDs (or uses “discoverable credentials,” where the authenticator can select the right credential).
• User unlocks the authenticator (Face/Touch, Windows Hello, Android screen lock, or a PIN on a hardware key).
• Authenticator signs the challenge with the private key.
• Server verifies the signature using the stored public key and validates:
• Correct relying party (RP) ID (prevents “phishing site” replay).
• Challenge freshness (prevents replay).
• Optional checks like sign counter / device binding policies.

No password is typed, stored, or transmitted—so common attacks (credential stuffing, password spraying, OTP interception) are dramatically reduced.

3) Why passkeys are phishing-resistant

Passkeys use an RP ID (typically the domain) as part of the protocol. A credential created for example.com won’t authenticate to examp1e.com. Even if a user is tricked into clicking a phishing link, the browser/authenticator won’t produce a valid signature for the attacker’s site.

4) Device sync vs. hardware keys (important operational difference)

In practice, you’ll encounter two broad passkey storage models:

• Platform passkeys (often syncable / multi-device credentials): Stored in an OS or password manager ecosystem and may sync across a user’s devices. This improves usability (new phone, same account), but requires you to think about recovery and account takeover risk if the ecosystem account is compromised.
• Roaming passkeys (hardware security keys): Private keys stay on the physical key; no cloud sync. Strong for admins and high-risk users, but more friction and requires key management (spares, inventory, loss process).

Security teams should define which is acceptable for which user populations (e.g., executives/admins vs. general workforce).

Practical tip: password managers and passkeys (and when it makes sense)

Many teams pair passkeys with a reputable password manager to centralize credential inventory, improve recovery outcomes, and reduce “shadow IT” sign-in storage. If you’re evaluating options, 1Password supports passkeys in many workflows and can simplify cross-device usage for end users: Try 1Password →.

Technical notes: Minimal WebAuthn data flow (conceptual)

A simplified view of the browser-to-server exchange:

Registration:
Server -> Client: challenge, rpId, userId, pubKeyCredParams, authenticatorSelection
Client -> Authenticator: createCredential(challenge, rpId, userId, ...)
Authenticator -> Client: credentialId, publicKey, attestationObject
Client -> Server: credentialId, publicKey, attestation (optional)

Authentication:
Server -> Client: challenge, rpId, allowCredentials (or discoverable)
Client -> Authenticator: getAssertion(challenge, rpId, ...)
Authenticator -> Client: credentialId, signature, authenticatorData
Client -> Server: credentialId, signature, authenticatorData
Server: verify(signature, publicKey) + validate rpId/challenge

Technical notes: What to log for troubleshooting

For operational visibility, log (at minimum) the following fields for registration/auth attempts:

• user identifier (internal ID, not email if possible)
• RP ID / origin
• WebAuthn result (success/failure)
• failure reason category (e.g., challenge_mismatch, rpId_mismatch, credential_not_found, user_cancel, policy_denied)
• authenticator type (platform vs cross-platform), if available
• AAGUID (if you use it for policy/allow-listing), if available
• client user agent + OS version (helps isolate platform bugs)

Avoid logging raw challenges, full authenticator blobs, or attestation objects unless you have a strong need and a secure logging pipeline.

Where you’ll encounter passkeys

Passkeys are no longer niche. You’ll encounter them in both consumer and enterprise contexts, and you’ll need to make decisions about rollout, policy, and fallback.

1) “Sign in with passkey” prompts on major sites/apps

Users will see UI such as:

• “Use passkey”
• “Create a passkey”
• “Continue with biometrics”
• “Use security key” (sometimes grouped with passkeys)

This often appears after a normal login, as part of an account security upgrade, or as a default sign-in method on supported devices.

2) Workforce identity providers and SSO platforms

In enterprise environments, passkeys may appear as:

• a replacement for password + MFA
• a stronger factor for privileged access
• a phishing-resistant MFA requirement for admin consoles

Expect policy questions like: - Do we allow synced passkeys for workforce accounts? - Do we require hardware keys for admins? - How do we handle BYOD vs managed devices?

3) Device enrollment and account recovery workflows

Passkeys improve day-to-day login, but recovery is where security teams get burned if they don’t plan ahead.

You’ll encounter passkeys during: - new device setup (migrating credentials) - lost phone/laptop scenarios - employee offboarding (ensuring credentials don’t remain usable) - break-glass access (when the passkey isn’t available)

Plan for: - multiple registered authenticators per account (at least 2) - verified recovery methods (in-person, HR-validated, helpdesk with strong identity proofing) - policy-driven fallback (temporary codes, hardware keys, or tightly-scoped step-up)

A useful way to pressure-test your recovery design is to think in terms of impact radius when a credential is lost or abused—see what is the blast radius of a credential.

4) Browser and endpoint management considerations

Passkey readiness intersects with endpoint security and IT operations:

• OS/browser versions must support WebAuthn well.
• Managed devices may need policy settings for platform authenticators.
• Remote access and VDI environments can complicate platform authenticator use; hardware keys often work more predictably.

Technical notes: Quick CLI checks for WebAuthn endpoints (service owners)

If you run the relying party (the server), ensure your auth endpoints enforce strong TLS and correct origin handling. Basic TLS inspection:

# Check TLS and certificate chain basics
openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

# Verify HTTP security headers commonly used alongside authentication pages
curl -sI https://yourdomain.tld/login | egrep -i 'strict-transport-security|content-security-policy|x-frame-options|permissions-policy'

Passkeys don’t replace the need for secure session management, CSRF protections, and strong origin controls.