What does an encrypted dead man's switch protect?

An encrypted dead man's switch protects selected content while it is waiting for a future release. It does not automatically protect every surrounding system.

Encryption can reduce the impact of storage compromise, but the service still depends on account authentication, recipient email, release tokens, key recovery, browser security, file handling, provider operations, and clear legal authority.

Before trusting a service, write down the harm from early disclosure, late or failed disclosure, and permanent loss. The best configuration balances all three rather than treating encryption strength as the only risk.

Questions 1–4: encryption and key custody

  1. Are files encrypted before upload? “Encrypted at rest” may still mean the provider holds all server keys and can routinely decrypt the content.
  2. Is authenticated encryption used? Confidentiality without integrity checks may not detect modified ciphertext.
  3. Who can recover the key? Distinguish assisted recovery from true self-custody in plain language.
  4. What happens if the recovery secret is lost? A secure design must state whether recovery is possible, not hide the answer in marketing copy.

Ask whether filenames, delivery names, recipient addresses, file sizes, timing, IP addresses, and activity records remain visible. Encryption of file contents does not make all metadata disappear.

Questions 5–8: account and recipient security

  1. Does sign-in count as a check-in? Presence should be a deliberate, auditable action rather than a side effect of unrelated account activity.
  2. Can sensitive changes require stronger authentication? Recipient changes, release, key recovery, billing, and account deletion deserve additional assurance.
  3. Is the recipient verified before private details appear? Possession of a forwarded email link should not reveal sender-selected content.
  4. Are release sessions short-lived and restricted? The service should limit purpose, expiry, reuse, and access after revocation.

Also ask whether the recipient receives a generic notice or a subject line containing sensitive names, titles, or filenames. Email is part of the threat model.

Questions 9–12: accidental release and reliability

  1. Is there a separate safety period? One missed check-in should not immediately release the delivery.
  2. Can a valid check-in cancel the warning? The state transition and cut-off time should be clear.
  3. Are release jobs durable and retryable? Email APIs, storage, and server functions fail; an in-memory attempt is not enough.
  4. Can you distinguish access issued from access used? “Released” should not be marketed as proof the recipient opened, decrypted, or acted on the material.

Reliable systems also monitor their own scheduler, sending domain, storage, database, webhook, and billing dependencies. Ask who watches the watcher and how owners are warned if the service itself is unhealthy.

Questions 13–15: expiry, portability and proof

  1. Does released access expire? Long-lived links increase exposure; invisible or very short deadlines can cause permanent loss.
  2. Can you export or reconstruct the plan elsewhere? Provider shutdown should not erase the only copy of critical records.
  3. Can you test end to end? A marketing claim is not evidence that your recipient can recover your file on their device.

For a meaningful test, encrypt a sample file, release it through the real recipient path, verify the intended identity checks, download and decrypt it on another device, and compare its SHA-256 hash with the original. Test failure states too: expired links, wrong codes, revoked recipients, and tampered ciphertext.

Security claims that need closer reading

Be cautious with:

“Zero knowledge.” Ask what the provider knows about metadata, which mode is being described, and whether any assisted-recovery path exists.

“Military-grade encryption.” This says little about key generation, recovery, implementation, endpoint safety, or access control.

“A delivery guarantee.” No provider controls every inbox, domain, device, human response, payment dependency, or internet outage.

“Legally binding.” Software delivery does not automatically create a valid will, trust, power of attorney, transfer, or corporate approval.

“Impossible to hack.” Secure systems describe boundaries, testing, incident response, and residual risk rather than promising impossibility.

How ZeroLatch answers the checklist

ZeroLatch encrypts files in the browser using AES-256-GCM and separates a deliberate check-in from ordinary sign-in. A missed deadline begins a safety period; the recipient receives nothing during that period.

Release emails omit sender-selected private details. The recipient exchanges the link for restricted access and verifies the intended email address before seeing the sender, message, or files. Released access is time-limited.

Simple mode supports authorised assisted recovery. Private mode requires a separately preserved recovery code that ZeroLatch does not store. ZeroLatch does not claim to verify death, replace legal authority, provide urgent emergency response, guarantee email delivery, or remove every source of metadata and operational risk.

The service remains in controlled early access. Use synthetic data until you have personally completed and repeated the full path appropriate to your recovery mode.