Delete One Passkey, Lose Every Note You Encrypted With It

A passkey's encryption secret lives exactly as long as the credential does. Delete the passkey and the secret is gone with it — not corrupted, not recoverable, gone. Losing a device usually does not do this. Deleting the credential does, and deletion is the one action every passkey manager treats as routine.

The mechanism is real and standardized. The W3C's Web Authentication specification, Level 3, defines a prf extension — a pseudo-random function bound to a single credential — and proposes this exact use in its own text: "As a motivating example, PRF outputs could be used as symmetric keys to encrypt user data. Such encrypted data would be inaccessible without the ability to get assertions from the associated credential."¹

That is the feature working as designed. Encrypted notes, unlocked by the same gesture that signs you in.

The tension is internal to the standard. On 27 February 2026, Tim Cappalli — listed first among the editors of that same Level 3 specification — published a post titled "Please, please, please stop using passkeys for encrypting user data," which argues: "To the wider identity industry: please stop promoting and using passkeys to encrypt user data. I'm begging you. Let them be great, phishing-resistant authentication credentials."²

A second listed editor files the extension in his own library's documentation under a breadcrumb that reads Advanced Guides › Danger Zone › PRF.³

This post is about key durability — whether the thing that opens your notes will still exist in five years. It is the companion question to whether you can move a passkey at all, and the sibling of a diary you can still open in 2046, which asks whether the format survives. Format durability and key durability are two separate failure modes. Encryption that survives both is the only encryption worth keeping a decade of notes in.

What the PRF extension actually gives a website

The prf extension lets a website ask your authenticator to evaluate a pseudo-random function tied to one credential. You send bytes in, you get 32 bytes back, and the same input always returns the same output. Those 32 bytes are key material — strong, hardware-bound, and impossible to read out of the authenticator.

The specification is precise about the primitive. "Let PRF be a pseudo-random function whose outputs are exactly 32 bytes long, selected uniformly at random from a set of at least 2^256 such functions," it says, and the extension "map[s] from BufferSources of any length to 32-byte BufferSources."^{4 5} Inputs are not passed through raw. They are domain-separated first, so that a PRF output can never be confused with a signature over something else:

salt1 = SHA-256( UTF8Encode("WebAuthn PRF") || 0x00 || eval.first )
salt2 = SHA-256( UTF8Encode("WebAuthn PRF") || 0x00 || eval.second )   // optional
→ authenticator: output1 = PRF(salt1), output2 = PRF(salt2)            // 32 bytes each

That derivation is the specification's own, quoted from §10.1.4.⁶ Filippo Valsorda, who shipped a working implementation of it, gives the shortest accurate description of what you are holding: "You can think of a PRF as a keyed hash (and indeed for security keys it's backed by the hmac-secret FIDO2 extension): a given input always maps to the same output, without the secret there's no way to compute the mapping, and there's no way to extract the secret."⁷

Three properties follow. The output is deterministic — the same input reproduces the same key every time. The secret never leaves the authenticator, so the key cannot be stolen from a database. And the secret cannot be exported, backed up, or escrowed by anyone — including you.

On FIDO2 hardware, the specification says the extension "is modeled on top of the [FIDO-CTAP] hmac-secret extension, but can also be implemented by other means."⁸ The CTAP 2.1 text describes what the authenticator does with it: the extension "is used by the platform to retrieve a symmetric secret from the authenticator when it needs to encrypt or decrypt data using that symmetric secret. This symmetric secret is scoped to a credential."⁹

The enrolment happens once, at registration — "the authenticator generates two random 32-byte values (called CredRandomWithUV and CredRandomWithoutUV) and associates them with the credential."¹⁰

// authenticatorGetInfo response (CBOR)
{ 1: ["FIDO_2_0"], 2: ["hmac-secret"], ... }

// authenticatorMakeCredential request (CBOR)
{ 1: h'687134968222EC17202E42505F8ED2B16AE22F16BB05B88C25DB9E602645F141',
  ...
  6: {"hmac-secret": true} }
// → authenticator generates CredRandomWithUV / CredRandomWithoutUV, associates them
//   with the credential, and never releases them.

Read that last line twice. The secret is associated with the credential — no independent existence, no separate handle, no lifetime of its own.

The clause that decides how long your data lives

One sentence in the Level 3 specification governs the durability of everything encrypted this way. In the authenticator's processing steps for the extension, the normative instruction is: "Associate PRF with the current credential for the lifetime of the credential."¹¹ The key's lifetime is the credential's lifetime. There is no second clause.

Search the rest of the specification for a recovery path and there is nothing to find. WebAuthn Level 3 defines no escrow, no export, no derivation-from-backup, and no way to migrate a PRF secret to a new credential. Neither does CTAP 2.1. The absence is deliberate — non-extractability is the security property, and a secret you could copy out would not be hardware-bound at all.

One honest caveat about the status of the text. Level 3 is a Candidate Recommendation Snapshot dated 26 May 2026, not a finished W3C Recommendation.¹² The ratified standard is Level 2, published 8 April 2021, and a search of that document returns zero occurrences of hmac-secret and zero of "pseudo-random function extension."¹³ The extension people are being invited to encrypt their backups with is new, still on the Recommendation track, and absent from the version that is actually ratified.

Here is the whole chain, and its two exits.

flowchart TD
  A[Passkey created] --> B[Secret stored with<br/>the credential]
  B --> C[Assertion returns<br/>32 PRF bytes]
  C --> D[Wrapping key derived]
  D --> E[Notes encrypted]
  B --> F{Credential deleted<br/>or reset?}
  F -->|No| C
  F -->|Yes| G[Secret destroyed]
  G --> H[Notes unreadable]

Figure: The lifetime of a PRF-derived key. A passkey is created and the authenticator stores a secret alongside it; each assertion returns 32 deterministic bytes, which the application turns into a wrapping key that encrypts your notes. As long as the credential exists, the same bytes come back every time. The moment the credential is deleted or the authenticator is reset, the secret is destroyed with it and the encrypted notes cannot be opened again.

What survives deletion, a reset, and a lost phone

Deletion is fatal. A factory reset of a security key is fatal. Losing every device you own is usually not fatal, because a synced passkey is designed to outlive your hardware. The popular framing of this hazard — lose the phone, lose the data — is the wrong one, and getting it wrong makes the real risk sound rarer than it is.

Apple states the recovery property directly: passkeys "sync across a user's devices using iCloud Keychain. iCloud Keychain is end-to-end encrypted with strong cryptographic keys not known to Apple and rate limited to help prevent brute-force attacks even from a privileged position on the cloud backend, and are recoverable even if the user loses all their devices."¹⁴

Valsorda describes the same property from the user's side — "Since passkeys are usually synced, it means you can e.g. encrypt a file on macOS and then pick up your iPhone and decrypt it there, which is pretty cool."¹⁵

Whether a credential syncs is fixed at birth. In WebAuthn's terminology, "backup eligibility is a credential property and is permanent for a given public key credential source," and "a backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential."¹⁶ You cannot promote a device-bound credential into a synced one later. Whatever it was created as, it stays.

The CTAP 2.1 reset method is worth reading in full, because it is the one hardware owners trigger casually. authenticatorReset "is used by the client to reset an authenticator back to a factory default state. Specifically this action at least: Invalidates all generated credentials, including those created over CTAP1/U2F. Erases all discoverable credentials."¹⁷ A security key that has been reset is cryptographically indistinguishable from a new one. Every file it was holding a key for is now noise.

Two of those four rows are things a person does on purpose, in under ten seconds.

So the failure mode is not an accident that befalls unlucky people who drop their phones in rivers — it is a two-tap action, offered in a settings screen, next to a trash icon.

What the credential managers actually document

Across the published documentation of four major passkey providers, the words "PRF" and "pseudo-random" do not appear once, and the only deletion warning any of them publishes is about losing the ability to sign in. That is a documentation-level finding, measured on their own help pages, not a claim about what any particular deletion screen displays today.

Microsoft is the one that warns. Its passkey-management page carries a Caution: "If you remove the passkey, you will no longer be able to use it to sign in to your Microsoft account. If you do need to remove a passkey, make sure you add new information first."¹⁸

The warning is real — and exclusively about authentication. A census of that page returns zero occurrences of prf, zero of encrypt, and zero of backup.

The one vendor that warns you, warns you about the wrong loss.

Google's documented removal flow is four steps and ends "Select the passkey you want to remove. Tap Remove," with the stated reasons for removing one being "If you lose a device with your passkey, or created a passkey on a shared device by mistake."¹⁹ Bitwarden's help page documents a delete-and-confirm sequence — "Select Delete to confirm" — with no data caveat attached.²⁰

Neither page mentions prf or pseudo-random. Apple's passkey-security page goes further in the other direction — it contains zero occurrences of "delete" or "remove," and does not document deletion at all.²¹

Cappalli's own complaint is about the enabling flow rather than the deletion flow, and it is worth quoting precisely: "There is nothing in the UI that emphasizes that these backups are now tightly coupled to their passkey."²² His scenario for what follows is four words long. A person replaces a phone, recovers the account, and finds the old credential gone: "Since they no longer have it, they are informed that they cannot access their backed up data. Goodbye, memories."²³

The gap is structural, not negligent. Deletion UIs were designed for a credential whose only job was authentication, where removing one costs you a login method you can re-enroll in thirty seconds. The interface never had to describe a second consequence, because until recently there was not one.

How a shipped implementation does it

The construction is not hypothetical. Valsorda's age integration derives a file-wrapping key from two PRF outputs and encrypts the file key with it, and the platform support arrived across the ecosystem in one wave: "Support for the PRF extension landed in Chrome 132, macOS 15, iOS 18, and 1Password versions from July 2024."²⁴

The derivation chain, in his words: "The two 32-byte PRF outputs are concatenated and passed to HKDF-Extract-SHA-256 with age-encryption.org/fido2prf as salt to derive the ChaCha20Poly1305 wrapping key."²⁵

PRF input 1 = "age-encryption.org/fido2prf" || 0x01 || nonce
PRF input 2 = "age-encryption.org/fido2prf" || 0x02 || nonce
wrapping_key = HKDF-Extract-SHA-256( salt = "age-encryption.org/fido2prf",
                                     ikm  = output1 || output2 )
file_key_ct  = ChaCha20Poly1305( wrapping_key, nonce = 0, file_key )

Nothing in that chain is weak. Two independent 32-byte PRF outputs, a standard extract step, an authenticated cipher, a domain-separated salt. If you were reviewing this as a cryptographic design you would sign it off, and that is precisely the point worth being clear about.

The cryptography is not the flaw. The lifecycle is.

This is also where the honest advantage lives. A key that cannot be extracted cannot be exfiltrated by malware, copied from a stolen backup, or handed over by a service that never had it. The same property that makes the secret durable against attackers makes it fragile against you.

Why two of the specification's own editors are warning about this

The strongest evidence against using passkeys this way comes from inside the document that describes how. Two of the six people listed as editors of WebAuthn Level 3 have published warnings about the extension: Cappalli in a blog post, and Matthew Miller in the documentation of the library most developers reach for.²⁶

Cappalli's argument is a scope argument, and it fits in one sentence: "When you overload a credential used for authentication by also using it for encryption, the 'blast radius' for losing that credential becomes immeasurably larger."²⁷ A lost login is an inconvenience with a recovery flow behind it. A lost decryption key is an archive you cannot read.

Merging the two means every routine credential-hygiene action now carries the second consequence.

Miller — SimpleWebAuthn's author, listed in the specification as an editor at Cisco — files the extension under "Danger Zone" and opens the page with "Proceed with extreme caution." What follows is the clearest statement of the failure mode anywhere in the primary sources: "Use of WebAuthn's prf extension dangerously ties vital encryption information to a user's passkey. If a user inadvertently deletes their passkey, they will lose all access to their information that your website chose to encrypt with that passkey's PRF seed. There is nothing that can be done with SimpleWebAuthn to fix this problem if it occurs to you."²⁸

He then declines to make it easier — "There are no plans to make PRF simpler to use using SimpleWebAuthn because of the footgun described above. Passkeys are an authentication technology first and foremost, and SimpleWebAuthn prioritizes simplifying these use cases over any other use of WebAuthn."²⁹

Editorship of a specification is not authorship of any particular clause, and neither post is a W3C position. What it does establish is that the concern is not an outsider's misreading of the standard. When Cappalli's post reached Hacker News on 28 February 2026 it drew 280 points and 244 comments, which is the size of the audience currently deciding whether to turn this on.³⁰

Where PRF is legitimately durable

The critic supplies the exception himself. Cappalli names uses he considers sound: "There are some very legitimate and more durable uses of PRF in WebAuthn, specifically supporting credential managers and operating systems."³¹ The distinction is not about the cryptography — it is about whether anything else in the system can open the same data.

His reasoning is the rule this whole post reduces to. Credential managers hold several unlock paths at once — master passwords, per-device keys, recovery keys, and social recovery keys — so, in his words, "losing access to a passkey used to unlock your credential manager rarely leads to complete loss of your vault data."³²

The passkey is one door into the vault. Remove it and the other doors remain.

Bitwarden is exactly that sanctioned case, described in its own words. Vivian Shic writes that "the WebAuthn PRF extension is an emerging standard that sources symmetric keys from an authenticator," and that "when a Bitwarden user registers a passkey from a hardware security key such as a YubiKey, Bitwarden can use that encryption key (associated with the passkey) to encrypt and decrypt the user's vault data."³³

The vault still has a master password. The PRF key is a convenience layer over an account that already has other ways in — which is the whole difference.

Valsorda is likewise not an opponent of the technology: "I am a strong believer in passkeys, especially when paired with email magic links, as a strict improvement over passwords for average users and websites."³⁴ The people who understand this best are not telling you passkeys are bad. They are telling you that one specific composition — sole key, no second path — turns a good authentication credential into a single point of failure for your data.

The mitigation: make sure something else can open the file

The fix is not a better warning — it is a second recipient. File formats that wrap one file key for several independent holders make any single deletion survivable, because the same file opens with a key that was never touched. That is a property of the format, not a vendor promise.

The age v1 specification states the structure plainly: "The textual file header wraps the file key for one or more recipients, so that it can be unwrapped by one of the corresponding identities," and "each recipient stanza wraps the same file key independently."³⁵

Two stanzas mean two keys, each sufficient on its own.

age-encryption.org/v1
-> age-encryption.org/fido2prf Fv8VHh8kzhSlR14OviQ2OA
0Gw/JQEYrx5wPEUQzAh14nB6vTujga6VaboJ/vMKgWw
-> X25519 XEl0dJ6y3C7KZkgmgWUicg63EyXJiwBJW8PdYJ/cYBE
qRS0AMjdjPvZ/WT08U2KL4G+PIooA3hy38SvLpvaC1E
--- HK2NmOBN9Dpq0Gw6xMCuhFcQlQLvZ/wQUi/2scLG75s

That header is an illustration of the format — assembled from two separate examples in the sources, not captured from one real file.³⁵ The shape is what matters: the first stanza is unwrapped by a passkey, the second by an ordinary offline key. Delete the passkey and the file still opens.

There is also a disclosure mechanism, and it is worth knowing the name. The W3C's companion Working Draft for Relying Party passkey endpoints defines an optional prfUsageDetails member: "This OPTIONAL member contains a URL to an informational page describing how the RP uses the WebAuthn Pseudo-Random Function Extension (PRF)."³⁶

It is optional, it sits in a Working Draft, and how widely it is published in practice is not something this post can verify. A field that exists is not yet a norm.

Who should use a passkey as an encryption key, and who should not

Use it when the passkey is one of several paths to your data and a second key is already enrolled. Avoid it when the passkey is the only thing standing between you and an unreadable archive. That single test — how many independent keys open this file — decides the question better than any judgment about the cipher.

Reasonable, if you accept the terms:

• A vault or account that also has a master password or recovery key, which is the case Cappalli calls durable.³¹
• Per-file encryption where a second recipient is enrolled at the same time and stored somewhere else.
• Short-horizon data where losing it is an annoyance rather than a loss.

Not reasonable:

• A decade of notes with one credential and no second recipient.
• Anything encrypted on a device-bound credential you cannot back up and would replace routinely.
• Any workflow where the same passkey is subject to normal credential hygiene — rotation, cleanup, a device migration that drops the old entry.

The honest version of this trade is that you are choosing between two failure modes, not avoiding one.

A key you can export can be stolen. A key you cannot export can be destroyed. Systems that survive both keep more than one key.

Frequently Asked Questions

These are the questions people actually type when a product offers to encrypt their data with a passkey. Each answer is scoped to what the specifications and the vendors' own documentation state, and it names the source, because the difference between "encrypted" and "recoverable" is exactly where the confusion lives.

Can I encrypt my files with a passkey?

Yes. The WebAuthn Level 3 prf extension exposes a per-credential pseudo-random function, and the specification names encryption as its motivating example.¹ Valsorda's age integration is a shipped implementation of it, with platform support in Chrome 132, macOS 15, iOS 18 and 1Password.²⁴ The mechanism works. The lifecycle is the part to understand first.

What happens if I delete a passkey I used to encrypt data?

The data becomes unreadable, permanently. The specification associates the PRF secret with the credential "for the lifetime of the credential," and defines no escrow or export.¹¹ SimpleWebAuthn's author states the consequence directly: delete the passkey and you "lose all access to" whatever was encrypted with its PRF seed.²⁸

If I lose my phone, do I lose the encrypted data?

Usually not, and this is the most misunderstood part. A synced passkey is "recoverable even if the user loses all their devices," per Apple's own documentation, and cross-device decryption is the normal case.^{14 15} Deletion destroys the secret; losing hardware generally does not. A device-bound credential is the exception.

Is the PRF output synced across my devices, or stuck on one?

It follows the credential's backup eligibility, which WebAuthn defines as "permanent for a given public key credential source" and fixed at creation.¹⁶ A multi-device credential carries its PRF secret wherever it syncs. A hardware security key does not sync, and CTAP notes the extension "can be used to maintain different secrets on different machines."³⁷

Can I back up or export the PRF key?

No. Non-extractability is the design: as Valsorda puts it, "there's no way to extract the secret."⁷ No escrow or export mechanism appears in WebAuthn Level 3 or CTAP 2.1. The mitigation is not backing up the key — it is enrolling a second, independent key that can open the same data.³⁵

Does my password manager warn me before I delete a passkey that holds data?

The published documentation does not. Microsoft's caution covers sign-in only, Google's and Bitwarden's removal steps carry no data caveat, and Apple's security page does not document deletion.^{18 19 20 21} Across all four, "PRF" and "pseudo-random" never appear. What any live screen shows today is a separate question.

Is it safe to use a passkey as an encryption key?

The cryptography is sound — 32-byte outputs, domain-separated inputs, a secret that never leaves the authenticator.^{4 6 7} The risk is lifecycle. It is safe where a second recovery path exists, as with a vault that also has a master password, and unsafe where the passkey is the only key.³²

A passkey was designed for a loss you can recover from. Encryption is a loss you cannot. Before you let a credential hold a decade of notes, the question is not whether the data is encrypted — it is what else can open it, and whether that something else already exists.

Notes you keep for years want the same discipline: MNMNOTE is a local-first markdown editor that keeps your notes on your own device in open Markdown files, so what opens them is a text editor.