Inheritance With No Server: How a Vault Hands Itself Over
How do you let a family open a vault after you're gone, with no account to reset and no server to ask permission? A recovery key, split into shares, that no company ever holds. Here is the architecture.
How do you let a family open a vault after its owner is gone — with no account to reset, no password to recover, and no server to ask for permission? Most digital-legacy apps answer with a company login: your heirs sign in, and a server decides what they get. We think that server is the weakest part of the design, so we built the handoff without one. This is the architecture behind bequest, our digital legacy vault for iPhone, and the key-management problem it solves.
The problem: a login is a single point of failure
A company account is convenient to build and fragile to depend on. It can lapse when a card expires, be breached along with everyone else's, or simply outlive its usefulness if the company shuts down. For an everyday app that's an inconvenience. For the thing that holds what your family needs when you die, it's the one failure you can't afford — because the person who set it up is no longer around to fix it.
So the design constraint is strict: the owner's family must be able to open the vault with nothing but what the owner physically handed them, on their own device, with no network. That rules out a server entirely.
The mechanism: split the key, don't store it
The answer is an old idea from cryptography — split the secret so that no single piece reveals anything, and only a chosen number of pieces together reconstruct it.
The vault is encrypted on-device. The key that opens it is never uploaded anywhere. Instead, the recovery key is divided into shares using a threshold scheme — for example three shares where any two reconstruct the key (a "2-of-3"). The owner hands those shares to people they trust: a spouse, a lawyer, a safe-deposit box. No single holder can open the vault alone, and no single lost share locks the family out.
Why a threshold, not a single key
A single recovery key has two bad failure modes: lose it and the vault is gone forever; leak it and anyone holding it has everything. A threshold splits the difference on purpose. Set the quorum to 2-of-3 and you survive one lost or compromised share without surviving a single bad actor. The owner chooses the trust model; the math enforces it.
What each heir actually receives
Shares are only useful if a non-technical person can use them under stress. So each share becomes a printable recovery kit — a clean sheet with the words, a QR code, and plain instructions — that the owner distributes. The app never stores or transmits these. When the time comes, heirs combine the required kits on their own iPhone, load the encrypted backup, and the vault opens read-only, honoring the release rules set per entry. You can verify the whole flow in airplane mode.
Why "no server" is a feature, not a limitation
The reflex is to assume a server makes things safer. The opposite is true here: a server is something to breach, subpoena, mis-configure, or shut down. Remove it and an entire class of risk disappears with it. There is no central store of keys, no account database, no company copy of anyone's data — because there is nowhere for any of that to live.
That's the same conviction behind everything we ship: privacy is an architecture decision, not a policy you promise. The vault stays private because of how it's built, not because of a line in a terms-of-service page.
The tradeoff we accept
No server means no "reset by email" — and that's deliberate. Recovery is physical: the owner's own recovery phrase to restore on a new device, and the shares in trusted hands for the handoff. It asks a little more of the owner up front in exchange for a vault that can't be breached server-side and can't be locked away by a company that no longer exists. For a digital legacy, that's the right trade.
If you want a vault your family can actually open — with a recovery kit you control, not a login that might not be there when it counts — see how bequest handles the handoff.
