Threat-Model a Conditional Credential Handoff Before You Trust It
A plain-language threat model for inactivity triggers, recipient access, encrypted files, recovery codes, and operational misuse.
What can go wrong before release?
Begin with false activation. An owner may be travelling, ill, locked out of email, or unable to respond while still capable of acting. Use reminders, a safety period, more than one contact channel where appropriate, and an escalation rule that distinguishes a missed check-in from proof of death or incapacity.
Then consider account takeover. An attacker who controls the owner's account may alter recipients, upload malicious instructions, or suppress check-ins. Protect the account with a unique password and the strongest authentication the service supports. Review recipient addresses and delivery settings after any account recovery event. Keep ordinary privileged access outside the handoff so one compromised application does not become the only route into production.
What can go wrong during and after release?
Email can be forwarded or compromised. A recipient device may be infected. A recovery code may be lost, photographed, or stored beside the encrypted files. Released information may be technically correct but operationally stale.
Reduce impact by splitting duties where practical, limiting each delivery to one scenario, using separate recipients for different roles, and including post-access rotation instructions. A recipient should know how to verify the release, whom to call, and which actions require separate approval. Time-limited links reduce exposure but do not make the recipient's endpoint trustworthy.
How do Simple and Private change the threat model?
Both modes encrypt files in the browser before upload. In Simple mode, the application manages recovery of the content key; the service can technically recover a delivery after the required authorisation path. This reduces the risk of a lost recovery code but increases trust in the application and its server-side key boundary.
In Private mode, ZeroLatch does not store the recovery code. That reduces the service's ability to recover content, but loss of the code becomes permanent data loss. The code must reach the intended responder through a separate, durable channel. Neither choice removes the need to protect the owner account, recipient email, endpoints, backups, and the operational procedure around the released material.
ZeroLatch Security Team
The ZeroLatch Security Team consists of experts in cryptography, digital legacy, and decentralized systems. We build zero-knowledge infrastructure to protect your most critical assets and ensure they reach the right people at the right time.
Disclaimer: The information provided in this article is for educational and informational purposes only and does not constitute legal, financial, or technical advice. ZeroLatch is a software service, not a law firm. We recommend consulting with qualified professionals regarding your specific estate planning, data privacy, and security needs.
Protect Your Digital Legacy
Set up your own zero-knowledge encrypted dead man's switch in minutes. 30-day money-back guarantee.
Get Started →