You add a Legacy Contact to your Apple Account, configure Google’s Inactive Account Manager, choose people you trust, and assume that your digital inheritance is now arranged.
It is certainly better than doing nothing. Both tools can preserve valuable parts of your digital life and give your family a recovery path that would not otherwise exist.
But they do not create a complete digital inheritance plan.
With Apple, you are preparing a future claim through which your Legacy Contact may request eligible account data after your death. With Google, you are creating an automated instruction to notify selected people or share selected data if your account becomes inactive.
Those are useful functions, but in both cases, the platform still defines the boundaries. Apple and Google decide what information can be released, what remains excluded, what event activates the process, how the recipient is verified, and what form of access is ultimately provided.
You are planning inside their systems and under their rules.
What Apple and Google Actually Provide
Apple Legacy Contact is designed to give selected people access to certain information stored in your Apple Account after your death.
The available data may include photos, messages, notes, files, device backups, and other eligible information. However, Apple excludes purchased media and subscriptions, as well as data stored in iCloud Keychain. That means your Legacy Contact cannot obtain the passwords or passkeys stored there.
To begin the process, the Legacy Contact needs the unique access key created when you selected them and a copy of your death certificate. Apple then verifies the request before providing access.
Google’s Inactive Account Manager follows a different model. You can select up to ten contacts, decide which data each person should receive, and choose how long Google should wait before considering the account inactive.
When the configured period passes, Google can notify those contacts and provide a link to download the data you selected. The recipient’s phone number is used to help verify that the intended person is accessing the data. Google also makes clear that some account information cannot be shared through this system.
Neither tool gives another person access to your complete account, all your credentials, or control over every external service connected to your email address.
The Platform Still Defines the Transfer
Apple determines which categories of account data a Legacy Contact may access. It also determines what documentation must be presented and whether the submitted request satisfies its requirements.
Google gives you more control over which contacts receive which data, but Google still determines which products are included, which information is eligible for sharing, what signals count as activity, and how the recipient must verify themselves.
This dependence may not matter when the process works exactly as expected. The problem appears when something falls outside the expected path.
Companies can also discontinue products, change interfaces, reorganize accounts, add or remove data categories, and modify their verification procedures.
This does not mean Apple or Google intend to ignore your instructions. It means that your instructions exist inside a service controlled and maintained by somebody else.
Have You Ever Tried to Appeal a Decision Made by a Huge Company?
Appealing a platform decision is frustrating even when you are alive, in possession of your devices, and able to explain the history of your own account.
Now imagine your heir doing the same while trying to prove their eligibility or explain inconsistencies in the documents they submitted.
If the standard process fails, your heir may have to deal with automated support systems, identity checks, unfamiliar legal terminology, and an overly complicated process that leaves little room for individual circumstances.
The company’s caution is understandable. Releasing a deceased or missing person’s private data to the wrong applicant would be a serious failure. The company controls the review process, the interpretation of its rules, and the final decision.
That is a fragile position in which to place the only route to an important asset.
Their Triggers May Not Match the Real Emergency
Digital inheritance is normally described as a problem that begins after death. In reality, somebody may need access to your resources or instructions long before a death certificate exists.
People may disappear while travelling, suffer a medical emergency, lose every device they own, become incapacitated, be detained, or simply become unreachable.
Apple Legacy Contact does not address those situations directly. Its trigger is documented death. If you are alive but unable to communicate, the event required to activate the Legacy Contact process has not occurred.
Google’s inactivity model is broader, but inactivity is still only an indirect signal.
Google considers signals such as recent sign-ins, activity recorded in My Activity, Gmail usage, and Android device check-ins. Those signals can establish that an account appears to be in use, but they cannot establish who is actually in control or why the activity stopped.
A connected phone may continue checking in after its owner becomes unavailable. Another person may still have access to the account. A business device may continue generating activity. The account may remain technically active even though the person whose availability matters is no longer responding.
The opposite can also happen. Someone may abandon an old Google Account, move to another provider, or stop using a device without suffering any emergency.
Neither system asks the more practical question:
Has the owner stopped responding across enough independent channels that the emergency process should now escalate?
That question requires more than one fixed trigger.
Neither Platform Sees Your Entire Digital Estate
Apple can only act on information inside the Apple ecosystem. Google can only act on information associated with Google products.
Your most important digital asset may exist somewhere else entirely.
It may be:
- a self-custodied cryptocurrency wallet;
- an account with a cryptocurrency exchange;
- a portfolio of domains;
- a server running an online business;
- a source-code repository;
- a cloud-provider account;
- a payment processor;
- a password-manager vault;
- an encrypted drive;
- a hardware security key;
- a monetized social-media channel;
- a database;
- a set of API credentials;
- or an autonomous agent operating from a server and controlling its own wallet.
Your Google Drive may contain hundreds of documents, but your heir would still need to know what to search for and where to look. Nor should you store every password, private key, or recovery phrase in plain text on Google Drive, because that would create another serious point of failure.
Digital inheritance has at least three stages:
1. Your heir must discover that an asset exists.
2. They must obtain the technical information needed to access it.
3. They may need legal authority to control or transfer it.
Apple and Google can help with the first stage and, in limited cases, part of the second. They do not automatically solve all three.
Giving Someone the Secret Today Creates Another Problem
Once people recognize the limits of platform tools, the obvious alternative is to give the important information to somebody in advance.
You might hand a cryptocurrency recovery phrase to a relative, put passwords into a will, leave a document in a safe, give an emergency kit to a lawyer, or divide a secret between several people.
This improves the chance that somebody can find the information later. It also makes the information available earlier.
A person holding a readable seed phrase does not need to wait to use it. A document stored in a physical location can be copied or photographed. A lawyer, executor, family member, employee, or other custodian may be trustworthy today but compromised, coerced, replaced, or involved in a dispute years later.
Dividing a secret between several people changes the risks rather than removing them. A fragment may be lost, one participant may become unavailable, the group may stop cooperating, or the fragments may be combined earlier than you intended.
This is the central difficulty of secure digital inheritance:
How can you prepare the transfer today without completing the disclosure today?
The recipient must eventually obtain the information, but nobody should need to keep a readable copy on their behalf while you remain in control.
A Different Model: Conditional Release of Encrypted Information
The Digital Heir is designed around that specific problem.
Instead of asking another person to hold your credentials in advance, you place the relevant information inside an encrypted Envelope. The Envelope may contain recovery phrases, passwords, private keys, server instructions, account details, or simply an explanation of what exists and where the next recovery step can be found.
You then define a Pipeline: a sequence of checks intended to establish whether you are still available.
A Pipeline might begin by checking your recent Telegram activity. If the expected activity is absent, the system can send a WhatsApp message and wait for your response. If you do not reply with the separate Okay Password, it can try another verified channel, wait again, and continue through the sequence you configured.
If you respond correctly, the Pipeline resets.
If every configured check fails, the system sends your selected heir a limited-time link through which they can attempt to decrypt the Envelope. The system does not transfer the external wallet, domain, account, or business itself. It transfers the protected information needed to discover or access it.
This produces a different relationship between the owner, the platform, and the heir.
You Define the Escalation Process
Apple uses documented death. Google uses account inactivity.
The Digital Heir allows the owner to define a sequence involving several signals, communication channels, and waiting periods.
One failed check does not have to release anything. An absence of recent social-media activity can trigger a direct message. The direct message can be followed by email. Each step can have its own delay, and a valid response can stop and reset the process.
The process establishes that the owner has failed to respond to the sequence of checks they configured. That is the technical condition they selected for sending the heir a link to the decryption page.
That makes the system relevant in many situations involving disappearance, incapacity, detention, loss of devices, or another prolonged inability to communicate.
No death certificate is required, and no employee manually decides whether the situation is serious enough. The configured Pipeline determines when the heir link is sent.
Nobody Needs to Hold the Readable Secret in Advance
Your heir does not need to even know that you selected them until the Pipeline finishes.
When they receive the link, they still do not receive the plaintext automatically. They must answer one of the personal questions you created for them. The questions are intended to refer to shared knowledge that is easy for the correct person to recall but difficult for an outsider to guess.
The service does not store those secret answers. The database contains the encrypted Envelope and the cryptographic material required for decryption, but it does not contain a copy of the answer.
The practical advantage is not that no living person can ever know the secret. You, as the owner, know what you placed inside the Envelope, and your heir may eventually decrypt it.
The advantage is that no additional person needs to act as a living custodian of the plaintext.
Neither your heir nor your lawyer needs to hold it in advance.
The transfer can be prepared without creating a readable duplicate in somebody else’s possession.
The Database Alone Is Not Enough
The Envelope is encrypted in the browser with a random data-encryption key. Additional protection is derived from the secret answer, and the protected key material is wrapped through external key-management infrastructure.
The service stores neither the plaintext Envelope nor the secret answers.
Decryption attempts are subject to online rate limits and application-level lockouts, preventing an attacker with only the database from testing unlimited guesses offline.
Multiple KMS providers are used as replicas to reduce dependence on one provider and improve availability. They are not three fragments that must be assembled; the security still depends on the answer-derived encryption layer, the protected KMS operation, and the enforced limits on guessing.
The purpose of this architecture is to prevent any one compromised component from being sufficient to reveal the Envelope.
An outsider should therefore be unable to test millions of possible answers privately without interacting with the live, rate-limited system.
The project is open source so that these claims and the relevant code paths can be examined rather than accepted only as marketing statements.
External security and cryptography audits remain part of the project roadmap, but The Digital Heir is already available to help you securely prepare the transfer of your digital assets today.