The digital legacy provider comparison, as an open dataset
16 providers — every major password manager, every big-platform legacy-contact feature, and the dedicated digital-legacy services — scored on the only two questions that decide whether any of this works. Machine-readable, CC BY 4.0, and every field carries the URL it was read from.
Download
JSON — full records with notes, sources and field definitions.
CSV — flat table, one row per provider.
Version 1.0.0, last modified 2026-08-08. Reuse it under CC BY 4.0; attribution and a link back are all we ask.
The two questions
Does the provider actually verify that you died — or does it just notice that you stopped logging in? And can the provider read your data? Almost every product in this category answers one of these well and the other badly.
Across every record below, verifying death and being unable to read the user's data are mutually exclusive. No product occupies the cell where both are true. That is stated as a falsifiable claim, with the criteria for beating it fixed in advance, at https://github.com/cairnvault/digital-legacy-teardown/issues/8 — anyone may close it with evidence.
The table
This is generated from the JSON file above, so it cannot drift from it. “Unknown” means we could not establish the field from a primary source and declined to guess — it is not a euphemism for “no”.
| Provider | Category | What triggers release | Verifies death? | Provider can read your data? | Passwords included? | Status |
|---|---|---|---|---|---|---|
| Legacy Contact (Digital Legacy) Apple | Platform legacy feature | Death certificate, human review | Yes | Yes | No | verified src |
| Inactive Account Manager | Platform legacy feature | Inactivity timer | No | Yes | Unknown | Partial src |
| Legacy Contact Meta (Facebook) | Platform legacy feature | No release mechanism | Partial | Yes | No | verified src |
| Deceased-user account access Microsoft | Platform legacy feature | Legal process only | Yes | Yes | Unknown | Partial src |
| Emergency Access Bitwarden | Password manager | Contact-initiated silence timer | No | No | Yes | verified src |
| Emergency Access LastPass | Password manager | Contact-initiated silence timer | No | No | Yes | Partial src |
| Emergency Access Proton | Password manager | Contact-initiated silence timer | No | No | Yes | Partial src |
| Emergency Access NordPass | Password manager | Contact-initiated silence timer | No | No | Yes | Partial src |
| Emergency Access Keeper Security | Password manager | Contact-initiated silence timer | No | No | Yes | Partial src |
| Emergency Kit (no emergency-access feature) 1Password | Password manager | No release mechanism | No | No | — | verified src |
| Emergency contacts (discontinued) Dashlane | Password manager | No release mechanism | No | No | — | Partial src |
| Everplans (Deputies) Everplans (subsidiary of Precoa) | Digital-legacy service | Contact-initiated silence timer | No | Unknown | Yes | verified src src |
| GoodTrust (dead man's switch) GoodTrust | Digital-legacy service | Inactivity timer | No | Yes | Yes | verified src src |
| Trustworthy (legacy access) Trustworthy | Digital-legacy service | Death certificate, human review | Yes | Scoped | Yes | verified src src src |
| CipherWill CipherWill | Digital-legacy service | Inactivity timer | No | No | Yes | verified src |
| CairnVault CairnVault | Digital-legacy service | Death certificate, human review | Yes | No | Yes | Self-reported src |
How to read “provider can read your data”
The answer is yes whenever the provider holds the keys, and also whenever the provider can grant a third party access — because access a company is able to grant is access that company has. It is scoped where a vendor's inability-to-read claim is real but covers only some fields. It is no only where encryption happens on the user's device and the provider never receives the key.
Method, and the conflict of interest
CairnVault sells a commercial product in this category and is therefore not a neutral party. That is why every field is sourced to the vendor's own page rather than to us, why the last record in this file is our own product held to the same schema, and why unverified fields are marked "unknown" instead of filled in. Check the sources.
Every claim was read from the vendor's own live documentation and quoted verbatim where the wording carries the weight. Roughly a third of the competitive claims we started with did not survive that check and were retracted — including three that were in our own marketing. The dated correction log and the open verification questions are both public.
Nothing in this dataset is legal advice. Statutory interaction (RUFADAA and its state enactments) varies by jurisdiction. Vendor terms change; re-verify before relying on any of this. If a row is wrong, open an issue — corrections are published with dates, including corrections against us.