Dead man's switch: what it is, and how to set one up by email

What is a dead man's switch?

The term comes from machinery. A dead man's switch is designed to act if the operator becomes incapacitated: a train driver has to keep pressure on a handle or pedal, and if it is released the emergency brakes apply. Newer rail systems add a vigilance check that asks the driver to respond at intervals, because a slumped operator can still hold a handle down. Walk-behind lawn mowers sold in the US must stop their blades within three seconds of the user letting go. Software versions turn the idea around: instead of stopping something, they start something when you go quiet.

• ✓Rail: release the handle or miss the vigilance alarm and the brakes apply
• ✓Lawn mowers and power tools: let go and the blade stops
• ✓Email and software: miss a login or check-in for a set number of days and a stored message, alert or deletion runs

Ways to set up a dead man's switch email

Several services offer a version of this. They differ in what they send, who can receive it and what the recipient has to prove.

• ✓Google Inactive Account Manager: you choose how long Google waits after your account goes inactive. Then up to 10 people get an email you wrote and, if you choose, a link to download selected Google data. Contacts verify their identity by phone. It covers your Google account only.
• ✓Apple Legacy Contact: not a timer. A contact needs the access key you shared and a death certificate, and iCloud Keychain passwords and passkeys are excluded.
• ✓Bitwarden emergency access (premium): a trusted contact requests access and gets it when you approve or when the wait time you set runs out, either view-only or full takeover.
• ✓Dead Man's Switch (deadmansswitch.net): you write emails and check in by clicking a link. On its standard 60-day schedule, reminders go out 30, 45 and 52 days after your last check-in and the emails are sent at day 60; the interval can be changed. Free accounts only send to your own address as a test; premium sends to up to 100 recipients.
• ✓PingVaults: check-in emails plus an encrypted vault. The contact receives recovery information, but decrypting it still needs answers you shared with them separately.

Using a dead man's switch for crypto

For crypto, the switch should deliver a route, not the keys. Tell the contact which wallets and accounts exist, where the protected backups are and which steps to follow, and keep seed phrases and passphrases in the recovery system you chose. Exchange accounts still go through each exchange's estate claim, which an email cannot replace.

PingVaults' free email schedule: an example

The free plan uses a 90-day initial wait, three owner reminders and 14-day intervals. With no check-in or delays, reminders become due around days 90, 104 and 118; contact delivery becomes due around day 132. The scheduler checks every hour, so these are thresholds, not guaranteed delivery times. A successful check-in restarts the initial wait. Paid plans allow a custom schedule.

• ✓Day 90: first owner reminder
• ✓Day 104: second owner reminder
• ✓Day 118: third owner reminder
• ✓Day 132: contact delivery becomes due if still unanswered

What does the contact receive—and what stays private?

The recovery email provides the vault location and recovery-field structure, not the answers needed to decrypt it. New ciphertext is uploaded to Arweave through ArDrive Turbo; an upload receipt does not prove the data is already in an Arweave block. Keep the exported JSON containing ciphertext and a verified offline decryptor separately, and tell the contact how to find them.

Test the recovery path before using real secrets

Create a sample instruction with harmless text, export its encrypted JSON, and verify offline decryption with the intended recipient. Separately confirm the contact address and understand the schedule. This drill tests recovery, not future email delivery or the live scheduler; do not deliberately trigger a real emergency workflow just to test decryption.

Define inactivity precisely

Missing one email is not proof of death or incapacity. Travel, spam filters, abandoned inboxes, and service outages all create false positives. A robust policy states the cadence, number of attempts, grace period, and escalation sequence.

Minimize what the switch can expose

Deliver a location, instructions, and decryption clues rather than a reusable signing key whenever possible. If the delivery layer is compromised, encryption and factor separation should still limit what an attacker gains.

Design for both false positives and false negatives

A false positive releases information too early; a false negative leaves heirs without help. Use redundant contact details, backup contacts, calendar reminders, and periodic drills to reduce both failure modes.

Keep legal authority outside the trigger

An automated email cannot determine inheritance rights. The recipient still needs to follow applicable estate documents, custody procedures, and local law before accessing or transferring assets.