Using Passkeys and PRF for End-to-End Encryption (2025)

WebAuthn & Passkeys has revolutionized web authentication, offering phishing-resistant, passwordless logins through public-key cryptography. But its capabilities extend beyond sign-ins. An exciting feature is the Pseudo-Random Function (PRF) extension. This extension allows web applications to derive secret keys directly from a user's passkey or hardware security key during authentication. This unlocks end-to-end encrypted data or decrypting a secure vault using only your passkey, without needing a separate password. In this article we want to answer the following question:

• PRF use cases: What are interesting use cases to use PRF for?
• PRF support: What's the real current support of PRF across operating systems and browsers today?

This article analyzes the WebAuthn PRF extension, exploring its technical specifications, use cases, implementation details, security considerations and the current landscape of browser and operating system support.

The PRF extension (prf) is formally defined in the WebAuthn Level 3 specification. Its core purpose is to allow a Relying Party (your web application) to request the evaluation of a pseudo-random function associated with a specific WebAuthn credential (passkey) during an authentication ceremony (navigator.credentials.get()).

A PRF takes a secret key (held securely within the authenticator and tied to the credential) and one or more input values (provided by the Relying Party) to produce a deterministic, cryptographically random-looking output. This output, typically a 32-byte string, can then be used by the client-side application, most notably as symmetric key material for encryption or key derivation.

Many authenticators, particularly FIDO2 security keys, implement an underlying capability defined in the Client-to-Authenticator-Protocol (CTAP2) called the hmac-secret extension. This CTAP2 extension provides access to a hardware-backed HMAC (Hash-based Message Authentication Code) function, which serves as the pseudo-random function. The WebAuthn PRF extension acts as a standardized way for web applications to access this hmac-secret capability through the browser's WebAuthn API.

To prevent potential conflicts or security issues where a website might trick the authenticator into generating HMACs intended for non-web purposes (like local OS login), the WebAuthn specification mandates an important step: the inputs provided by the website (first and second salts) are first hashed with a specific context string ("WebAuthn PRF" and a null byte) before being passed to the underlying hmac-secret function. This effectively partitions the PRF's input space, ensuring that web-derived outputs are distinct from those potentially used in other contexts.

The ability to derive authenticator-bound keys unlocks several compelling use cases for developers:

1. Client-Side / End-to-End Encryption (E2EE): This is the primary motivator for the PRF extension. Browser based applications can derive a unique encryption key per credential during login. This key can then be used with the WebCrypto API to encrypt user data stored locally or on the server. The data remains encrypted at rest and can only be decrypted by the user after successfully authenticating with the specific passkey, enhancing privacy and data security. Service providers can store user data without ever having access to the plaintext. This is especially helpful for applications in the passwordless world, because without the PRF extension, they would need to additionally request a secret in the form of a password, which contradicts the passwordless architecture.

2. Passwordless Vault Decryption: Services like password managers (e.g., Bitwarden, 1Password) or secure note apps (e.g., Notesnook , Reflect) can use PRF to replace the traditional master password. The user authenticates with their passkey, the PRF extension derives the vault decryption key and the vault is unlocked - no master password required. Bitwarden has announced support for this.

3. Secure Key Rotation: The PRF extension allows providing two input "salts" (first and second) during authentication. This facilitates cryptographic key rotation schemes. A server could request the "current" key using first and the "next" key using second. Over time, the server can update which salt corresponds to the current key, allowing for seamless rotation without disrupting the user experience. This is especially important in case regulatory requirements or internal policies require all keys to be rotated within a specific schedule and increases security.

4. Identity Wallets & Non-Custodial Systems: PRF can derive keys for securing identity data within digital wallets or enable non-custodial systems where private keys are never exposed server-side.

While the specification is defined, actual browser and platform support is the critical factor for developers. Support has been evolving and, until recently, was primarily limited to Chromium-based browsers. Tracking support can be challenging as there isn't a dedicated entry on CanIUse.com for the PRF extension itself (searching for "webauthn" shows general API support, but not specific extensions). Information must often be gathered from browser release notes, bug trackers and status pages. Successfully using the WebAuthn PRF extension requires a coordinated effort across three distinct layers of the technology stack. Support must be present at each level for the feature to function:

1. The Authenticator: This is the hardware (like a security key) or platform component (like Windows Hello, iCloud Keychain and the corresponding hardware module e.g. TPM or Secure Enclave) that securely stores the credential's secret key and performs the actual pseudo-random function calculation (typically using the CTAP2 hmac-secret capability). If the authenticator lacks this fundamental cryptographic capability, PRF cannot work.

2. The Operating System (OS): The OS acts as the bridge between the browser and the authenticator. It provides the necessary drivers and system-level APIs for the browser to discover, communicate with, and request operations from authenticators (especially platform authenticators and those connected via USB/NFC/Bluetooth). The OS must be able to recognize and expose the authenticator's PRF (hmac-secret) capability to the browser. If the OS doesn't provide this pathway, the browser cannot access the feature.

3. The Browser: As the interface for the web application, the browser must implement the WebAuthn JavaScript API, specifically recognize the prf extension, translate the web request into the appropriate commands for the OS/authenticator, handle the crucial security step of hashing inputs with the context string, and correctly parse and return the results to the application.

A failure or lack of support at any of these three tiers Authenticator capability, OS exposure, or Browser implementation will prevent the PRF extension from working.

This sequence chart shows a simplified version of how these actors work together to facilitate PRF support.

The journey toward broad PRF support highlights a common challenge with web standards extensions: implementation is often staggered, with platform-specific issues needing resolution. We’ll aim to keep this table updated, but keep in mind that since the PRF extension is one of the latest additions requiring the entire compatibility chain to adapt, ongoing adjustments are expected.

In the table above, we’ve included the most important combinations for first-party passkey provider support. However, when using password managers as third-party passkey providers, their specific capabilities must be considered separately. For example, 1Password supports PRF in its Android version but not in its iOS version. Also Chrome Profile as authenticator does not support prf.

You can experience the WebAuthn PRF extension directly using our interactive demo application. In this demo, you'll be able to:

• Register a passkey with PRF and confirm if your authenticator supports this powerful extension.
• Authenticate using your passkey and view the PRF-generated cryptographic value in action.

Seeing the PRF value yourself highlights the practical implications of using passkeys for secure, key-based operations. It allows you to directly verify authenticator compatibility and observe how PRF-derived keys can power end-to-end encryption and secure vault decryption without passwords.

Take a moment to try the demo—understanding your specific environment's PRF capability helps you better plan secure, passwordless experiences tailored to your users.

Ready to test the power of PRF? Click the image above or follow this link to start your hands-on exploration.

PRF isn't the only WebAuthn extension related to storing or deriving data. How does it compare?

• PRF vs. credBlob / largeBlob:

  • credBlob: Allows storing a tiny (32 bytes) static blob with the credential, possibly at creation time. It wasn't designed primarily for secrets, and support is limited, especially for non-discoverable credentials.

  • largeBlob: Enables storing more data (~1KB) with discoverable credentials, often intended for auxiliary data like certificates. Support is also limited (supported by iCloud Keychain since iOS 17, but not by GPM). Chrome developers explicitly favored focusing on PRF over largeBlob for most use cases, although development might happen in the future.

  • PRF: In contrast, PRF is specifically designed to derive secret keys on demand during authentication using a hardware-bound secret, rather than storing a static blob. It is generally considered the most appropriate and secure standard mechanism for deriving encryption keys tied to a passkey. The evolution from discussing blobs for secrets to the standardization and implementation focus on PRF suggests a convergence on PRF as the dedicated solution for this use case.

• PRF vs. Password-Derived Keys (e.g., PBKDF2): Traditionally, client-side encryption keys were derived from user passwords. PRF offers significant advantages:

  • Stronger Source: Keys are derived from strong cryptographic material within the authenticator, not potentially weak or reused passwords.

  • Phishing Resistance: Derivation is tied to the phishing-resistant WebAuthn authentication flow.

  • Passwordless: Enables use cases like vault decryption without requiring a password at all.

• PRF vs. Other WebAuthn Data: Attempting to derive keys from other parts of the WebAuthn response (like the signature, authenticatorData, or the public key) is fundamentally insecure and incorrect. These components are either public, non-secret, or designed for verification, not key derivation.

For securely deriving cryptographic key material linked directly to a WebAuthn credential or passkey, the PRF extension is the purpose-built and recommended standard approach.

When integrating the PRF extension into your application, consider these practical guidelines:

The following recommendations help developers navigate the current state of PRF support effectively and plan for future developments:

• Treat PRF Opportunistically:
  Support for the PRF extension currently varies significantly across browsers, operating systems, and authenticators. Therefore, treat PRF integration as an enhancement rather than a core dependency.

• Avoid Critical Dependence on PRF:
  Avoid making PRF essential for mission-critical functionality. Current support, particularly on platforms like Safari on macOS and iOS, remains inconsistent and incomplete.

• Prepare for Passkey Loss Scenarios:
  Remember that data encrypted with PRF-derived keys is bound exclusively to the specific passkey. Losing the passkey will permanently render the encrypted data inaccessible. Always implement robust backup and recovery mechanisms.

• Anticipate Broader Support by 2026:
  PRF support is rapidly maturing. By 2026, anticipate consistent availability across major browsers, operating systems, and authenticators, particularly with first-party passkey providers.

• Monitor Windows Ecosystem:
  Platform authenticator support via Windows Hello is currently absent. Full PRF integration in Windows environments relies heavily on Microsoft's adoption strategy, so keep this ecosystem under close observation.

Following these guidelines ensures developers can smoothly incorporate PRF while maintaining compatibility and security during its adoption phase.

Understanding how PRF aligns with your overall passkey strategy helps you maximize its benefits without unnecessary complications:

• Flexible Integration:
  It is not necessary to decide whether to leverage PRF at the moment of passkey creation. Existing passkeys can later be seamlessly integrated with PRF use cases without additional credential management overhead.

• Retrofitting PRF:
  Since PRF operates during the authentication phase (navigator.credentials.get()), previously created passkeys can support PRF-based workflows at a later stage. This allows your application to enhance security incrementally without disrupting established authentication methods. This approach works with iCloud Keychain and Google Password Manager (GPM) and newer security keys. For older security keys an hmac-secret might only be generated if requested on creation of the credential.

• Passkey Complexity Considerations:
  The complexities inherent to passkey management—such as credential synchronization, cross-device authentication, and recovery processes—apply equally when using PRF. Ensure your PRF implementation aligns cohesively with your overall passkey authentication strategy, maintaining streamlined user experiences and robust security controls.

Considering PRF as part of a holistic passkey strategy enables a smoother transition to more secure and user-friendly authentication practices.

For enterprises service providers handling sensitive user data, the ability to leverage WebAuthn PRF alongside passkeys opens up possibilities for enhancing security and user experience, particularly in scenarios requiring client-side encryption of Personally Identifiable Information (PII) or securing applications that require End-2-End Encryption. While Corbado Connect is primarily designed for seamless enterprise passkey integration, it can facilitate also the implementation of passkey extensions such as SPC or PRF.

Here’s how Corbado can assist organizations looking to integrate PRF:

• Facilitating PRF for Encrypted Storage: In enterprise settings there's is sometimes a requirement to store sensitive information securely, maybe sometimes even directly on the client-side to minimize server-side PII exposure. Corbado Connect can be configured to request PRF values during the passkey authentication flow (navigator.credentials.get()), enabling applications to derive the necessary cryptographic keys.
• Flexible Storage Patterns: The data encrypted using PRF-derived keys can be stored in various ways depending on the security requirements and architecture:
  • Client-Side: Stored directly in the browser using mechanisms like localStorage or secure Cookies. The plaintext data only exists transiently on the client during decryption.
  • Corbado Backend (E2EE): While Corbado generally avoids storing customer PII, the PRF mechanism technically allows for storing client-side encrypted data on Corbado's servers. Corbado would not possess the keys to decrypt this data; decryption would still happen client-side after successful user authentication.
  • Client's Backend: The encrypted data could also be sent to and stored on the enterprise's own backend systems, still benefiting from client-side encryption.
• Secure Key Derivation Flow: Corbado Connect components manage the interaction with the WebAuthn API. When PRF is requested:
  1. A user-specific PRF output is generated by the authenticator, tied to the individual passkey.
  2. This output is securely returned to the client-side application.
  3. The application should then use a Key Derivation Function (KDF) via the WebCrypto API (e.g., HKDF) to derive a robust symmetric encryption key from the PRF output.
  4. This symmetric key is used with WebCrypto (e.g., AES-GCM) to encrypt or decrypt the target information (like PII).
• Seamless Decryption on Subsequent Logins: When the user authenticates again using the same passkey, While Corbado Connect initiates the same PRF request. This yields the identical PRF output, allowing the application to re-derive the same symmetric key and decrypt the previously stored information client-side.
• PRF Adoption Intelligence: Implementing PRF requires knowing if the user's environment (OS, browser, authenticator) supports it. Corbado Connect collects signals about the user's device and capabilities during authentication. This intelligence can be used to:
  • Determine PRF readiness across the user base before fully activating PRF-dependent features.
  • Implement PRF opportunistically, providing it as an enhancement for supported users while maintaining fallback mechanisms (like prompting for re-verification or using alternative methods) for those without support.
• Streamlining PII Availability: By using PRF to encrypt verified PII (e.g., identity attributes obtained through a verification flow) and storing it client-side, applications can make this data immediately available after a passkey login for subsequent interactions or transactions, significantly reducing friction compared to re-verification or app-based flows.
• Enabling Custom E2EE Systems: While Corbado Connect offers UI components for standard flows, the underlying principles can allow developers to integrate the PRF functionality more deeply into sensitive applications. This enables building end-to-end encrypted systems where the frontend application directly leverages the PRF-derived keys for complex cryptographic operations on existing or new data. For the time being this still will only be possible opportunistic and fallback mechanisms need to implement a different way to store those information.

Corbado aims to simplify the complexities of passkey and PRF integration, allowing enterprises to leverage standards securely and effectively, adapting to specific use cases like client-side PII encryption while navigating the evolving landscape.

The WebAuthn PRF extension marks an important step forward in making truly passwordless, end-to-end encrypted applications a practical reality. By leveraging passkeys to securely derive cryptographic keys, it provides a seamless and secure user experience without compromising on privacy.

Directly answering the questions posed at the start of this article:

• Interesting PRF use cases: PRF enables compelling use cases such as end-to-end encrypted data storage, passwordless vault decryption for password managers, secure cryptographic key rotation schemes, and secure identity wallets or non-custodial systems that protect user privacy by ensuring private keys never leave client devices.

• Current state of PRF support (April 2025): Support remains fragmented and evolving. While Android has robust support across browsers and authenticators, platforms like macOS and iOS are shaky, particularly within Safari and WebKit-based browsers. Windows support is limited primarily to external security keys, with native platform support via Windows Hello notably absent.

Developers considering the PRF extension should anticipate rapid improvement, yet proceed cautiously, building resilient applications that gracefully handle the current limitations. As broader adoption emerges in major platforms and authenticator ecosystems, the future for PRF-enabled passwordless encryption appears bright, promising enhanced privacy and usability in web authentication.