What is a digital dead man's switch?

A digital dead man's switch is an online inactivity system that waits for a deliberate check-in and performs a prearranged information handoff only after the check-in deadline and a separate safety period both pass.

It is also described as an online dead man's switch, inactivity switch, dead man's switch app, deadman switch app, or automated check-in service. The wording varies, but a responsible design has the same core components: a clear activity signal, a durable clock, warnings, a cancellation path, protected content, a verified recipient, and a recorded release outcome.

The system is not observing life or death. It is observing whether a specific check-in was recorded. That limitation should shape every timing, security, and recipient decision.

The five states of an online dead man's switch

A useful state model is:

Draft. The owner is still preparing content. Nothing is scheduled and nothing can be released.

Protected. The delivery is active. A deliberate check-in resets the clock for every active delivery on the account.

Safety period. The check-in deadline passed. The owner is warned, but the recipient receives nothing. A valid check-in returns active deliveries to Protected.

Release in progress. The complete safety period passed. The system creates restricted recipient access and attempts the required notifications. This work must be retryable because email and provider APIs fail.

Released or release failed. Released means access was issued; it does not prove the recipient opened, downloaded, decrypted, understood, or lawfully used the material. A failure needs a visible state and an operational retry path rather than a silent assumption of success.

This language is more accurate than labelling every configured item “ready.” It separates a saved draft from real protection and separates an attempted release from confirmed human receipt.

Encryption and recovery are separate decisions

“Encrypted” is not a complete security description. Ask three separate questions:

  1. Where does encryption happen? Browser-side or device-side encryption reduces plaintext exposure before upload.
  2. Who can obtain the recovery key? A provider-assisted mode is easier to recover but gives the provider a defined recovery capability. A self-custody mode can remove that capability but creates a permanent lost-code risk.
  3. How is the key bound to the file? Authenticated encryption should detect tampering, and file metadata should be validated before decryption.

ZeroLatch encrypts files in the browser with AES-256-GCM. Simple and Private deliberately have different recovery boundaries. Neither mode removes metadata, endpoint compromise, recipient compromise, malicious files, service outages, legal obligations, or the need to test the entire handoff.

A secure recipient release flow

The notification email should reveal as little as possible. A safer sequence is:

  1. Send a generic notice from a recognisable domain.
  2. Keep the sender's name, delivery title, message, filenames, and recovery hint out of the email.
  3. Exchange the release capability for a short-lived, restricted browser session.
  4. Verify control of the recipient email with a one-time code.
  5. Reveal sender context and available files only after verification.
  6. Require the separate Private password or recovery phrase where self-custody was selected.
  7. Expire access and make the deadline visible.

A link in an email is a capability, so forwarding, mail scanners, screenshots, browser history, and recipient-device compromise all matter. Identity verification protects the access step; it does not prove the recipient is the legally authorised executor, trustee, director, or beneficiary.

What can make a digital dead man's switch fail?

Plan for at least these failure modes:

• The owner misses a check-in while alive • The owner loses access to their email or account • The recipient address is mistyped, abandoned, or compromised • The notification is rejected, filtered, delayed, or opened by a security scanner • A billing or provider outage affects the service • The encrypted material is outdated, malicious, incomplete, or impossible to understand • The Private password or recovery phrase is lost • The recipient has technical access but lacks legal authority • The service provider closes, changes terms, or loses its domain • The recipient never saves the files before expiry

Mitigate these risks with long enough timing, a visible safety period, tested contact details, non-sensitive rehearsals, independent legal records, offline recovery material where appropriate, and a documented alternative if the service disappears.

How should you test a dead man's switch app?

Do not test a live continuity plan by deliberately waiting for real sensitive material to release. Create a synthetic delivery containing an unmistakable sample file, then verify:

  1. The saved draft cannot release before activation.
  2. The check-in resets the expected clock.
  3. The warning does not reveal content to the recipient.
  4. The recipient email contains no private sender-selected details.
  5. The access link requires recipient verification.
  6. The sample file downloads and decrypts on a separate device.
  7. The resulting file exactly matches the original, ideally by SHA-256 hash.
  8. Old, expired, revoked, or previously consumed links fail.

Repeat the test after meaningful changes to email, encryption, recipient identity, storage, or release processing.