Passkeys: A Passwordless Authentication Overview

• Passkeys are public-key credentials used for passwordless authentication in the FIDO2/WebAuthn ecosystem, enhancing user security and convenience.
• They leverage asymmetric challenge–response and origin binding to resist phishing, credential stuffing, and replay attacks.
• Deployment models include device-bound and synced passkeys, each balancing trade-offs between usability, recovery, and attack surface reduction.

Passkeys are passwordless authentication credentials in the FIDO2/WebAuthn ecosystem: a user-friendly form of public-key credential in which an authenticator generates a key pair $(sk, pk)$, retains the private key, and registers the public key with a relying party. In contemporary usage, the term usually denotes discoverable WebAuthn credentials, often synchronized across devices through platform credential managers, although the term is also used in other technical domains; in Bluetooth literature, for example, a “passkey” may instead denote a six-digit pairing code for Passkey Entry, not a WebAuthn credential (Dikshit et al., 2023, Bhardwaj et al., 16 Feb 2026, Sivakumaran et al., 2021).

1. Definition, terminology, and scope

In the FIDO2/WebAuthn model, a passkey is essentially a cryptographic credential used instead of a password. Registration creates a key pair $(sk, pk)$, the relying party stores $pk$ and metadata, and the authenticator later proves possession of $sk$ by signing a challenge. WebAuthn is the browser API that exposes these public-key credentials, while CTAP is the protocol between client software and the authenticator. Passkeys are therefore not a distinct cryptographic primitive so much as a deployment and user-experience layer over FIDO2/WebAuthn credentials (Büttner et al., 13 Jan 2025).

The contemporary industry meaning of “passkey” is narrower than the broader FIDO2 category. A passkey is typically a discoverable WebAuthn credential stored on a platform authenticator or credential manager and often synchronized across devices via encrypted cloud storage. This emphasis on discoverability and synchronization is what distinguishes passkeys from earlier FIDO2 deployments centered on device-bound credentials and roaming security keys (Bhardwaj et al., 16 Feb 2026).

The term is not uniform across all technical literatures. In Bluetooth Secure Simple Pairing and Bluetooth Low Energy pairing, “passkey” denotes a six-digit decimal value used in Passkey Entry, with a very different security model and threat surface from WebAuthn-based passkeys (Madugula et al., 2021). In IoT firmware analysis, “fixed passkeys” similarly refer to hardcoded BLE pairing codes such as "123456" or "000000", not passwordless web-authentication credentials (Sivakumaran et al., 2021). This terminological divergence is a frequent source of confusion.

2. Protocol architecture and cryptographic operation

Passkeys are built on asymmetric challenge–response. During registration, the authenticator generates $(sk, pk)$ and returns $pk$ together with attestation-related data; the relying party stores the public key, a credential identifier, and associated metadata. During authentication, the relying party generates a fresh challenge $c$, and the authenticator computes a signature such as

$$\sigma = \text{Sign}_{sk}(c \,\|\, \text{origin} \,\|\, \text{rp\_id} \ldots),$$

after which the relying party verifies $\sigma$ using the stored public key. In implementation-oriented descriptions, the browser invokes navigator.credentials.create() for registration and navigator.credentials.get() for authentication, while the server validates the challenge, origin, relying-party identifier, and credential counter monotonicity (Tran et al., 16 Aug 2025).

Origin binding is central. A passkey is associated with a specific origin or relying-party identifier, and the browser-authenticator stack enforces that a credential created for one domain is not used for another. This is why a passkey for example.com is not presented on examp1e.com, and why standard credential-phishing attacks do not transfer directly to passkey-based authentication (Dikshit et al., 2023).

Authenticators can be platform authenticators or roaming authenticators. Platform authenticators are embedded in a phone, laptop, or operating system and are commonly unlocked through local user verification such as PIN, fingerprint, or face recognition. Roaming authenticators are external devices such as USB/NFC/BLE security keys. In both cases, the private key is intended to remain inaccessible to ordinary application code and to be used only through authenticator-mediated signing operations (Kayali et al., 11 Jul 2025).

Cross-device use can occur without exporting secrets. One prominent flow uses a QR code on a target device, a nearby phone as the authenticator, a single-use encryption key, Bluetooth-based proximity signaling, and encrypted CTAP traffic relayed through a server that sees only ciphertext. The result is that the phone signs the WebAuthn challenge for the target device without disclosing the private key to it (Dikshit et al., 2023).

3. Security properties and attack surface

Passkeys are designed to mitigate several failure modes of password systems. There is no shared secret to guess, reuse, or exfiltrate from a relying-party database; each relying party gets a distinct public key; each authentication uses a fresh challenge; and the private key never leaves the authenticator. These properties yield strong resistance to phishing, credential stuffing, replay, and verifier compromise, and they are the basis for the widespread characterization of passkeys as phishing-resistant (Blessing et al., 2024).

The security case is strong, but not absolute. A comparative evaluation using Bonneau et al.’s framework finds that all passkeys, whether device-bound or synced, provide strong properties including Resilient-to-Phishing, Resilient-to-Throttled/Unthrottled-Guessing, Resilient-to-Leaks-from-Other-Verifiers, and Unlinkable. The major differences arise elsewhere: synced passkeys only partially provide Resilient-to-Internal-Observation and do not provide No-Trusted-Third-Party, because the passkey provider becomes part of the trust set (Büttner et al., 13 Jan 2025).

Recent attack studies sharpen this distinction between protocol strength and ecosystem strength. One analysis concludes that the phishing-resistance claim “largely holds true,” but also demonstrates two advanced attacks: an Infected Authenticator attack, in which a corrupted authenticator generates attacker-known keys, and an Authenticator Deception attack, in which an attacker modifies a browser’s certificate authority store, installs a valid certificate, relays a legitimate challenge from the real server, and causes the victim to sign it. The paper’s central conclusion is that successful attacks on passkeys require substantial effort and resources and significantly raise the bar relative to passwords (Berladskyy et al., 22 Apr 2026).

A second line of work shows that CTAP itself is a critical attack surface. “CTRAPS” identifies client impersonation and API-confusion attacks that exploit the lack of CTAP client authentication and insufficient API-level enforcement, enabling actions such as credential deletion, user tracking, and even zero-click factory reset of authenticators over NFC. The attacks were validated on six popular authenticators, including a FIPS-certified Yubico model, and ten relying parties, including Microsoft, Apple, GitHub, and Facebook (Casagrande et al., 2024). A plausible implication is that the main residual risks in passkey deployments increasingly arise from client–authenticator trust boundaries, destructive authenticator management operations, and recovery workflows rather than from the core WebAuthn signature protocol.

4. Device-bound credentials, synchronization, and recovery

A major distinction in the passkey literature is between device-bound and synced credentials. Device-bound passkeys are created and stored on one device only, with the private key living in secure hardware such as a TPM, Secure Enclave, or security key, and not being exportable. Synced passkeys are available across multiple devices through a passkey provider, typically using end-to-end encryption, but because the private key or its representation must move between devices, the provider and its account security become a critical trust anchor (Büttner et al., 13 Jan 2025).

This distinction creates a clear availability–security trade-off. Device-bound passkeys have the lowest remote attack surface and the strongest hardware-centric protection, but loss of the authenticator can be catastrophic unless separate recovery paths exist. Synced passkeys improve cross-device availability and recovery because multiple devices can authenticate, but they also increase remote attack surface through malware, provider-account compromise, sharing, export, and provider-side compromise. The comparative evaluation explicitly characterizes the security of synced passkeys as being “mainly concentrated in the passkey provider” (Büttner et al., 13 Jan 2025).

Large platform ecosystems address this by embedding passkeys in end-to-end encrypted synchronization systems. Apple stores passkeys in iCloud Keychain, always under end-to-end encryption, with decryption keys protected by hardware security modules that rate-limit recovery attempts; Google stores passkeys in Google Password Manager with end-to-end encrypted backups and recovery tied to the Google account and an existing device’s lock-screen secret (Blessing et al., 2024). This suggests that modern passkey deployments inherit many of the recoverability and account-lifecycle challenges of end-to-end encrypted services.

Cross-device recovery remains an open problem in adjacent systems as well. In VA-DAR, for example, device-bound passkeys are used only for local daily unlock via a passkey-exposed pseudorandom function, while cross-device recovery uses an identifier and a recovery passphrase to locate and decrypt a backup artifact; the passkey is then re-established on the new device rather than transferred (Wang, 3 Mar 2026). This design is not standard WebAuthn passkey synchronization, but it illustrates one research direction for separating local authentication from portable recovery.

5. Standardization, deployment, and adoption

Passkeys are specified primarily by the W3C and the FIDO Alliance, but they are embedded in a broader Internet standards stack. They operate over TLS and HTTPS, can run over QUIC and HTTP/3, and are complemented by other privacy technologies under IETF standardization such as encrypted DNS, Privacy Pass, Private Access Tokens, MASQUE, and Private Relay. In that framing, passkeys are an application-layer privacy technology that solves “who is this user?” without exposing shared secrets, while transport- and network-layer mechanisms reduce exposure of metadata such as destination lookups and client IP address (Dikshit et al., 2023).

Platform support has been driven largely by Apple, Google, and Microsoft. Early deployments emphasized Apple’s iOS and macOS with iCloud Keychain, Google’s passkey support on Android and Chrome, and Windows Hello–based equivalents, though interoperability and synchronization behavior have remained fragmented across platforms and browsers (Büttner et al., 13 Jan 2025). Implementation guidance reflects this heterogeneity: a practical passkey system commonly combines a WebAuthn server library, persistent storage of credential IDs, public keys, counters, and device names, and surrounding middleware for sessions, rate limiting, and fallback authentication paths (Tran et al., 16 Aug 2025).

Empirical adoption studies show both rapid growth and methodological complexity. A 2024 survey of 94 top-200 sites with account creation found that 28 sites, or 29.8%, directly supported passkeys, while 31 sites, or 33.0%, offered indirect support through SSO providers that themselves supported passkeys; combined direct and indirect support reached 59 of 94 sites, or 62.8% (Blessing et al., 2024). A 2026 census of the top 100,000 Tranco-ranked domains found that 11.3% of reachable sites supported passkeys, with adoption strongly correlated with site popularity: 20% among the top 100 sites and 6.9% among ranks 50,000–100,000 (Bhardwaj et al., 16 Feb 2026). The same census found that adoption often depended on external identity providers rather than native implementations, and that Google appeared on 75.2% of passkey-supporting sites as an external IdP (Bhardwaj et al., 16 Feb 2026).

Sectoral distribution is uneven. Business and Finance, Shopping, and Technology & Computing dominate the passkey-supporting set, and the banking and financial-services category shows particularly strong uptake, whereas healthcare and government remain comparatively sparse (Bhardwaj et al., 16 Feb 2026). A plausible implication is that fraud pressure and user-account value are stronger deployment drivers than the generic maturity of web authentication stacks.

6. Specialized deployments, alternative architectures, and adjacent meanings

Although passkeys emerged in web authentication, recent work extends them into other protocols and environments. “SSH-Passkeys” integrates WebAuthn with stock SSH servers via PAM, requiring no new client-side software and preserving the usual ssh command-line workflow. In a study with 40 SSH users, the prototype yielded a 90% reduction in critical security errors and reduced authentication time by 4x on average, while also offering protection for cryptographic material at rest, phishing protection, privacy protection, and attestation capability (Kayali et al., 11 Jul 2025).

Captive-portal network access is another extension. FIDO2CAP adapts WebAuthn and passkeys to Wi-Fi hotspot authentication through a captive portal, and later usability work on a router implementing FIDO2CAP compared passkeys with passwords in a controlled laboratory study with 50 participants across Android and Windows. That study reported a tendency for passkeys to be perceived as more usable than passwords during login, although differences were not statistically significant, and identified captive-portal limitations and platform-specific issues as major sources of friction; recommended remedies included usernameless flows, improved captive-portal detection, and interface changes (Rivera-Dourado et al., 2024, Rivera-Dourado et al., 26 Mar 2026).

Research also explores alternative architectures beyond mainstream platform-synced passkeys. “Verifiable Passkey” proposes a decentralized model in which a passkey created with a Verifiable Credential issuer can be used across multiple verifiers without the issuer remaining in the login path, with PageX serving as a static webpage that hosts WebAuthn interactions under the issuer’s domain (Mitra et al., 25 Dec 2025). “TUSH-Key” proposes cross-platform synchronization without storing private FIDO keys in proprietary clouds: each device enrolls its own FIDO keypair, while a separate server coordinates device onboarding through Diffie–Hellman key exchange and encrypted access tokens (Mitra et al., 2023).

Finally, the word “passkey” remains polysemous outside the WebAuthn ecosystem. In Bluetooth Secure Simple Pairing, Passkey Entry is a protocol in which devices authenticate a shared six-digit passkey bit by bit through commitments and nonces, and recent work proposes an enhanced passkey entry protocol that replaces direct use of passkey bits with a hash-derived representation to improve security against passive eavesdropping and active MITM (Madugula et al., 2021). In BLE/IoT firmware analysis, “fixed passkeys” are static six-digit pairing codes hardcoded into device firmware; one large-scale study of stripped ARM Cortex-M binaries found a real-world binary containing the fixed passkey "000000" (Sivakumaran et al., 2021). These uses are conceptually unrelated to FIDO2/WebAuthn passkeys, despite the shared term.

Passkeys, in their dominant modern sense, are therefore best understood as a family of origin-bound, public-key, authenticator-mediated credentials that replace passwords in user-facing authentication. Their defining technical properties are asymmetric challenge–response, local user verification, and per-relying-party credential separation; their main practical debates concern synchronization, recovery, authenticator management, and the security of the client–authenticator boundary rather than the underlying signing primitive itself (Dikshit et al., 2023)