Definition
- Dead man's switch
- A mechanism that activates when a person fails to perform a required action — such as a periodic check-in — within a set time. In digital inheritance, it often triggers delivery of encrypted instructions or credentials to trusted contacts.
The name comes from train engineering: if an operator became incapacitated, a released pedal would stop the train. Online, the 'release' might mean sending a beneficiary email, unlocking a vault, or notifying an attorney.
Historical origin
Physical dead man's switches appear in locomotives, lawn mowers, and industrial equipment — always tied to immediate safety. Digital versions emerged as people realized password vaults and crypto keys could outlive their owners with no release mechanism.
Early implementations were crude: cron jobs emailing a file if a server ping failed, or encrypted ZIP attachments scheduled to send on a calendar date. Modern services add grace periods, multi-step verification, and beneficiary-specific permissions.
Digital dead man's switch
A digital dead man's switch combines three elements: stored secrets, a timer or activity monitor, and a delivery channel. The user periodically confirms they are active; failure after warnings triggers release.
| Component | Function |
|---|---|
| Stored payload | Encrypted documents, passwords, instructions |
| Timer / monitor | Inactivity interval, missed check-ins, calendar date |
| Verification | Email link, app tap, optional trusted-contact confirm |
| Delivery | Email to beneficiaries, portal access, API webhook |
Common use cases
- Passing crypto wallet instructions to family after death or incapacitation
- Releasing business continuity documents to a partner
- Notifying a lawyer when check-ins stop during solo travel
- Delivering personal letters or final messages on a schedule
- Escalating access when someone cannot respond due to medical emergency
Ever Legacy uses a Heartbeat system: periodic emails ask you to confirm you are okay. Missed responses during a configurable grace period begin beneficiary notification — without releasing data on a single missed email.
Inactivity timers
Timers define how long silence must last before action. Intervals range from weekly check-ins to quarterly. Shorter intervals catch problems faster but increase notification fatigue; longer intervals suit stable routines but delay emergency response.
- Fixed calendar date: releases on a specific day regardless of activity
- Rolling inactivity: resets each time you check in
- Hybrid: minimum date AND inactivity requirement
- Manual trigger: trusted contact requests release with verification
Verification systems
Verification reduces false activation. A single bounced email should not dump passwords to heirs. Good systems send multiple reminders, require explicit confirmation links, and offer snooze for planned travel.
- Primary: user clicks 'I'm okay' in email or app
- Secondary: SMS or push notification backup
- Tertiary: trusted contact confirms emergency (some services)
- Cancel path: logging into the dashboard stops escalation
Trusted contacts
Beneficiaries or trusted contacts receive output when the switch triggers. They should know they are named — without necessarily seeing vault contents today. Clear roles prevent surprise and help them act responsibly when notified.
Encrypted delivery concepts
Payloads should remain encrypted at rest until delivery. Transport uses TLS. After release, beneficiaries often receive a secure link with expiration rather than attachments in plain email. Server-side encryption models allow delivery when triggered; zero-knowledge models may require pre-shared keys.
Compare technical approaches in our dead man's switch apps comparison.
Security considerations
- Protect the check-in email account — compromise could suppress confirmations
- Use strong account passwords and 2FA on the switch service itself
- Review beneficiary list when relationships change
- Understand whether the provider can decrypt your vault (trust model)
- Keep a manual override: logging in cancels false triggers
False activation risks
False activation releases sensitive data while you are alive — often during vacation, hospital stays without email access, or spam filtering blocking check-in messages. Mitigate with grace periods, multiple channels, and pre-travel snooze settings.
Privacy considerations
Beneficiaries learn you named them when triggered — or sometimes when invited. Consider what metadata the service exposes before activation. Some people split sensitive items across multiple beneficiaries with partial views.
Comparison of approaches
| Approach | Pros | Cons |
|---|---|---|
| Calendar-only release | Simple to set up | No real-time incapacity detection |
| Email heartbeat | Low friction, familiar | Depends on email deliverability |
| App-based check-in | Push notifications | Requires app installed |
| Trusted-contact petition | Human judgment | Slower, relationship dependent |
| Lawyer-held letter | Professional oversight | Cost, not automated |