Playbook

KeePass: a file you own, not an account you negotiate

Platform claims verified July 9, 2026

What this mechanism is

KeePass (and KeePassXC, KeePassium, Strongbox, and other compatible apps) keeps your passwords in a single encrypted database file (a .kdbx) unlocked by a master password, and optionally a key file and/or a hardware key. There is no company, no cloud, and no “legacy contact” feature: inheritance is entirely up to you.

That sounds like a gap, but it makes KeePass the cleanest case in the whole product. The .kdbx file is the vault, and it’s already encrypted. So the whole plan is two things a survivor needs together: the file, and what unlocks it. Nothing to escalate, no vendor to negotiate with, no death-certificate review. It works offline, forever. (The same logic covers a self-hosted Vaultwarden export, or any file-based manager.)

Unlike Google or Apple Passwords, here it is correct to escrow the vault itself — because a .kdbx is encrypted at rest, not a plaintext dump.

Set it up now

1. Escrow what unlocks the database into AmberKey Layer 2. Add a secret of kind master password with your KeePass master password. If you use a key file or a hardware key, that’s a second factor the password alone can’t replace. Record exactly where the key file lives and how to use the hardware key (AmberKey Layer 2 stores text, not binary, so note the key file’s location rather than pasting it).
2. Make sure the .kdbx file itself is reachable by survivors. Keep a current copy somewhere the estate can find it. The same USB drive as your continuity bundle is ideal, or a location you note on the card. Don’t let the only copy live on a single laptop that gets wiped or lost.
3. On the account card (Layer 1), record: that you use KeePass (and which app), where the .kdbx file lives, and whether a key file / hardware key is required. No secrets here, just the map.
4. Re-escrow after any change. If you change the master password or rotate the key file, update the Layer 2 secret and refresh the stored .kdbx copy — an old master password against a new database is worthless.

What AmberKey stores

• Layer 1 (metadata): that you use KeePass, the app, where the .kdbx file is kept, and whether a key file or hardware key is needed.
• Layer 2 (bearer secret): the master password, plus a note pointing to the key file (and hardware-key instructions) if you use one.

What your survivors do

1. Retrieve the .kdbx file from where the card says it lives (often the USB drive kept with the estate papers).
2. Retrieve the master password (and the key file location) from the AmberKey vault (Layer 2).
3. Open the file in any KeePass-compatible app (KeePass, KeePassXC, KeePassium, Strongbox). It opens offline; nothing is uploaded and no one has to approve anything.
4. Every saved login is now available, current as of the last backup of the file.

Required documents

None. There is no vendor and no process. Just the file and what unlocks it. This is the point of choosing KeePass.

Expected timeline

Minutes, once a survivor has the file and the master password (plus key file, if used). There is no waiting period and no review queue.

Gotchas

• The key file is a second lock, not a convenience. If your database needs a key file (or hardware key), the master password alone will not open it. Both must survive. Escrow the password, and make sure the key file is stored somewhere findable and named on the card.
• A stale backup is a stale vault. Survivors get whatever was in the last saved copy of the .kdbx. If you add or change logins, refresh the stored copy. Set a reminder alongside your bundle re-export.
• Don’t stash the only .kdbx copy inside the very bundle it’s meant to unlock, then lose the drive. Keep at least one durable copy the estate can physically reach.
• Vaultwarden / other file-based managers: same recipe: escrow the master password and make the encrypted export/backup reachable. A hosted service you run yourself dies with the server unless the file outlives it.