AmberKey

Playbook

Any Other Password Manager (including Apple Keychain)

Platform claims verified July 6, 2026

What this mechanism is

Your password manager is the master index to everything else you own online — which makes it the single most valuable thing you can hand your survivors, and the single worst thing to lose. This playbook covers any manager without its own dedicated guide: KeePass, Dashlane, Proton Pass, Enpass, a browser’s built-in manager — and Apple Keychain (iCloud Passwords), which is the default password manager for most people whether they think of it that way or not. The strategy is always the same: check for a native emergency-access feature first; if there isn’t one, escrow the master credential in AmberKey Layer 2.

Set it up now

First, figure out which case you’re in:

  1. Does your manager have a native emergency/legacy feature? Search its help site for “emergency access,” “legacy,” or “inheritance.” Some managers have one (Dashlane, Proton Pass, and others have added or changed such features over time — check the current docs). If yes: set it up per their instructions, record the designee and any waiting period on your AmberKey card, and still consider the Layer 2 escrow below as a fallback.
  2. If it’s Apple Keychain / iCloud Passwords (you save passwords on your iPhone and never installed anything): understand this sharp edge — Apple’s Legacy Contact does NOT include Keychain. Apple explicitly excludes saved passwords, passkeys, and auto-fill cards from what a legacy contact can access (https://support.apple.com/en-us/103128). Your plan is therefore device-mediated:
    1. Set up a Legacy Contact anyway (see the Apple playbook) — it covers photos, notes, messages, and removes Activation Lock from your devices.
    2. Escrow your device passcode (iPhone/iPad) and/or Mac login password into AmberKey Layer 2. A survivor holding the physical device and its passcode can open Settings > Passwords (or the Passwords app) and read every saved password.
    3. Note on your AmberKey card which physical device is the designated “keychain device,” and keep that device around even when you upgrade.
  3. Any other manager with no native feature: escrow the master credentials to Layer 2:
    • The master password.
    • Anything else login requires: secret key / recovery code, the 2FA method and its recovery codes, and the exact sign-in URL or, for offline managers like KeePass, where the vault file lives (paths, devices, sync folder) and the key file if one exists.
  4. Test your own escrow: pretend you know only what’s in the card + secret item, and try to sign in fresh. If you hit a step the escrow doesn’t cover (a 2FA prompt, a key file, an unknown server URL), fix the escrow now.
  5. On the Layer 1 card record: which manager, the account email, where the app/vault lives, whether a native emergency feature is configured and for whom.
  6. Set a reflex: change the master password → re-escrow the same day. A stale master password is the most common way this whole plan fails.

What AmberKey stores

  • Layer 1 (metadata): which password manager, account email, sign-in URL or vault file location, whether a native emergency feature exists and who the designee is, which physical device holds Keychain (for Apple users).
  • Layer 2 (bearer secrets): the master password, plus every co-requisite: 2FA recovery codes, key files’ locations, secret keys — and for Apple Keychain, the device passcode. Incomplete escrow is failed escrow; the test in step 4 is the standard.
  • The password manager’s contents include bank passwords — that’s fine, they live inside its encryption, not in AmberKey. AmberKey holds one key (the master credential), not the thousand things behind it. Survivors should still use the banks’ estate process rather than the stored bank logins — see the banks playbook.

What your survivors do

  1. Open the AmberKey packet’s password-manager card. It tells you which manager the deceased used and which of these three paths applies:
  2. Path A — a native emergency feature was configured: the card names the designated person and the manager. That person follows the manager’s process (often: request access, then wait out a built-in delay). The card notes where to start.
  3. Path B — Apple Keychain: find the device passcode in the AmberKey vault, and the physical iPhone (the card says which one). Unlock the phone with the passcode, open the Passwords app (or Settings > Passwords), and every saved password is there. Two warnings: keep this phone safe and charged — it is now the key cabinet — and don’t erase or trade it in until the estate is fully settled. (The Apple Legacy Contact process in the Apple playbook will NOT give you these passwords — only the physical device will.)
  4. Path C — escrowed master credentials: find the master password (and any recovery/2FA codes) in the AmberKey vault, sign in at the URL on the card, or open the vault file at the location the card gives.
  5. Whichever path: export a full backup of the vault first, before changing anything.
  6. Then work through the AmberKey packet account by account. The password manager gives you the keys; the packet tells you which doors matter and in what order. Leave email and phone for last — everything else resets through them.
  7. If none of the paths works (stale password, missing device): most password managers, by design, cannot recover a vault for you no matter what documents you have. Fall back to account-by-account password resets through the deceased’s email inbox, using the packet’s account list.

Required documents

  • None for any of the three paths. These are bearer credentials and device possession.
  • Password-manager companies generally have no death-certificate unlock process — the encryption makes one impossible. (A few will close an account or refund with documentation; that recovers nothing.)

Expected timeline

  • Paths B and C: minutes, once the AmberKey vault is reconstructed.
  • Path A: whatever waiting period the manager’s emergency feature imposes (commonly days to weeks).
  • Fallback resets without any path: weeks, and some accounts will be permanently lost.

Gotchas

  • Apple Legacy Contact silently excludes exactly the thing people assume it covers. Families set up Legacy Contact, feel done, and discover after a death that Keychain passwords aren’t in the data. The device passcode in Layer 2 is the fix; without it, the passwords are gone when the account is closed or the device is erased.
  • Erasing or trading in the Keychain device destroys the plan. For Apple users, one specific physical phone is effectively the family vault. Upgrading? Re-establish on the new device, update the card, and only then wipe the old one. Survivors: never let a carrier “helpfully” wipe the deceased’s phone during a number transfer.
  • Stale master password = locked vault forever. Zero-knowledge managers can’t reset anything. Re-escrow on every change; this playbook fails silently otherwise.
  • The escrow is only as complete as its weakest missing piece. Master password without the 2FA recovery code, KeePass password without the key file, vault password without the vault file’s location — each is a locked door. That’s why the fresh-login test in setup step 4 exists.
  • Browser-synced passwords follow the browser account. Chrome passwords live behind the Google account (see the Google playbook), Edge behind Microsoft. If the “manager” is a browser, the real plan is the plan for that account.
  • Native emergency features change. Managers add, remove, and re-tier these features (some paywall them). Re-check your manager’s current policy yearly, and keep the Layer 2 escrow as the fallback regardless.
  • Offline vaults can be lost with the hardware. A KeePass file that lived only on a laptop that was sold, or in a sync folder nobody knows about, is unrecoverable. The card must say where the vault file lives, and backups should exist.