Passkeys & WebAuthn PRF for End-to-End Encryption (2026)

Live PRF testing: Try the WebAuthn PRF Demo - now with community-submitted test results from real devices and browsers to help keep this page up to date.

1. Introduction to Passkeys & WebAuthn PRF Extension#

WebAuthn and passkeys are known for phishing-resistant, passwordless logins, but their capabilities extend beyond sign-ins. The WebAuthn Pseudo-Random Function (PRF) extension lets a web application derive secret keys directly from a user's passkey or hardware security key during authentication. That is what makes end-to-end encryption or a vault that opens with a passkey possible without a second secret. This article answers three questions:

1. Passkey PRF use cases: what is the extension actually good for?
2. PRF extension support: what is the real support across operating systems and browsers today?
3. Credential managers: what happens when the user's passkey lives in 1Password, Bitwarden or Enpass instead of in the platform provider?

This article builds on the groundwork laid by Matthew Miller and Levi Schuck in 2023, who covered the mechanics and published the first live tests.

2. What is the WebAuthn PRF Extension and why does it matter?#

The WebAuthn PRF extension (PRF) is formally defined in the WebAuthn Level 3 specification. It lets a Relying Party (your web application) ask the authenticator to evaluate a pseudo-random function tied to one specific WebAuthn credential (passkey) during an authentication ceremony (navigator.credentials.get()).

A PRF takes a secret key, which stays inside the authenticator and belongs to that one credential, plus one or more input values from the Relying Party and returns a deterministic output that is indistinguishable from random. The output is 32 bytes, which is exactly the size of a symmetric key, so the client can hand it to the WebCrypto API without further processing.

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 specification adds one step: the salts supplied by the website are hashed together with a fixed context string ("WebAuthn PRF" and a null byte) before they reach the hmac-secret function. This splits the input space, so a value derived on the web can never collide with one used elsewhere.

3. WebAuthn PRF Use Cases: Enabling End-to-End Encryption#

Keys that are bound to an authenticator are useful in four situations:

1. Client-Side / End-to-End Encryption (E2EE): This is what PRF was designed for. A browser application derives one encryption key per credential at login. This key can then be used with the WebCrypto API to encrypt user data stored locally or on the server. The data can only be decrypted after a successful authentication with that specific passkey, so the service provider never holds the plaintext. Without PRF, a passwordless application would have to ask for a password anyway just to get key material, which defeats the point.

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, PRF derives the vault decryption key and the vault opens, with no master password involved. Bitwarden and Dashlane have both shipped this. Note that this is the manager acting as a relying party for its own vault, which is a different thing from returning PRF results to your site, see section 5.3.

3. Secure Key Rotation: PRF accepts two input salts, first and second, in the same authentication. That is what makes rotation possible: the server asks for the current key with first and for the next one with second. Over time, the server can update which salt corresponds to the current key, so keys can be rotated without a re-enrollment step for the user. That matters wherever a policy or regulation prescribes a rotation schedule.

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.

4. PRF Extension Support: Browser, OS and Authenticator#

CanIUse.com has no entry for the PRF extension, so the state of support has to be pieced together from release notes and bug trackers. That is what the tables below do. Support has to be present at all three layers of the stack for the feature to work at all:

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). Without it, nothing further up the stack helps.

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 commands the OS and authenticator expect, hash the inputs with the context string and parse the results back to the application.

A failure or lack of support at any of these three tiers, meaning 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.

5. Understanding WebAuthn PRF Support Across the Stack (updated August 2026)#

A functioning PRF workflow requires every layer in the WebAuthn ↔ CTAP chain to cooperate.
For clarity, we separate the discussion into (1) browser + operating‑system behavior and (2) authenticator behavior.

5.1 WebAuthn PRF Support in Browsers and Operating Systems#

5.1.1 Windows WebAuthn PRF Support#

Historically, PRF support on Windows was limited because Windows Hello lacked the necessary hmac-secret capability. That changed with the February 2026 cumulative update (KB5077181) which patched hmac-secret support into Windows Hello on 25H2 (build 26200.7840+). Earlier 25H2 builds before this update do not have PRF support. This was first reported by the Bitwarden community.

Windows introduced the necessary platform support with WEBAUTHN_API_VERSION_8, which exposes PRF evaluation during both credential creation and authentication.

On the browser side, Firefox 148+ correctly handles this and fully supports PRF with Windows Hello on both creation and authentication (creation-time support was backported to Firefox 147). Chrome 147 has committed support for PRF on create on Windows (tracked in issue 446157741) and enabled it by default. Chrome/Edge 146 and below do not yet surface PRF support from Windows Hello during creation.

5.1.2 macOS WebAuthn PRF Support#

With macOS 15, PRF support has arrived for platform authenticators. Both Safari and Chrome support PRF via iCloud Keychain. Firefox support for the platform authenticator is available since Firefox 139. Security Keys only work with Chrome.

Safari on macOS 26.4 / iPadOS 26.4 also has two open WebKit bugs that affect PRF with CTAP2 security keys (platform authenticators are unaffected): WebKit 311099 returns the AES-256-CBC encrypted hmac-secret undecrypted on USB/NFC keys, breaking cross-browser interop, and WebKit 314934 returns null PRF results for YubiKey Bio and other intervalUV keys that skip the PIN entry flow.

5.1.3 iOS and iPadOS WebAuthn PRF Support#

The status on iOS and iPadOS mirrors macOS, with PRF working via iCloud Keychain. However, there are significant caveats: a bug in early versions of iOS 18 can lead to data loss, support for external security keys is not yet implemented on iOS, and iPadOS 26.4 inherits the same WebKit security-key PRF issues described in the macOS section.

5.1.4 Android WebAuthn PRF Support#

Android has the broadest PRF support today. Passkeys stored in Google Password Manager include PRF support by default, and it works across most major browsers, with the exception of Firefox.

These tables cover the first-party passkey providers. Passkeys stored in a third-party credential manager follow that manager's capabilities instead, which section 5.3 covers. One exception worth knowing: the Chrome profile authenticator does not support PRF at all.

5.2 Authenticator Support for the WebAuthn PRF Extension#

While WebAuthn specifies what a Relying Party can ask for, the Client‑to‑Authenticator Protocol (CTAP) defines how the authenticator must behave. In practice, authenticators fall into four categories:

1. No PRF support: Older platform authenticators (e.g., Windows Hello on pre-25H2 builds), legacy security keys without the hmac‑secret extension and third-party providers that have not adopted PRF yet.

2. PRF only if the PRF flag was set at credential creation: Some CTAP 2.0/2.1 security keys expose hmac‑secret, but will refuse PRF evaluations unless the Relying Party requested it when the credential was first created to initialize the secrets.

3. PRF available on authentication even when not requested at creation: Newer hardware tokens, iCloud Keychain and Google Password Manager expose hmac‑secret unconditionally. Credentials created without the flag still work with PRF during navigator.credentials.get(). Samsung Pass belongs here too, and it is the reason this category matters in practice: our registration on a Galaxy phone came back with no PRF extension result at all, and the following authentication returned a value. A relying party that decides at registration time would have ruled it out.

4. Full CTAP 2.2 compliance (PRF + first PRF value on creation): Platform authenticators that sync passkeys, such as iCloud Keychain and Google Password Manager, can on request return the first PRF output already during navigator.credentials.create(), which saves a separate authentication round for key establishment.

Knowing which bucket an authenticator belongs to is essential when you design backup, migration or key‑establishment logic. We've also included tests for these scenarios in our demo.

5.3 PRF Support by Credential Manager#

The tables above cover browsers, operating systems and authenticator classes. In production a third axis decides the outcome, and it is the one the user controls: which credential manager is set as the default passkey provider.

A user on Android with Google Password Manager and the same user with a third-party manager get different results. Since Android 14 and Windows 11 25H2, third-party managers act as full passkey providers, so this is not an edge case anymore.

One distinction matters before reading the tables. A credential manager can use PRF in two completely different roles:

• As a relying party. It derives its own vault key from a passkey, which is what replaces the master password. Dashlane and Bitwarden have both shipped this and documented how they do it.
• As a provider. It returns PRF results to your website for passkeys stored in its vault. This is the role that decides whether your encryption feature works.

Vendor announcements usually describe the first role. Your users need the second one. The two are genuinely independent: Dashlane and Bitwarden both use PRF for their own vaults and both returned nothing to our test site on macOS. Reading a vendor's PRF announcement as a statement about your integration is the most common mistake here.

Status: August 2026. ✅ works in every combination we measured. 🟡 partial, meaning it works on some platforms or browsers but not others, or succeeds only in a share of attempts or is claimed by the vendor without our own confirmation. ❌ returns no PRF output in the combinations we measured. There is no symbol for "we do not know": every row here is a run we did or a number we can point at.

Providers that ship with the operating system, listed as the baseline the rest is measured against:

Third-party credential managers, sorted by how far you get with them:

The percentages come from the anonymous community results of our PRF demo, snapshot August 2026, where every data point is one authenticator, OS and browser combination. They are per-attempt success rates, so an aborted ceremony counts as a failure and the numbers sit below what a clean lab test would produce. The sample behind a single number is small. Read the values as a direction, not as a benchmark, and note that a value in the middle means "sometimes", which in production is the same as "not reliable".

Apple Passwords on macOS 26.3 with Safari 26.3, the baseline every other row is measured against. The PRF value returned on authentication is identical to the one from registration, which is the property the whole encryption use case rests on. Ignore the "macOS 10.15.7" in the box, Safari has reported that frozen version string for years.

1Password on macOS 26.3 with Chrome 150. All three checks pass, and the Authenticator box names 1Password as the provider, which is what separates this from a result produced by iCloud Keychain.

Bitwarden on the same machine, same day. The passkey is created and the authentication succeeds, but no PRF value comes back. This is the failure mode your code has to survive, and it is invisible until you ask for the PRF output.

Dashlane, same machine, same result. This is the row that makes the relying-party distinction concrete: Dashlane derives its own vault key from a passkey via PRF and markets that, and still hands your site nothing.

NordPass on macOS 26.3 with Chrome 151, all three checks negative. It differs from Bitwarden and Dashlane in one respect: the registration comes back with prf.enabled: false instead of no PRF result at all, so a relying party can tell the difference between "no" and "no answer".

1Password behaves the same way in our measurement: a PRF value at creation and the identical value on the next authentication. That round trip is the property an encryption feature rests on, and it is what separates these two from the managers that only accept the extension.

One warning about reading a capability flag as a promise. In the same session, Chrome reported extension:prf as supported with Bitwarden, Dashlane and Proton Pass active, and the registration then returned no PRF extension result at all for Bitwarden and Dashlane. The flag describes what the client will forward, not what comes back. The L3 support matrix has the full comparison across twelve providers.

Two things follow from the tables. First, create and get are separate capabilities and a manager can ship exactly one of them. Samsung Pass is the sharpest case: nothing at registration, a value on the next authentication. KeePassXC leans the same way less clearly, and the Microsoft Password Manager has the split the other way round. Second, the same manager behaves differently per platform. Bitwarden goes from 100% on Linux with Firefox to 0% on iOS with Safari, so one verdict per vendor would be a lie. Keeper used to be the standard example for the first point and no longer is: our own run in August 2026 returned a value on both sides, which is why the row moved.

Every cell in both tables is now a measurement, Samsung Pass included, which took a Galaxy phone to close. If you maintain one of these products and a row is wrong, tell us and we will retest it. The broader picture across all Level 3 features, not only PRF, is in our WebAuthn L3 support matrix.

5.4 Why the Fallback to the Built-in Provider is a Business Problem#

If PRF is unavailable, the usual answer is to fall back: ask the user to create the passkey with the operating system's built-in provider instead, meaning Apple Passwords, Google Password Manager or Windows Hello, or drop the encryption feature for that session. "Platform authenticator" is not the right word for this, because a third-party manager like 1Password registers as a platform authenticator as well and still may not return PRF. What you are actually falling back to is the provider that ships with the OS.

Technically that is sound. Commercially it is not free.

Users who installed a credential manager did so to control where their credentials live. A flow that says "your password manager cannot do this, use Apple or Google instead" asks them to give up exactly that control. Credential manager vendors report this as an explicit user concern in Japan, and in Germany it shows up in enterprise procurement, where the storage location of credentials is a standard question rather than a detail.

Two consequences for your implementation:

• Write the fallback as a choice, not as a downgrade. "This feature needs a provider that supports PRF" is a different sentence from "your password manager is not supported".
• Do not build a core feature on a capability that a third of your users may not have. Check the provider distribution in your own traffic before you make PRF a hard dependency.

6. WebAuthn & Passkey PRF Test Demo#

Our WebAuthn PRF demo runs the ceremony against your own setup. You can:

• Register a passkey with PRF and see whether your authenticator supports it.
• Authenticate and read out the actual PRF value.
• Compare against the community results, which is where the numbers in section 5.3 come from.

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 for the PRF extension and observe how PRF-derived keys can power WebAuthn 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. Results are shared anonymously, so every run also improves the compatibility data in this article.

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

7. WebAuthn PRF vs. credBlob, largeBlob and Password-Derived Keys#

PRF is not the only WebAuthn extension that deals with secret data. The differences:

• 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: PRF derives secret keys on demand during authentication from a hardware-bound secret instead of storing a static blob, which is why it, and not the blob extensions, is the standard mechanism for encryption keys tied to a passkey.

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

  • Stronger source: the key material comes from the authenticator, not from a password that may be weak or reused.

  • Phishing resistance: the derivation is tied to the phishing-resistant WebAuthn flow.

  • Passwordless: a vault can be decrypted without asking for 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.

8. Developer Recommendations for Integrating the WebAuthn PRF Extension#

8.1 General Recommendations for PRF Extension Support#

• Treat PRF as an enhancement, not a dependency:
  Support still varies across browsers, operating systems, credential managers and authenticators, so no mission-critical function should require it. Safari on macOS and iOS is the weakest combination today.

• Plan for the lost passkey:
  A PRF-derived key exists only as long as the passkey does. If the passkey is gone, the encrypted data is gone with it, permanently. Build the backup and recovery path before you ship the feature, not after.

• Monitor Windows Ecosystem:
  Windows Hello on Windows 11 25H2 has started returning PRF values via WEBAUTHN_API_VERSION_8. Firefox 148+ fully supports the capability and Chrome 147 has committed PRF-on-create support, enabled by default. Windows is the platform where the picture still changes from release to release.

8.2 Integrating PRF into Your Passkey Strategy#

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.

9. How Corbado can help#

As Sections 4 and 5 show, PRF support is fragmented across operating systems, browsers and authenticators. Before you gate any encryption feature on PRF, you need to know how many of your users can actually use it, and reading it off the support matrix is not enough. Corbado Observe measures exactly that on top of your existing passkey flow.

• Measure PRF readiness across your user base: Observe's Client Capabilities reads the browser's getClientCapabilities() and reports, per device and segmented by OS over time, whether the PRF extension (extension:prf) is available, alongside related capabilities like conditionalCreate and platform-authenticator support.
• Decide rollout from real data, not assumptions: see whether PRF availability in your actual traffic is high enough to ship a PRF-dependent feature, and for which segments, before you build the fallback path for everyone else.

Scope note: Corbado's role here is measurement. It tells you where PRF is safe to turn on, while the PRF key derivation and client-side encryption itself stays in your application.

10. Conclusion: WebAuthn End-to-End Encryption with PRF#

PRF is what makes a passwordless application capable of end-to-end encryption without falling back to a password for key material. Answering the three questions from the start:

• PRF use cases: end-to-end encrypted storage, vault decryption without a master password, key rotation via the two salts and identity wallets or non-custodial systems where the private key never leaves the client and user privacy does not depend on the operator.

• Current state of PRF support (August 2026): Android works across browsers and authenticators. macOS and iOS work via iCloud Keychain, with the caveat that iOS 18.0 to 18.3 had cross-device bugs that could destroy data (fixed in 18.4+). Windows was the long-standing gap and is now closed: Windows Hello on Windows 11 25H2 returns PRF values via WEBAUTHN_API_VERSION_8, Firefox 148+ supports it fully and Chrome 147 adding PRF-on-create support.

• Credential managers: this is the axis that is still fragmented. Platform providers are reliable, third-party managers are not, and several ship on-create without on-get, which fails only after the user has already committed. Measure the provider mix in your own traffic before you make PRF a hard dependency.

The practical consequence is unchanged: treat PRF as an enhancement, build the fallback path and never let a lost passkey take the only copy of a key with it.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

Frequently Asked Questions#

Can I add PRF support to passkeys that were already created without requesting the PRF extension at registration?#

PRF operates during the authentication phase (navigator.credentials.get()), so previously created passkeys can support PRF-based workflows without issuing new credentials. This retrofitting works with iCloud Keychain, Google Password Manager and newer security keys. However, older security keys may only generate an hmac-secret if it was explicitly requested during credential creation.

What is the difference between WebAuthn PRF and largeBlob for deriving encryption keys?#

PRF is specifically designed to derive secret keys on demand during authentication using a hardware-bound HMAC secret, making it the purpose-built standard for key derivation. largeBlob enables storing roughly 1KB of auxiliary data with discoverable credentials but is not designed for secret key derivation. Chrome developers explicitly favored PRF over largeBlob for encryption use cases.

What happens to data encrypted with PRF-derived keys if a user loses their passkey?#

PRF-derived keys are bound exclusively to the specific passkey used during authentication. If that passkey is lost, the encrypted data becomes permanently inaccessible because the same PRF output cannot be reproduced without the original credential. Build the backup and recovery path before you put PRF-based encryption in front of users.

How does PRF support vary across different authenticator types?#

Authenticators fall into four categories: no PRF support at all (older platform authenticators and legacy security keys); PRF only if the flag was set at credential creation (some CTAP 2.0/2.1 security keys); PRF available unconditionally even for credentials created without the flag (iCloud Keychain and Google Password Manager); and full CTAP 2.2 compliance where the first PRF output is returned already during credential creation. Knowing which category an authenticator belongs to is essential for designing backup and key-establishment logic.