Trusted handover: giving a beneficiary access to your encrypted notes, the right way

What happens to your encrypted notebook if you stop being able to use it? The trusted handover is Flowvault's answer: nominate a beneficiary, pick a check-in cadence, and if you go quiet for the interval plus a grace period, the vault auto-hands-over to that person — without ever telling Flowvault your password, and without an account anywhere. Here's how it works, end to end, and how it compares to Bitwarden Emergency Access and 1Password recovery.

The problem

Zero-knowledge encryption has a structural weakness: if you forget your password or die, your notes are gone. The single-tenant property that protects you from us also protects your notes from anyone you'd want to inherit them.

The naive fixes are all bad:

Share the master password with your spouse now. Fine until one of you changes it and forgets to tell the other, or until you have content you wouldn't want them reading while you're still alive.
Put it in a will. Works, but slow, legally messy, and requires your executor to understand passwords.
Give the service operator an escrow key. Breaks zero-knowledge. That's not a recovery flow, it just makes the vault no longer zero-knowledge.

What you actually want is: a beneficiary who gets the keys automatically, at the right moment, without the operator ever holding a plaintext key.

The shape of the solution

Two ideas, combined:

Client-side wrap. The beneficiary password is never sent to us. It runs Argon2id in your browser, producing a beneficiary key, which then AES-GCM-wraps your master key. The resulting wrapped key is what we store.
Server-side timer.Every time you save, the server bumps a “last seen” timestamp. An hourly Cloud Function scans for vaults whose last-seen is older than (interval + grace). Those get marked released. Once released, the wrapped key becomes readable to a client that presents the beneficiary password.

Both parts are necessary. Without the server-side timer, there's no “you went quiet” signal. Without the client-side wrap, the server would have to decrypt things for the beneficiary and we'd know the key.

Walkthrough: enabling a handover

You open your vault, click Handover in the toolbar, and configure three things:

Interval: How long you can go without saving before the grace period starts. Presets: weekly, monthly, quarterly, yearly. Custom intervals between 1 day and 5 years.
Grace period: A buffer after the interval during which Flowvault emails nobody (we don't have your email) and does nothing except wait. Typical: 7 days. This is your “I was on a hiking trip” window.
Beneficiary password: A strong password (min 12 chars) you hand to a trusted person out of band. Not your master password. Flowvault never sees it, in plaintext or otherwise.

When you click Enable trusted handover, the client:

Takes your current master key (the one that just decrypted this slot).
Runs Argon2id on (beneficiary password, a fresh 16-byte salt) to get a beneficiary key.
Encrypts the master key with that beneficiary key using AES-256-GCM and a fresh 12-byte nonce. This produces a wrapped master key.
Uploads a Firestore document containing: the wrapped master key, the Argon2id salt, the GCM nonce, the interval, the grace period, a released: false flag, and the current timestamp as last-seen.

That's the whole setup. The beneficiary password never leaves your browser. Flowvault has a ciphertext that wraps another ciphertext and a clock.

Steady state: checking in

Every time you save your vault, the same transaction that writes the new ciphertext also bumps the handover'slastSeenAttimestamp. That is the check-in. There's no separate “I'm still here” button — if you're editing, you're checking in.

If you never want to log in again but want the handover to fire sooner, just stop saving. If you want the handover to fire never, disable it from the same modal.

The release

A Cloud Function runs once an hour. It queries Firestore for handovers where lastSeenAt plus interval plus grace is in the past and released is still false. For each match, it writes released: trueand flips the vault's main document into read-only mode (no more writes accepted, including from someone who still has the master password).

The Firestore security rules enforce the read-only flip: once deadman.releasedis true, no client can write the main blob or change handover fields. This is what stops a “a malicious party presses the button early” scenario: the server can't fake a release because the scheduled Cloud Function is the only write path, and the rule engine enforces it.

The beneficiary side

Your beneficiary receives two things from you out of band: the vault URL and the beneficiary password. If the handover has fired (or when it eventually does), they:

Open the URL. The page loads, notices released: true on the handover document, and shows a beneficiary unlock prompt.
They type the beneficiary password. Argon2id runs in their browser with the same salt you originally used, derives the beneficiary key, and unwraps the master key via AES-GCM.
The master key now decrypts the slot it was created for, and the beneficiary sees the notebook — in read-only mode. Flowvault blocks further writes from the beneficiary. It's explicitly an inheritance view, not a transfer of ownership.

If you stored a backup of the beneficiary password yourself, you can also unlock post-release to grab the contents and move them elsewhere. Either way, once released, the vault at that URL is frozen — if you're back from the woodlands, you should create a new vault at a new URL rather than trying to “un-release” the old one (which is impossible by design).

Handover + hidden volumes: deniability is preserved

The handover wraps one slot's master key. It knows nothing about other slots, so:

A beneficiary with the beneficiary password sees exactly the notebook you configured the handover from.
They don't see, and can't prove the existence of, decoy notebooks behind other passwords. The handover document in Firestore is a small blob keyed to one slot; the other slots remain unreferenced random bytes.
You can have multiple handovers too — enable one for a “family” notebook with your spouse, another for a “work” notebook with your business partner. Each beneficiary sees only their notebook.

How this compares to Bitwarden Emergency Access and 1Password

Bitwarden Emergency Access

Bitwarden's Emergency Access is the closest equivalent in a mainstream password manager. It works on a similar “timer + beneficiary” pattern but with some important differences:

Both parties need Bitwarden accounts. Your beneficiary must sign up, enable two-factor, and accept an invitation.
It's a Premium feature (paid tier on both sides).
The key escrow happens through Bitwarden's shared-key mechanism rather than a direct password-derived wrap. This is well-designed but requires more trust in Bitwarden's infra.
Bitwarden is a password manager with accounts, backups, and recovery phrase support. If you're already in that ecosystem, Emergency Access is excellent.

Flowvault's handover is the account-less version. No sign-up for either party. No subscription. Open-source server code (Bitwarden's server is open-source too). The trade-off is that Flowvault is a notepad, not a password manager — if you want vault features like password generation and autofill, use Bitwarden. If you want a zero-knowledge scratchpad with inheritance, use this.

1Password Recovery

1Password Families has “family organizer” recovery: family members can reset each other's passwords if they have recovery roles. This is a different shape — it's a social recovery model, not an inactivity-triggered release. Both parties must have 1Password accounts in the same family, and recovery is initiated on demand rather than automatically.

KeePass

KeePass-family tools leave inheritance as an exercise for the user: you can give someone a copy of the kdbx file and the password now, but there's no scheduled release and no check-in. If you want scheduled release of a KeePass database, you need a dead-man mail service on top, which reintroduces an account.

Summary table

quick comparison

                        Flowvault  Bitwarden EA  1Password  KeePass
Account required         no         yes           yes        no
Cost                     free       paid tier     paid tier  free
Inactivity-triggered     yes        yes           no         no
Open-source end-to-end   yes        partial       no         yes
Plausible deniability    yes        no            no         no
Zero-knowledge release   yes        yes           yes        n/a

What it protects against — and what it doesn't

Protects against

Death or incapacity. The beneficiary gets the key on schedule.
Long-term amnesia. If you forget your own password, the beneficiary password is a back-channel (one you set up knowingly).
Flowvault operator compromise.Attackers at our end can't release your vault early: the scheduled function is the only write path, and Firestore rules enforce it.
Evil beneficiary before you're gone. The beneficiary cannot read the vault while you're still checking in. The wrapped key is unreadable to them until released: true.

Doesn't protect against

Collusion between you and the beneficiary now. If you've already shared the master password with them, the handover doesn't make it go away. It's an addition, not a replacement.
Weak beneficiary passwords. If the beneficiary password is guessable, anyone with the URL can wait for release and then brute-force. Use a long random one.
You reviving.Once the timer fires, it fires. There is no “I'm back, never mind” button, by design: that would let an attacker who temporarily got your password silently extend the timer forever. Starting a fresh vault is the recovery path.

Practical advice

Pick your interval honestly. If you open your vault weekly, a weekly interval is fine. If you use it only in emergencies, set it yearly and accept that your beneficiary waits up to a year plus grace.
Communicate the setup.A handover that your beneficiary doesn't know about is a handover that doesn't fire. Tell them: “when this URL starts working with the password I gave you, that's how you know to open it.”
Test it. Temporarily set the interval to a few minutes on a test vault, watch it release, and unlock from a different browser with the beneficiary password. Then reset to real values.
Pair it with an encrypted backup. Download a .fvault occasionally and store it somewhere your beneficiary can find it. Even if Flowvault disappeared tomorrow, the ciphertext + the password still decrypts on any self-hosted instance.