A practical guide to keeping your critical information safe for the people who matter
The first step is to create a document on your own computer — a Word file, a Notepad document, a text file in your favourite editor. This is your working document. It should contain everything someone would need to know if you weren't around to tell them.
Include things like:
This is YOUR working document. It stays on YOUR computer, protected by YOUR normal access controls. You can update it anytime without any restrictions.
A vault slot can only be updated once every 30 days. We suggest setting a recurring monthly calendar reminder. When the reminder fires:
Open your working document.
Copy the text.
Log into your IfGone vault.
Overwrite the vault slot with the latest text.
Done — your vault now has a recent copy.
The vault is NOT your working document. It's not a backup. You should follow normal 3-2-1 backup practices for your working document. The vault is for when you're NOT around to unlock your computer.
You might wonder why you need both a working document and a vault copy. The answer is separation of concerns:
The vault provides a likely up-to-date version of your critical information for the situation where the owner can't provide access themselves. It bridges the gap between your daily life and the people who may need to step in.
The physical plate (or printed QR code) is what gives someone access to your vault. Keep it somewhere safe but accessible to the right person when needed.
There's no need to "register" anyone — whoever has the physical plate can access the vault. This is by design. It's the same principle as giving someone a key to your house: if you trust them with the key, they can get in.
Keep it simple — plain text works great. Don't overcomplicate it with formatting.
Organise by category — financial, digital accounts, practical info, personal messages. Make it easy to find things.
Update it whenever something changes — new bank account, changed password, new subscription. Don't wait for your monthly reminder.
Don't include everything — focus on what someone would NEED to know. This isn't an autobiography; it's a practical reference.
Add a "last updated" date at the top — so you (and anyone who reads it later) know how current the information is.
Most password managers — Bitwarden, 1Password, KeePass, and others — provide an export function that produces a file containing your stored credentials. The exact format does not matter as long as your manager has a matching import process to restore the data later.
As the vault owner, you can use a scheduled job (cron on Linux, Task Scheduler on Windows) to automatically export your passwords and upload the encrypted file to a vault slot via the API, signed with your private key PEM. This keeps the vault copy current without manual effort.
In a different vault slot, you should include clear instructions explaining how to restore the password backup into a working state — possibly on a different computer, a different network — so that the executor can access your protected systems. Think of it as a step-by-step guide for someone who has never used your password manager before.
This is NOT a replacement for the password manager itself. The vault copy exists for when you are no longer around to provide access. Continue using and maintaining your password manager as your primary tool.
Be sure to document the export format in your instructions — which format was used (CSV, JSON, proprietary), which version of the password manager produced it — so the executor knows exactly what they are dealing with.
An advanced use case: you can provide instructions for an executor — perhaps a solicitor or trusted technical contact — to visit a crafted URL containing a unique payload, cryptographic signature, or other impossible-to-guess and impractical-to-brute-force path. This URL will kick off actions you wanted processed when you are no longer around.
These actions could be anything: publishing a final blog post, securely deleting sensitive files from a remote server, executing a cryptocurrency trade, sending pre-composed messages, or triggering any other automated process you have set up on your own infrastructure.
The execution of the action is not related to IfGone. There is no guarantee the executor will indeed call the HTTP server as requested, and IfGone has no way to verify whether the action was carried out. This is, by design, a dead man's switch with a low guarantee of execution.
The URL and any required authentication details should be stored in a vault slot, with clear instructions on when and how to trigger it. Include the full HTTP method, headers, and any parameters the executor would need to send.
This feature is intended for technically capable owners who understand HTTP requests, API authentication, and the risks of relying on a third party to trigger automated actions. If you are not comfortable with these concepts, this section does not apply to you.
IfGone does not execute the action — it simply stores the instructions for the executor. The entire mechanism runs on infrastructure you control.