Do not use Passkeys' PRF extension to derive encryption keys for data

Tim Cappalli, a co-editor of the W3C WebAuthn Level 3 specification and Okta’s Standards Architect, formerly on Microsoft’s Identity Standards Team, published a warning article saying that using Passkeys’ PRF extension to derive encryption keys is dangerous. It has drawn more than 100 points on Hacker News. Cappalli is also a maintainer of passkeys.dev, so this is a warning from the person who helps write the WebAuthn spec itself.

How the PRF extension works

WebAuthn’s PRF (Pseudo-Random Function) extension lets you extract a deterministic 32-byte pseudorandom value from an authenticator. With the same authenticator, the same RP ID, and the same salt, you always get the same output.

There are two protocol layers:

Layer	Name	Context
WebAuthn API (browser)	`prf` extension	Web apps only
CTAP2 (authenticator protocol)	`hmac-secret` extension	Native apps + Web

WebAuthn PRF does not use the developer-provided salt directly. The browser hashes it internally with SHA-256, which keeps the Web-derived secret cryptographically separate from secrets used for non-Web purposes such as disk encryption.

That deterministic output looked attractive as a data-encryption key. If you could handle authentication and data protection with one passkey, that would seem convenient.

What is the problem?

The PRF output is bound to the credential ID and the RP ID. With the same authenticator and the same domain, you get the same key. But if the authenticator changes, the key changes too.

Cappalli uses a fictional user named Erika to show the failure mode:

Erika encrypts backup data using a passkey PRF on one service
Later, while cleaning up the credential manager, she deletes that passkey. The UI does not show that it was used for encryption
She registers a new passkey on a new device, but the key derived from the old authenticator cannot be reproduced
A backup containing photos and messages from deceased relatives becomes permanently unrecoverable

Cappalli’s central point is this:

When you overload a credential used for authentication by also using it for encryption, the “blast radius” for losing that credential becomes immeasurably larger.

Authentication credentials are replaceable. You can recover them by resetting a password or registering a new passkey. Encryption keys are not replaceable; once they are lost, the data is gone forever. If you use a passkey for encryption, something that was replaceable becomes non-replaceable. Users think of passkeys as login tools, but in practice they are also acting as encryption keys. That mismatch in mental model is what causes accidents.

Synced Passkeys vs Device-Bound Passkeys

With synced passkeys, such as those synced through iCloud Keychain or Google Password Manager, the secret material is synchronized across devices. That means the PRF output is the same across those devices if you use the same salt.

With device-bound passkeys such as hardware security keys like YubiKey, the PRF output is locked to that device. Losing the device means losing access to the encrypted data forever.

The annoying part is that PRF support is still inconsistent across platforms:

Platform	Status	Notes
Android	Stable	PRF support across Google Password Manager passkeys
macOS 15+	Good	Safari 18+, Chrome 132+, Firefox 139+
iOS/iPadOS 18+	Buggy	Data-loss bug in iOS 18.0-18.3, fixed in 18.4+
Windows 11	Limited	Windows Hello does not support `hmac-secret`; only external security keys do
Firefox	Partial	Android not supported; macOS/Windows supported in v139+

As of February 2026, support is still incomplete, which is why PRF should be treated as an enhancement feature rather than a core dependency.

Implementations that already use PRF for encryption

Several services already use PRF for encryption.

Password manager category

Bitwarden: derives the vault encryption key from PRF and can unlock the vault without a master password. It expands the 32-byte PRF output to 64 bytes with HKDF and builds a three-layer encryption architecture with an RSA key pair. It already supports multiple passkeys. When PRF is unavailable, it falls back to the master password
Dashlane + Yubico: uses WebAuthn PRF with YubiKey to handle both authentication and vault unlock, becoming the first major credential manager to use a FIDO2 security key for vault access
1Password: supports PRF with stored passkeys and has open-sourced a library that lets third-party apps use passkeys for E2EE

Consumer services

WhatsApp: added passkeys as an alternative to the password or 64-digit encryption key for encrypted chat backups, deriving encryption key material from the passkey through the PRF extension
Confer (from Signal founder Moxie Marlinspike): an E2EE AI chat service. It derives a 32-byte secret from the passkey PRF extension and uses it as root key material. It derives subkeys for client-side encryption/decryption, then sends ciphertext to a TEE for inference

Cappalli considers the password-manager cases legitimate. They have separate recovery mechanisms such as master passwords and recovery codes. The concern is designs like WhatsApp and Confer, which rely on passkey PRF as the only path to encryption.

Recommended pattern: Envelope Encryption

If you do use PRF for encryption, the recommended pattern is Envelope Encryption:

[Data Encryption Key (DEK)] -- encrypts the actual data
        |
[Key Encryption Key (KEK)] -- wraps the DEK, with a different KEK per authenticator
        |
[PRF output -> HKDF -> KEK derivation] -- derive a KEK from each passkey or security key

The server stores an encrypted vault plus multiple DEK copies wrapped by different KEKs. Because each authenticator can independently unlock the DEK, losing one authenticator does not cut off access to the data.

The PRF extension is designed to derive two different secrets in one authentication ceremony, so you can request both the old and new PRF secrets and rotate keys atomically.

Anti-patterns you should avoid:

Using the raw PRF output directly as an encryption key. Always pass it through HKDF
Omitting the HKDF info parameter, which removes purpose binding
Designing encryption around a single authenticator, which leads directly to the Erika scenario
Using a static salt across users or credentials

What the HN discussion reveals about the ecosystem

The Hacker News thread pointed out several structural issues.

First, passkeys are designed as replaceable authentication credentials, but PRF turns them into non-replaceable encryption keys. Because users think of passkeys as login tools, they do not realize deletion can have permanent consequences. One suggestion was to expose a signal in the WebAuthn spec that says “this passkey is being used for encryption.”

Second, credential managers have no way to know how a service is using PRF. Without always-on communication with the service, they cannot warn the user at deletion time that “deleting this passkey will delete your data.”

To address that, the W3C spec “Well-Known URL for Relying Party Passkey Endpoints,” co-edited by Cappalli and Matthew Miller of Cisco, defines a prfUsageDetails field. It points to an info page that explains how PRF is used, so credential managers can warn users before deletion.

{
  "enroll": "https://example.com/passkey/enroll",
  "manage": "https://example.com/passkey/manage",
  "prfUsageDetails": "https://example.com/passkey/prf-info"
}

There is still no official FIDO Alliance guidance that says “do not use PRF for encryption.” The spec itself is designed with the expectation that PRF may be used to derive encryption keys. This article is therefore best read as Cappalli’s personal warning and industry recommendation, but it comes from the editor of the WebAuthn L3 spec itself, so it is not something to dismiss lightly.