How HeirVault delivers what it cannot read

A vault that opens for your family after you are gone sounds like it must have a spare key under the mat. If HeirVault can hand your documents to your sister one day, surely HeirVault can read them today.

That objection is fair, and the answer is the most important design decision in the product. Here is how delivery works, mode by mode, including the one path that is not end-to-end and tells you so.

Your live vault is protected by end-to-end encryption. Everything you store (documents, logins, bank details, files) encrypts in your browser before upload. That means what reaches our servers is ciphertext, and HeirVault cannot decrypt your live vault. If someone breached our storage, they would get ciphertext, not your plaintext.

The client-side library that does this is public: TrueWear/heirvault-crypto on GitHub, @heirvault/crypto on npm, Apache-2.0. The full product is not open source, and the library has not yet had a third-party audit. But the exact code that encrypts your vault in the browser is there to read.

So far, this is what any serious zero-knowledge tool promises. The interesting part is what happens next.

The naive design would wrap your vault key for each beneficiary. We never do that. The live vault key is never wrapped for anyone but you.

Instead, when you assign items to a beneficiary, your browser builds a separate handoff for that person. It happens while your vault is unlocked, on your own device. It creates a beneficiary-specific handoff key and re-encrypts only their assigned items and attachments under it. Your sister's handoff contains the house folder. Your co-founder's handoff contains the domain logins. Nobody is handed everything, and no handoff can open the live vault.

The question "can HeirVault read this?" then becomes precise: it depends on who holds each handoff key. That is exactly what the delivery mode decides.

HeirVault-assisted handoff is the free default. It exists for the beneficiary who will not install anything, create an account in advance, or manage a password. Realistically, that describes many of the people we leave things to. To make that work, HeirVault stores a protected handoff key and transfers it to the beneficiary's account after a verified claim. Until release, that key sits in escrow with layered protections. But we hold it. An assisted handoff is not end-to-end to the beneficiary alone, and escrowed key custody is an additional access path that exists so delivery can work without setup on their side. The app tells you this at the exact moment you choose the mode, not in a footnote.

Invite now (Pro and Shield) removes us from the loop while everyone is alive. Your beneficiary enrolls with their own account, and their account holds the key material for their handoff. Delivery is end-to-end: we transfer ciphertext they can already open. The trade is silence: they know today that they are named. If their enrollment is left incomplete, the handoff needs repair by you; the dashboard surfaces that instead of quietly falling back.

Shared beneficiary password (Pro and Shield) is end-to-end without early enrollment. Your browser derives the handoff key from a unique password generated for that one beneficiary, and you share it out of band: a sealed envelope, a safe, a lawyer. It is never your vault password, and we never see it. The trade is stewardship: if the password is lost, that handoff is unopenable, by design.

Who can open a handoff is the cryptography above. When they may open it is the check-in system, and the two are deliberately independent.

You check in on the rhythm you choose. Nothing opens while you keep checking in. Miss enough check-ins and a waiting period starts, with reminders the whole way down; a single check-in during that window cancels everything. On Pro and Shield you can add witnesses: people who must approve release by majority after the waiting period ends. Witnesses never receive content or handoff keys, and they cannot reset your timer. They are a brake, not a key.

We describe this as detecting missed check-ins, because that is what it is. HeirVault does not detect death; it detects absence, on a schedule you set, with every false-positive protection pointed in the direction of not releasing.

We could have shipped only the end-to-end modes and written a prouder security page. We kept assisted delivery as the default because the alternative is worse in practice: plans that depend on every heir doing setup work in advance mostly do not survive contact with real families. A handoff that reaches your people through a path we are honest about beats a perfect one they can never open.

If your threat model says no service should ever hold a handoff key for you, we agree that is a coherent position. Pick Invite now or a shared password, and every handoff you make is end-to-end. The mode is per-beneficiary, so your co-founder can get the end-to-end path while your mother gets the assisted one.

That is the whole design: one vault we cannot read, separate handoffs per person, and a delivery boundary we would rather state plainly than have you discover.

If you want to see it from the inside, the free plan includes the vault, three beneficiaries, and the full check-in mechanism. If you would rather start without an account, the digital estate checklist runs in your browser and is useful on its own.