{
  "name": "Digital Legacy Provider Comparison",
  "description": "A structured, primary-source comparison of what every major password manager, platform legacy-contact feature and dedicated digital-legacy service actually does when a user dies. Each record is scored on the only two questions that matter: does the provider verify that the user actually died, and can the provider read the user's data. Every field carries the source URL it was read from, and any field that could not be established from a primary source is recorded as \"unknown\" rather than guessed.",
  "version": "1.0.0",
  "dateCreated": "2026-08-02",
  "dateModified": "2026-08-08",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "creator": "CairnVault Research",
  "url": "https://research.cairnvault.app/digital-legacy-teardown/dataset.html",
  "disclosure": "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.",
  "notLegalAdvice": "Nothing in this dataset is legal advice. Statutory interaction (RUFADAA and its state enactments) varies by jurisdiction.",

  "fieldDefinitions": {
    "id": "Stable slug for the record.",
    "name": "The feature or product name as the vendor writes it.",
    "vendor": "The company that operates it.",
    "category": "platform_legacy_feature | password_manager | digital_legacy_service",
    "releaseTrigger": "What actually causes data to be released. One of: death_certificate_human_review, inactivity_timer, contact_initiated_silence_timer, legal_process_only, none.",
    "verifiesDeath": "yes = a death certificate or equivalent is required and reviewed. no = the trigger cannot distinguish death from any other silence. partial = required for some paths only. unknown = not established from a primary source.",
    "providerCanReadUserData": "yes = the provider holds the keys or can grant access to a third party, which is the same thing. scoped = the provider's inability-to-read claim covers only some fields. no = client-side encryption where the provider never receives the key. unknown = not established.",
    "passwordsIncluded": "Whether credentials/passwords are among the data a survivor actually receives. no = explicitly excluded by the vendor.",
    "delay": "Documented waiting period between the trigger firing and release.",
    "price": "As published by the vendor.",
    "sources": "URLs actually fetched and read. Not inferred, not remembered.",
    "verificationStatus": "verified = read verbatim from the vendor's own live page. partial = corroborated but not read verbatim from the primary source. unverified = could not be established.",
    "notes": "Anything that materially qualifies the row."
  },

  "keyFinding": "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.",

  "records": [
    {
      "id": "apple-legacy-contact",
      "name": "Legacy Contact (Digital Legacy)",
      "vendor": "Apple",
      "category": "platform_legacy_feature",
      "releaseTrigger": "death_certificate_human_review",
      "verifiesDeath": "yes",
      "providerCanReadUserData": "yes",
      "passwordsIncluded": "no",
      "delay": "unknown",
      "price": "free",
      "sources": ["https://support.apple.com/en-us/102631"],
      "verificationStatus": "verified",
      "notes": "The strongest of the big-platform options and it excludes the one category families need. Apple's own words: \"Inaccessible data includes movies, music, books, or subscriptions you purchased with your Apple Account, and data stored in your iCloud Keychain (payment information, passwords, and passkeys).\" To file an access request the contact needs both the access key generated at setup and a death certificate. Apple's page also states that in the U.S. and other locales access can be requested with a court order naming the requester as rightful inheritor."
    },
    {
      "id": "google-inactive-account-manager",
      "name": "Inactive Account Manager",
      "vendor": "Google",
      "category": "platform_legacy_feature",
      "releaseTrigger": "inactivity_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "yes",
      "passwordsIncluded": "unknown",
      "delay": "user-selected inactivity period; documented range approximately 3 to 18 months",
      "price": "free",
      "sources": ["https://support.google.com/accounts/answer/3036546"],
      "verificationStatus": "partial",
      "notes": "A silence timer with no death check of any kind. Up to 10 trusted contacts are notified when the period elapses. The 3-to-18-month range is corroborated across independent secondary sources but we could not confirm the exact endpoints with a verbatim quote from Google's own page; the part that matters — that the trigger is inactivity and nothing else — is confirmed. Google separately operates a discretionary request process for deceased users' accounts that does not promise access."
    },
    {
      "id": "meta-legacy-contact",
      "name": "Legacy Contact",
      "vendor": "Meta (Facebook)",
      "category": "platform_legacy_feature",
      "releaseTrigger": "none",
      "verifiesDeath": "partial",
      "providerCanReadUserData": "yes",
      "passwordsIncluded": "no",
      "delay": "not applicable",
      "price": "free",
      "sources": ["https://www.facebook.com/help/1568013990080948"],
      "verificationStatus": "verified",
      "notes": "A grief feature, not an inheritance feature. A legacy contact can manage a memorialised profile, write a pinned post, update the profile picture, respond to friend requests, and request removal of the account. They cannot log in as the deceased or read private messages — which is the correct privacy decision and also means nothing transfers. Correction to our own earlier draft: we had written that a legacy contact cannot delete the account; Meta's live help page lists requesting removal as something they can do. We were wrong."
    },
    {
      "id": "microsoft-account",
      "name": "Deceased-user account access",
      "vendor": "Microsoft",
      "category": "platform_legacy_feature",
      "releaseTrigger": "legal_process_only",
      "verifiesDeath": "yes",
      "providerCanReadUserData": "yes",
      "passwordsIncluded": "unknown",
      "delay": "unknown",
      "price": "free",
      "sources": ["https://support.microsoft.com/en-us/account-billing/accessing-the-outlook-com-onedrive-and-other-microsoft-services-when-the-account-owner-has-died-ebbd2860-917e-4b39-9913-212362da6b2f"],
      "verificationStatus": "partial",
      "notes": "The most restrictive major platform: a subpoena or court order is generally required and success is not guaranteed. Two narrow documentation-only exceptions exist for Germany and China. There is no self-service legacy-contact feature; older 'Next of Kin' references date from the Hotmail era and do not appear in current documentation. Plan around Microsoft, not through it."
    },

    {
      "id": "bitwarden-emergency-access",
      "name": "Emergency Access",
      "vendor": "Bitwarden",
      "category": "password_manager",
      "releaseTrigger": "contact_initiated_silence_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "grantor-set, documented minimum 1 day",
      "price": "emergency access requires a paid grantor plan; the recipient may use a free account",
      "sources": ["https://bitwarden.com/help/emergency-access/"],
      "verificationStatus": "verified",
      "notes": "Bitwarden's documentation is admirably clear: \"Anyone with a free or premium Bitwarden account on the same Bitwarden server can be designated as a trusted emergency contact.\" This retracts a claim in our own earlier marketing that the survivor must already be a paying subscriber — that was false. The real criticism is narrower and worse: the mechanism is a silence timer that cannot distinguish a funeral from an intensive-care stay."
    },
    {
      "id": "lastpass-emergency-access",
      "name": "Emergency Access",
      "vendor": "LastPass",
      "category": "password_manager",
      "releaseTrigger": "contact_initiated_silence_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "grantor-set",
      "price": "recipient does not need Premium",
      "sources": ["https://support.lastpass.com/s/document-item?language=en_US&bundleId=lastpass&topicId=LastPass/c_emergency_access.html"],
      "verificationStatus": "partial",
      "notes": "Same silence-timer design as every other vendor examined. No death verification."
    },
    {
      "id": "proton-pass-emergency-access",
      "name": "Emergency Access",
      "vendor": "Proton",
      "category": "password_manager",
      "releaseTrigger": "contact_initiated_silence_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "grantor-set",
      "price": "recipient may use a free Proton account",
      "sources": ["https://proton.me/support/pass-emergency-access"],
      "verificationStatus": "partial",
      "notes": "Shipped approximately August 2025. Silence timer, no death verification."
    },
    {
      "id": "nordpass-emergency-access",
      "name": "Emergency Access",
      "vendor": "NordPass",
      "category": "password_manager",
      "releaseTrigger": "contact_initiated_silence_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "grantor-set",
      "price": "free users can be recipients",
      "sources": ["https://nordpass.com/features/emergency-access/"],
      "verificationStatus": "partial",
      "notes": "NordPass's support article blocks automated fetching. The \"free users can be recipients\" line comes from NordPass's own blog and support-page snippets rather than a full page we retrieved ourselves."
    },
    {
      "id": "keeper-emergency-access",
      "name": "Emergency Access",
      "vendor": "Keeper Security",
      "category": "password_manager",
      "releaseTrigger": "contact_initiated_silence_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "grantor-set",
      "price": "unknown",
      "sources": ["https://docs.keeper.io/en/user-guides/emergency-access"],
      "verificationStatus": "partial",
      "notes": "Whether the recipient needs a paid plan could not be resolved from primary documentation and we are not going to guess. The silence-timer design is confirmed."
    },
    {
      "id": "1password",
      "name": "Emergency Kit (no emergency-access feature)",
      "vendor": "1Password",
      "category": "password_manager",
      "releaseTrigger": "none",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "not applicable",
      "delay": "not applicable",
      "price": "not applicable",
      "sources": ["https://support.1password.com/emergency-kit/"],
      "verificationStatus": "verified",
      "notes": "The market leader by reputation has no mechanism for this at all. Its Emergency Kit is a self-recovery PDF and 1Password's own guidance is: \"It's important that you don't share your Emergency Kit with anyone.\" The intended workaround is to print it and put it in a safe — a piece of paper, not a feature. 1Password Families 'account recovery' does not fill the gap: it resets the password of a living member who then completes the reset themselves, and a dead person cannot complete that step."
    },
    {
      "id": "dashlane",
      "name": "Emergency contacts (discontinued)",
      "vendor": "Dashlane",
      "category": "password_manager",
      "releaseTrigger": "none",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "not applicable",
      "delay": "not applicable",
      "price": "not applicable",
      "sources": ["https://support.dashlane.com/hc/en-us/articles/202699101"],
      "verificationStatus": "partial",
      "notes": "The automated emergency-contact feature was discontinued. What remains is a manual encrypted export, or live sharing between two people who are both present — which is not a legacy mechanism."
    },

    {
      "id": "everplans",
      "name": "Everplans (Deputies)",
      "vendor": "Everplans (subsidiary of Precoa)",
      "category": "digital_legacy_service",
      "releaseTrigger": "contact_initiated_silence_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "unknown",
      "passwordsIncluded": "yes",
      "delay": "grantor-set, up to 30 days",
      "price": "USD 99.99/year",
      "sources": [
        "https://www.everplans.com/blog/keep-things-private-until-after-youre-gone",
        "https://www.everplans.com/everplans-security"
      ],
      "verificationStatus": "verified",
      "notes": "A designated Deputy reports the death; Everplans then emails the user and waits. Everplans' own words: \"After reporting your death, the Deputy must wait while Everplans attempts to contact you via email with the opportunity to block the unlocking\" and \"You can choose a wait time for your unlockers of up to 30 days.\" We could find no mention of a death certificate anywhere in the documented release process — if nobody clicks the 'I'm not dead' link, the vault opens. On encryption the security page never uses the words zero-knowledge, end-to-end or client-side; it describes strict internal procedures with a stated carve-out, which is a policy promise rather than a mathematical one. Hence providerCanReadUserData is recorded as unknown, not no. Acquired by National Guardian Life Insurance in January 2021 and by Precoa, a pre-need funeral marketing company, in October 2024."
    },
    {
      "id": "goodtrust",
      "name": "GoodTrust (dead man's switch)",
      "vendor": "GoodTrust",
      "category": "digital_legacy_service",
      "releaseTrigger": "inactivity_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "yes",
      "passwordsIncluded": "yes",
      "delay": "three missed check-ins at a user-selected frequency of 1-4 times a month or year",
      "price": "USD 149 first year, then USD 39/year",
      "sources": [
        "https://support.mygoodtrust.com/support/solutions/articles/66000503696-what-is-the-dead-man-switch-and-how-does-it-work-",
        "https://mygoodtrust.com/security"
      ],
      "verificationStatus": "verified",
      "notes": "GoodTrust's own words: \"select how often you would like us to check-in, 1-4 times a month/year\" and \"if you don't reply after 3 times, the dead man's switch will be activated.\" No certificate, no human review. The security page describes TLS in transit, AES-256 at rest in \"our secure databases\", 2FA and SOC 2, and contains zero occurrences of zero-knowledge, end-to-end encryption or client-side encryption. That is a conventional server-side architecture: GoodTrust holds the keys."
    },
    {
      "id": "trustworthy",
      "name": "Trustworthy (legacy access)",
      "vendor": "Trustworthy",
      "category": "digital_legacy_service",
      "releaseTrigger": "death_certificate_human_review",
      "verifiesDeath": "yes",
      "providerCanReadUserData": "scoped",
      "passwordsIncluded": "yes",
      "delay": "duration of staff review",
      "price": "USD 0 to 40/month",
      "sources": [
        "https://www.trustworthy.com/legacy-access-invitation",
        "https://www.trustworthy.com/faq",
        "https://www.trustworthy.com/blog/revolutionary-ai-features"
      ],
      "verificationStatus": "verified",
      "notes": "The most interesting case in the category, because the thing it does best is exactly what creates its problem. The survivor submits a request, provides government ID, uploads a death certificate, and \"Trustworthy's team will review and validate the documents.\" That is a real, human-reviewed process and it is better than every timer above. But if staff can grant a stranger access to a vault, the company can access the vault. Their confidentiality claim — \"Trustworthy uses 'aliasing', a method that scrambles data to make it unreadable. These aliases are irreversible and cannot be solved — not even by the Trustworthy team\" — is scoped to specific tokenised fields (passwords, account numbers, SSNs, notes), not to uploaded documents. Uploaded documents are precisely what their AI 'Autopilot' feature operates on: it \"analyzes hundreds of document types, powered by AI... automatically extracts key metadata, and generates concise natural language summaries.\" An AI cannot summarise a document it cannot read. We allege no bad faith; the tokenised-field claim is probably accurate as written. The point is that the scope of \"not even we can read it\" is much narrower than a customer skimming the homepage would assume. For the record: Trustworthy's Series A was USD 15M led by Valor Siren Ventures in April 2022, bringing total funding to USD 19.7M — we had previously written \"USD 19.7M Series A\" and have corrected it."
    },
    {
      "id": "cipherwill",
      "name": "CipherWill",
      "vendor": "CipherWill",
      "category": "digital_legacy_service",
      "releaseTrigger": "inactivity_timer",
      "verifiesDeath": "no",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "day 100 of continuous inactivity",
      "price": "free tier, or USD 40/year",
      "sources": ["https://www.cipherwill.com/i/how-execution-timeline-works"],
      "verificationStatus": "verified",
      "notes": "An independent product with a genuine client-side encryption architecture — philosophically the closest thing in the category to what we build, and the one we most wanted to be fair to. Documented timeline: day 3 activity check, day 30 urgent attention, day 90 last call, day 100 key release to beneficiaries, day 200 zero-data purge. Any activity resets the clock, so the question deciding release is not \"did this person die\" but \"did this person log in within 100 days\". A hospitalisation, a lost phone, a lost 2FA device or a long trip is indistinguishable from death. Their homepage claims AES-256 and zero-knowledge proofs and elliptic-curve (BLS12-381, SECP256K1) and one-time-pad and lattice-based CRYSTALS-KYBER encryption simultaneously; that combination is unusual and no technical paper substantiating it appears to exist. Their client code is open source, which is genuinely commendable; the server — the component that decides when to release your data — is not."
    },

    {
      "id": "cairnvault",
      "name": "CairnVault",
      "vendor": "CairnVault",
      "category": "digital_legacy_service",
      "releaseTrigger": "death_certificate_human_review",
      "verifiesDeath": "yes",
      "providerCanReadUserData": "no",
      "passwordsIncluded": "yes",
      "delay": "duration of human claim review",
      "price": "USD 79 one-time to build the plan, plus an optional USD 29/year to keep it maintained — the two are separate and never bundled",
      "sources": ["https://cairnvault.app"],
      "verificationStatus": "self-reported",
      "notes": "This is our own product and it is listed here so the schema is applied to us on the same terms as everyone else. Read this row as a vendor claim, not as research: unlike every other row it is not sourced to a third party. Encryption is client-side, key exchange is post-quantum, release requires a two-of-two split key, and death claims are reviewed by a human. The design intent is that verifying death and being unable to read the data are both true at once, which is the empty cell described in keyFinding. If you can show that some other product already occupies that cell, or that ours does not, the open challenge at https://github.com/cairnvault/digital-legacy-teardown/issues/8 is the place to say so and it will be published. Not legal advice, and not a substitute for a will or an attorney."
    }
  ]
}