How to Give Someone Access to Your Accounts After You Die

There are three realistic routes to giving someone access to your accounts after you die: share credentials in advance, configure each platform’s legacy or emergency-access features, or deliver access instructions automatically via a dead man’s switch. Each works, each has real trade-offs, and the strongest setups combine them.

Here is the honest comparison.

Route 1: Sharing credentials in advance

The simplest approach: give someone your passwords now — on paper, in a shared document, or in a shared password manager vault.

The upside: it is immediate and free. If something happens tomorrow, your person can log in today.

The problems:

• It goes stale. Rotate a password, add an account, change your 2FA device — the shared copy is now wrong, and stale access instructions can be worse than none because they waste your successor’s critical first days.
• It grants access now, not when needed. Your successor (or anyone who finds the paper) holds the keys to your business while you are still running it. That is a standing security risk and, for many relationships, an uncomfortable amount of trust.
• Storage is usually weak. The notebook in the desk drawer and the “passwords-final-v2” spreadsheet are both common and both bad.

If you go this route, do it through a password manager’s sharing or emergency-access feature rather than paper — at least then the shared copy updates when you rotate credentials.

Route 2: Platform legacy and emergency-access features

Several major platforms have built real features for this, and you should configure them regardless of what else you do:

• Apple Legacy Contact — lets you designate people who can access your Apple account data after your death, using an access key plus a death certificate.
• Google Inactive Account Manager — lets you define an inactivity period after which Google notifies chosen contacts and shares selected account data with them.
• Facebook legacy contact / memorialization — manages what happens to a profile after death.

Password managers deserve a special mention here: most major ones offer an emergency access feature where a designated person requests access, a waiting period passes (giving you time to deny the request), and then the vault opens. This is a genuinely good mechanism for credential handover — we have a detailed breakdown in password manager emergency access vs. Imok.

The upside: official, supported, and (mostly) free. No one has to beg a support queue.

The problems:

• Coverage is patchy. These features cover the platforms that offer them. Your registrar, your hosting, your payment processor, your niche SaaS tools — most of the accounts a business actually runs on have no equivalent.
• Data access is not operational transfer. Getting into your Google account gives someone your email and files. It does not tell them which client is mid-project, what the server runs, or what to do first.
• Configuration burden scales with account count. Every feature must be set up separately, in advance, and kept current.

Route 3: A dead man’s switch

The third route solves the timing problem directly. You write a packet of access instructions — where credentials live, what the accounts are, how the money flows, what to do on day one — encrypt it, and let a dead man’s switch deliver it to your designated successor only if you stop checking in.

The upside: access arrives exactly when needed, not before; the packet stays current because you can update it anytime; and with zero-knowledge encryption, nobody — including the service provider — can read it while it waits.

The limitation: a switch delivers instructions, not magic. If your successor still cannot unlock your password manager, the instructions should say how (for example: “emergency access is configured with my vault, request it, the waiting period is 48 hours”). The switch is the delivery and context layer; credentials themselves live in proper credential storage.

Keys without the map

The deepest failure mode of routes 1 and 2 is not security — it is context. Handing someone every password you own still leaves them unable to answer:

• Which of these 40 accounts actually matters?
• Which client is mid-project and needs a personal email this week?
• What bills itself monthly and how do I cancel it?
• Is the intent to continue this business or wind it down?
• Where are the backups, the contracts, the SOPs?

Access without instructions is keys without the map. Your successor gets into the building and has no idea which room anything is in. This is why the “what to do” layer matters as much as the “how to log in” layer — a pattern that shows up across digital legacy planning for freelancers and solopreneurs alike.

Where Imok fits

Imok is the map layer. Your handover packet — accounts, money flows, key relationships, first-week instructions — is encrypted in your browser with AES-256-GCM before upload, and the passphrase never leaves your device, so we cannot read it and cannot recover it. It is delivered to your successor through a one-time link only after a staged escalation: five days of email reminders to you, then a check with your trusted contact. The details are on our security page.

The practical setup for most one-person businesses:

1. Credentials live in a password manager with emergency access configured for your successor.
2. Platform legacy features (Apple, Google) are switched on — they are free and take minutes.
3. Imok holds the encrypted instruction packet that explains everything above and delivers it automatically.

Three layers, each doing the job it is best at. The result is that your successor gets both the keys and the map — at exactly the moment they need them, and not a day earlier.

Frequently asked questions