Dead Man's Switch: How Automated Will Transfer Works

When someone dies, the people closest to them rarely think about passwords, encryption keys, or cloud storage accounts. They are grieving, handling arrangements, and navigating bureaucracy. Yet digital assets need attention quickly — accounts can be locked, subscriptions keep billing, and time-sensitive access windows close.

A dead man's switch eliminates the need for survivors to figure out what exists and how to reach it. The system detects your absence and acts on your behalf, automatically.

This guide explains what a dead man's switch is, how digital implementations work, the engineering behind liveness check systems, and how to set one up for your digital will.

---

What Is a Dead Man's Switch?

A dead man's switch is a mechanism that activates automatically when its operator becomes incapacitated or unresponsive. If the operator fails to perform a required action within a set time window, the switch triggers a predetermined response. The defining characteristic is inversion of control: the system acts not when you do something, but when you stop doing something.

The concept originates from physical safety systems in heavy machinery and transportation. The term has been in use since at least the early 20th century, and the mechanism itself predates the name.

Historical Origins

Railway dead man's switches were among the earliest implementations. Steam and diesel locomotives equipped a spring-loaded pedal or handle that the engineer had to actively hold down while the train was in motion. If the engineer released the control — due to a heart attack, falling asleep, or any other incapacitation — the spring returned the control to its default position, which engaged the emergency brakes and cut power to the engine.

Modern trains use more sophisticated versions called alerter systems. Instead of requiring continuous physical contact, they prompt the engineer at regular intervals (typically every 25-40 seconds of inactivity) with an audible alarm. If the engineer does not acknowledge the alarm within a set window, the system applies brakes automatically.

Industrial machinery uses dead man's switches extensively. Chainsaws, lawnmowers, and industrial presses require the operator to maintain grip on a safety lever. Releasing the lever stops the machine. This is mandated by safety standards such as ISO 13849 (safety of machinery) and enforced by agencies like OSHA in the United States.

Military applications include nuclear deterrence protocols (though the specifics are classified) and explosive ordnance disposal, where a dead man's switch can be wired to detonate if the operator is neutralized. This adversarial use has given the term a darker connotation, but the underlying mechanism is the same.

The principle is consistent across all of these: a periodic human action is required to maintain a safe state. Absence of that action triggers an automated response.

---

Digital Dead Man's Switches Explained

A digital dead man's switch applies the same principle to software systems. Instead of a physical pedal, the operator must periodically confirm their presence through a digital action — clicking a link in an email, responding to a push notification, logging into a dashboard, or any other verifiable interaction.

The core components of any digital dead man's switch are:

1. Liveness signal: The periodic action the operator must perform to prove they are active
2. Check interval: How often the system requests a liveness signal
3. Grace period: How long the operator has to respond to each request
4. Failure threshold: How many consecutive missed signals trigger the switch
5. Payload: The action executed when the switch triggers (send emails, decrypt files, transfer data)

Digital dead man's switches are used for several purposes beyond estate planning:

• Whistleblower insurance: Journalists and activists configure switches to release sensitive documents if they are silenced
• Business continuity: Solo operators ensure that critical credentials and procedures are transmitted to a backup contact if they become unreachable
• Cryptocurrency recovery: Holders ensure their keys are transmitted to beneficiaries if they cannot manage them
• Server administration: Lone sysadmins ensure that root credentials reach a trusted party if they are incapacitated

The challenge unique to digital implementations is balancing sensitivity (detecting genuine incapacitation quickly) against specificity (not triggering during a vacation, illness, or temporary disconnection from technology). This is where liveness check design becomes critical.

---

How Liveness Checks Work

A liveness check system is the engine that powers a dead man's switch. Its job is to determine whether the operator is alive and responsive, with high confidence in both directions: it must not miss a genuine incapacitation, and it must not trigger a false alarm during a period of normal inactivity.

The Three Parameters

Well-designed liveness check systems expose three configurable parameters. In Burning Ash Protocol, these are named HCIT, HCRT, and HCRAC. Understanding what each controls is essential for configuring a reliable dead man's switch.

HCIT: Host Check-In Interval

The Host Check-In Interval defines how frequently the system sends a liveness check to the operator. This is the time between consecutive check requests.

Timeline (HCIT = 7 days):

Day 1         Day 8         Day 15        Day 22
  |             |             |             |
  v             v             v             v
[Check #1]  [Check #2]  [Check #3]  [Check #4]

Shorter intervals (e.g., daily) detect incapacitation faster but create more friction for the operator. Nobody wants a daily "check in" notification indefinitely.

Longer intervals (e.g., monthly) are less intrusive but mean longer delays before the system detects a problem. A monthly interval with a 3-miss threshold means it could take over three months before the switch triggers.

For most personal digital will use cases, a 7-day interval is a reasonable default. It balances responsiveness with livability.

HCRT: Host Check-In Response Time

The Host Check-In Response Time is the window the operator has to respond to each individual check. Once a check is sent, the clock starts. If the operator does not respond within this window, the check is marked as missed.

Check sent          Response deadline
    |                     |
    v                     v
    |------HCRT (48h)-----|
    |                     |
    |   [Respond here]    |  --> Check passed
    |                     |
    |         [No response] --> Check missed

Short HCRT (e.g., 12 hours) increases the risk of false positives. The operator might be asleep, in a different time zone, or simply away from their devices.

Long HCRT (e.g., 7 days) is very forgiving but delays detection significantly when combined with the check interval.

A 48-hour response window is a practical default. Most people interact with at least one of their devices within any 48-hour period.

HCRAC: Host Check-In Response Action Count

The Host Check-In Response Action Count is the number of consecutive missed checks required before the dead man's switch triggers. This is the most important safeguard against false positives.

Example: HCIT=7d, HCRT=48h, HCRAC=3

Week 1: Check sent --> Missed (no response in 48h) --> Strike 1
Week 2: Check sent --> Missed                      --> Strike 2
Week 3: Check sent --> Missed                      --> Strike 3 --> TRIGGER

Week 1: Check sent --> Missed --> Strike 1
Week 2: Check sent --> Responded --> Counter resets to 0
Week 3: Check sent --> Missed --> Strike 1 (starts over)

A single missed check should never trigger a dead man's switch. People get sick, go on remote vacations, lose their phone, or simply forget. The HCRAC provides a buffer that requires sustained unresponsiveness.

HCRAC=2 is aggressive and appropriate only if the consequences of late triggering are severe and the operator commits to always responding.

HCRAC=3 is the most common configuration. With a 7-day interval, this means approximately 23-25 days of total unresponsiveness before the switch triggers (3 intervals plus response windows).

HCRAC=5+ is very conservative and appropriate for situations where false triggering would be catastrophic and late triggering is acceptable.

Notification Escalation

Sophisticated dead man's switch implementations do not simply send the same notification repeatedly. They escalate across channels as missed checks accumulate:

1. First check: Primary channel (e.g., email)
2. First miss: Primary + secondary channel (e.g., email + SMS)
3. Second miss: All configured channels (email + SMS + WhatsApp + Telegram), potentially with increased urgency in messaging
4. Final miss before trigger: All channels, with explicit warning that the will transfer will initiate if not responded to

This escalation pattern reduces false positives because it increases the chance that the operator sees at least one notification, even if their primary device is unavailable.

The Math of False Positives

The probability of a false trigger depends on the probability of missing a single check and the HCRAC threshold. If the probability of missing any single check is p, and checks are independent events, the probability of a false trigger is p^HCRAC.

For example, if there is a 5% chance of missing any given check (generous estimate for someone with multi-channel notifications):

• HCRAC=1: 5% chance of false trigger (unacceptable)
• HCRAC=2: 0.25% chance (1 in 400)
• HCRAC=3: 0.0125% chance (1 in 8,000)
• HCRAC=4: 0.000625% chance (1 in 160,000)

With multi-channel notifications, the per-check miss probability drops well below 5% for an active, living operator, making HCRAC=3 extremely reliable.

---

Dead Man's Switch vs. Alternatives

Several mainstream services offer features that overlap with dead man's switch functionality. Understanding the differences helps you choose the right tool — or decide to use multiple.

Google Inactive Account Manager

Google's Inactive Account Manager (IAM) lets you configure what happens to your Google account after a period of inactivity. You set a timeout (3, 6, 12, or 18 months), designate up to 10 trusted contacts, and choose whether to share your Google data with them and/or delete your account.

Google IAM is a good baseline for your Google-specific data, but its minimum 3-month detection window and Google-only scope make it insufficient as a standalone solution. Use it as a complementary layer alongside a purpose-built dead man's switch.

Password Manager Emergency Access

1Password, Bitwarden, and LastPass offer emergency access features that let a designated contact request access to your vault. After a waiting period (configurable, typically 1-30 days), if you do not deny the request, access is granted.

Password manager emergency access is a reasonable starting point, but it requires someone to manually initiate the process. If nobody knows to request access — or if the designated contact is also incapacitated — the system never triggers. A dead man's switch removes this dependency by actively monitoring and automatically initiating the transfer.

Email-Based Dead Man's Switches

Services like Dead Man's Switch (deadmansswitch.net) and similar tools send you periodic emails. If you do not click the confirmation link within the window, pre-written emails are sent to your designated recipients.

Email-based dead man's switches are the simplest option and adequate for low-sensitivity use cases, like sending a farewell message. For anything involving credentials, financial information, or encryption keys, the lack of payload encryption and recipient authentication is a serious limitation.

---

Why Encryption Matters for Dead Man's Switch Payloads

A dead man's switch is only as secure as the payload it delivers. The most sophisticated liveness check system in the world is worthless if the payload — your credentials, your financial information, your private keys — is stored or transmitted in plaintext.

The Threat Model

Consider what happens when a dead man's switch triggers:

1. The system determines you are unresponsive
2. Notifications are sent to your Survivors
3. Survivors access the payload

At each stage, there are threats:

• At rest: If the payload is stored unencrypted on a server, anyone with server access (administrators, hackers, law enforcement with a subpoena) can read it before the switch ever triggers.
• In transit: If the payload is sent via unencrypted email, it passes through multiple mail servers in plaintext. Any intermediate server can read and copy the content.
• At the recipient: If the payload arrives without recipient authentication, anyone who intercepts the notification (email compromise, phone theft) can access the data.

Defense in Depth

A properly secured dead man's switch payload uses multiple layers of protection:

Layer 1: Encryption at rest. The payload is encrypted with AES-256-GCM using a per-will Data Encryption Key (DEK) before it is stored. The hosting service never has access to the plaintext content. This is the standard recommended by NIST SP 800-57 for key management in data-at-rest scenarios.

Layer 2: Distributed key management. The DEK is split using Shamir's Secret Sharing, with shares distributed to individual Survivors. No single entity — not the service, not any individual Survivor — holds enough information to decrypt the payload. Reconstruction requires threshold cooperation.

Layer 3: Authenticated access. Survivors must verify their identity (via OTP sent to their registered contact method) before receiving their key fragment. This prevents unauthorized access even if a notification is intercepted.

Layer 4: Transport encryption. All communication between the service and Survivors occurs over TLS. Notification channels use their own transport encryption (HTTPS for email APIs, end-to-end encryption for WhatsApp and Signal-based channels).

This layered approach means that compromising any single layer does not expose the payload. An attacker would need to breach the server (to get encrypted data), obtain threshold key shares from multiple Survivors (to decrypt), and bypass OTP authentication (to impersonate a Survivor) — simultaneously.

What About Quantum Computing?

AES-256 is considered quantum-resistant by NIST. Grover's algorithm reduces the effective security of symmetric keys by half (AES-256 becomes effectively AES-128 against a quantum computer), but AES-128 equivalent security is still computationally infeasible to break. NIST's Post-Quantum Cryptography standardization (FIPS 203, 204, 205 published in 2024) primarily addresses asymmetric algorithms (RSA, ECC), not symmetric encryption.

For digital wills specifically, the payload has a limited relevance window — it is most critical in the years immediately following the owner's death. Even optimistic projections for cryptographically relevant quantum computers place them at least a decade away, well beyond the practical relevance window for most digital will contents.

---

Types of Dead Man's Switches

Digital dead man's switches can be categorized by what they deliver and who they serve.

Email Notification Switches

The simplest type. Pre-written emails are sent to designated recipients when the switch triggers. These typically contain instructions, farewell messages, or plaintext credentials. Low security, low complexity, adequate for non-sensitive information.

Examples: deadmansswitch.net, IfIdie.org

Document Transfer Switches

These switches deliver encrypted documents or structured data to recipients. They typically include a file vault or document management system alongside the dead man's switch mechanism. The payload is more structured than a plain email and usually includes some form of encryption.

Examples: Burning Ash Protocol, SafeBeyond

Cryptocurrency-Focused Switches

Designed specifically for transmitting cryptocurrency wallet access (seed phrases, private keys, hardware wallet instructions) to beneficiaries. These tend to have the strongest encryption because the payload is directly and immediately monetizable by an attacker.

Examples: Casa covenant, Unchained inheritance protocol

Social Media Managers

These focus on what happens to social media accounts after death — posting farewell messages, memorializing accounts, or deleting profiles. They are narrower in scope but address a specific and common concern.

Examples: GoodTrust, Afternote

Self-Hosted / Open-Source Switches

For users who do not trust any third-party service with their payload, self-hosted dead man's switches run on the user's own infrastructure. The trade-off is maintenance and reliability — if your server goes down, your dead man's switch may not trigger.

Examples: Burning Ash Protocol (AGPL-licensed, Docker deployment)

---

Setting Up BAP's Dead Man's Switch

Burning Ash Protocol implements a full dead man's switch with encrypted payload, threshold key distribution, and multi-channel notifications. Here is how to configure it.

Step 1: Establish Your Liveness Check Parameters

Before touching the software, decide on your parameters based on your lifestyle and risk tolerance:

For most people (moderate risk tolerance, regular device usage):

• HCIT: 7 days
• HCRT: 48 hours
• HCRAC: 3
• Total time to trigger: approximately 25 days of unresponsiveness

For frequent travelers or less tech-engaged users (higher tolerance for delay):

• HCIT: 14 days
• HCRT: 72 hours
• HCRAC: 3
• Total time to trigger: approximately 51 days

For high-security users (cryptocurrency holders, business operators):

• HCIT: 3 days
• HCRT: 24 hours
• HCRAC: 4
• Total time to trigger: approximately 16 days

Step 2: Configure Notification Channels

Set up at least two notification channels for your own liveness checks. Redundancy is critical — if your primary email is down, you need a fallback.

Recommended configuration:

1. Primary: Email (reliable, persistent, searchable)
2. Secondary: SMS or push notification (immediate, attention-grabbing)
3. Tertiary (optional): WhatsApp or Telegram (ensures reach across device and app ecosystems)

In BAP, notification channels are configured as Connectors. On the SaaS plan, platform-managed connectors are available out of the box. On self-hosted deployments, you configure your own SMTP server, Twilio credentials (for SMS and WhatsApp), and Telegram bot token.

Step 3: Designate Survivors and Configure Threshold

Add your Survivors in the BAP dashboard. For each Survivor, you need:

• Their name
• At least one verified contact method (email or phone)
• Their relationship to you (for your own organizational purposes)

Then set the Shamir's Secret Sharing parameters. Consider these scenarios when choosing:

The right choice depends on how much you trust your Survivors individually versus how concerned you are about one becoming unreachable. For most families, 3-of-5 provides a solid balance.

Step 4: Create and Encrypt Your Will

Upload your digital will content through the BAP dashboard. The encryption happens automatically:

1. A unique DEK is generated for your will
2. Your content is encrypted with AES-256-GCM using the DEK
3. The DEK is split into N key fragments using Shamir's Secret Sharing
4. Each key fragment is encrypted and associated with a specific Survivor
5. The original DEK is destroyed — it exists only as distributed key fragments

At no point does the BAP server (or any single entity) hold the complete decryption key.

Step 5: Understand the Transfer Flow

When the dead man's switch triggers, the following sequence executes:

You miss HCRAC consecutive liveness checks
            |
            v
Will Transfer Protocol (WTP) initiates
            |
            v
All Survivors notified via their configured channels
            |
            v
Survivors access the BAP Survivor portal
            |
            v
Each Survivor authenticates via OTP
            |
            v
Authenticated Survivors receive their key fragment
            |
            v
When K Survivors submit their key fragments, the DEK is reconstructed
            |
            v
The will is decrypted and made available to all Survivors

At any point before the WTP completes, you can respond to a liveness check to cancel the transfer. The system is designed to be interruptible — it is a dead man's switch, not an irreversible countdown.

Step 6: Verify Your Configuration

After setup, verify everything works:

1. Check that liveness notifications arrive: Wait for your first scheduled check and confirm you receive it on all configured channels
2. Confirm Survivor registration: Each Survivor should receive an initial notification explaining their role and what to expect
3. Review the dashboard: Verify your HCIT, HCRT, and HCRAC settings are displayed correctly
4. Document your setup: Record your configuration parameters somewhere separate from BAP itself (your traditional will, a conversation with your attorney, or a letter stored with your estate documents)

---

Security Considerations and Threat Models

A dead man's switch handles sensitive data and executes consequential actions. Understanding the threat model helps you configure it appropriately.

Threat: Premature Triggering (False Positive)

Risk: The switch triggers while you are alive but temporarily unreachable, prematurely revealing your will contents to Survivors.

Mitigations:

• Set HCRAC to at least 3 (requires sustained unresponsiveness)
• Configure multiple notification channels (reduces chance of missing every check)
• Use generous HCRT windows (48+ hours)
• BAP allows you to cancel a triggered transfer by responding to any liveness check before the WTP completes

Threat: Failure to Trigger (False Negative)

Risk: You die or are incapacitated, but the switch does not trigger because the service is down, notifications are not delivered, or the system malfunctions.

Mitigations:

• Self-host on reliable infrastructure with monitoring and alerting
• If using SaaS, choose a provider with uptime SLAs and transparent status pages
• Configure notification delivery via multiple independent channels
• Inform Survivors of the system's existence so they can manually investigate if they suspect you are incapacitated

Threat: Server Compromise

Risk: An attacker gains access to the server hosting the dead man's switch and attempts to read will contents or manipulate the switch.

Mitigations:

• End-to-end encryption means the server never holds plaintext will contents
• Shamir's Secret Sharing means the server never holds the complete DEK
• Survivor OTP authentication prevents unauthorized share retrieval
• Regular security updates and access auditing on self-hosted deployments

Threat: Survivor Collusion

Risk: A subset of Survivors equal to or exceeding the threshold cooperate to access the will before you are incapacitated.

Mitigations:

• Key fragments are only distributed after the WTP triggers (Survivors do not hold key fragments preemptively in BAP's implementation)
• The WTP only triggers after HCRAC missed checks, and you are notified at every stage
• Choose Survivors who do not have aligned incentives to collude
• Set the threshold high enough that collusion requires impractical coordination

Threat: Notification Channel Compromise

Risk: An attacker compromises your email, phone, or messaging accounts and either prevents you from receiving liveness checks (causing a false trigger) or intercepts Survivor notifications.

Mitigations:

• Use multiple independent notification channels (a compromise of one does not affect others)
• Enable two-factor authentication on all accounts used for notifications
• BAP's Survivor portal requires OTP authentication independent of the notification channel
• Monitor your notification channels for signs of compromise

Threat: Long-Term Key Viability

Risk: Cryptographic standards evolve. The encryption protecting your will today might be considered weak decades from now.

Mitigations:

• AES-256 is projected to remain secure against both classical and quantum attacks for the foreseeable future (NIST assessment)
• A digital will's relevance window is typically years, not decades
• Self-hosted deployments can be upgraded to newer cryptographic standards as they emerge
• Re-encrypt periodically (annually or biannually) to take advantage of any algorithm improvements

---

Frequently Asked Questions

What happens if I just forget to respond to a liveness check?

A single missed check does not trigger your dead man's switch. The HCRAC parameter (typically set to 3) requires multiple consecutive misses. If you respond to any check during the sequence, the miss counter resets to zero. You also receive escalating notifications across multiple channels as the miss count increases, making it increasingly difficult to accidentally miss all of them.

Can I temporarily pause my dead man's switch?

BAP allows you to snooze or adjust your liveness check parameters from the dashboard. If you are going on a remote vacation or having surgery, you can extend your HCIT or increase your HCRAC temporarily. The important thing is to set a reminder to restore your original settings afterward.

What if one of my Survivors dies or becomes unreachable?

You can update your Survivor list and regenerate key shares at any time while you are active. If a Survivor becomes unreachable, remove them and add a replacement. The Shamir's Secret Sharing parameters are recalculated, and new shares are distributed. This is why the threshold (K) should always be less than the total (N) — to tolerate at least one or two unreachable Survivors.

Is a dead man's switch legal?

Yes. A dead man's switch is a notification and data transfer mechanism, not a legal document. Its legality depends on what it transmits and to whom. Transmitting your own credentials and documents to your designated beneficiaries after your death is legal in all major jurisdictions. However, the legal standing of the transmitted documents (e.g., whether they constitute a valid will) depends on local estate law. See our digital will guide for jurisdiction-specific details.

How is this different from just giving someone my passwords?

Giving someone all your passwords now creates an immediate security risk and requires absolute trust in a single person. A dead man's switch with threshold encryption provides: (1) time-locked access — nobody can see anything until you are unresponsive, (2) distributed trust — no single person holds complete access, (3) automated triggering — no one has to notice your absence and manually act, and (4) authenticated delivery — Survivors must verify their identity to receive their key fragments.

What if the dead man's switch service itself shuts down?

For SaaS services, this is a real risk. If the service shuts down, your dead man's switch stops working. Mitigations include: choosing open-source, self-hostable solutions (like BAP) that you can run on your own infrastructure; keeping offline backups of your will contents; and informing your Survivors about the system so they can take manual action if the automated system fails.

Can I use multiple dead man's switches simultaneously?

Yes, and for high-value digital estates, this is recommended. You might use Google Inactive Account Manager for your Google-specific data, a password manager's emergency access for your credential vault, and BAP's dead man's switch for your encrypted digital will with detailed instructions. Layering systems with different detection mechanisms reduces the risk of any single system failing.

How quickly does the switch trigger after death?

The minimum trigger time equals (HCIT x HCRAC) + HCRT. With default settings of HCIT=7 days, HCRT=48 hours, and HCRAC=3, the switch triggers approximately 23-25 days after your last check-in response. This is configurable — more aggressive settings can reduce this to under a week, while conservative settings can extend it to several months.

---

Conclusion

A dead man's switch is the bridge between having a digital will and having your digital will actually reach the people who need it. Without an automated trigger mechanism, even the most meticulously prepared digital estate plan depends on someone knowing it exists, knowing where it is, and knowing how to initiate the transfer — during a time when they are least equipped to handle it.

The technology is mature. Liveness check systems, threshold cryptography, and multi-channel notification are well-understood engineering problems with proven solutions. The barrier is not technical — it is motivational. Setting up a dead man's switch forces you to confront your own mortality, which most people avoid until it is too late.

Do not be most people. Configure your liveness checks, designate your Survivors, encrypt your payload, and verify the system works. Then go live your life, knowing that if something happens, the people you care about will have what they need.