Bitcoin Account Dependency Decay Patterns

Account Dependency Decay in Recovery Paths

This memo is published by CustodyStress, an independent Bitcoin custody stress test that produces reference documents for individuals, families, and professionals.

Cloud Storage That No Longer Exists

Bitcoin custody often depends on accounts that holders do not think of as part of their custody system. Email addresses for exchange logins. Cloud storage for encrypted backups. Phone numbers for two-factor authentication. Password managers for credentials. Authenticator apps for verification codes.

These accounts have their own lifecycles. Providers change policies, delete inactive accounts, or discontinue services. Phone numbers get reassigned. Devices get lost. Two years, five years, ten years after setup, the account infrastructure surrounding Bitcoin custody may have disintegrated without anyone noticing. This memo examines what happens when account dependencies decay.

---

Cloud Storage That No Longer Exists

A seed phrase stored in cloud storage is only as durable as the account that holds it. Cloud storage depends on active accounts, continued service availability, and policies that may change without warning.

A holder uploads an encrypted copy of his seed phrase to a free cloud storage service. He sets it and forgets it. The service is acquired by another company five years later. Existing accounts are migrated to a new platform. Users are notified via email. The holder does not check that email address anymore—he switched to a different provider years ago. His account is flagged as inactive during the migration. Ninety days later, the account and its contents are deleted. He does not know this has happened. He believes his backup is secure in the cloud. It no longer exists.

A holder stored an encrypted backup in a cloud service he stopped using. He switched to a different provider years ago. The old account sat dormant. The service eventually shut down entirely—the company was acquired and discontinued the product. The backup vanished with the service. The holder did not notice because he had moved on. His heirs never knew the backup existed.

---

Phone Numbers as Decaying Dependencies

Phone numbers appear permanent but are not. Carriers reassign numbers after periods of inactivity. Numbers tied to prepaid plans disappear when the plan expires. International moves can make domestic numbers inaccessible. The phone number that anchors a recovery flow may not exist or may belong to someone else by the time recovery is attempted.

A holder configured two-factor authentication using a phone number. The number was later canceled and reassigned. A later access attempt depended on that number, causing the custody path to stall when the dependency no longer resolved.

A holder dies. Her daughter knows the exchange account exists. She has the password from her mother's notes. She tries to log in. The account requires a verification code sent to a phone number. The phone was a prepaid device that ran out of credit and was deactivated a year before her mother died. The number no longer routes anywhere. The daughter contacts the exchange. The exchange has procedures for deceased account holders, but those procedures require documentation the daughter does not have. The recovery stalls.

---

Email as the Single Point of Failure

Many custody paths depend on email for continuity. When email access fails, other services that depend on it can also become inaccessible.

A holder used one email address for everything: exchanges, wallets, cloud storage, password manager recovery. That email account was protected by two-factor authentication tied to an authenticator app on his phone. His phone was lost. The authenticator app had no backup. The email account became inaccessible. With the email inaccessible, he could not reset passwords or verify identity on any of the services that depended on it. His entire digital custody infrastructure collapsed because one email account was unreachable.

A holder's email provider changed its terms of service after she died. The provider began requiring periodic logins to maintain accounts. No one logged into her account. The account was flagged as inactive. The provider's policy was to delete inactive accounts after a warning period. The warning went to the inactive account itself—where no one would see it. The account was deleted. Her exchange accounts, which required email verification for any changes, became permanently locked to her heirs.

---

Identity Verification After Death

Account recovery often requires proving you are the account holder. After death, no one can prove they are the account holder because the account holder no longer exists. Heirs can prove they are heirs. That is a different claim. Many account providers have no process for converting "I am the heir" into "I can access this account."

After death, account providers may restrict or close accounts rather than transfer access. When email access cannot be obtained, downstream services that depend on it can remain blocked even when legal authority exists elsewhere.

An executor contacts a cloud storage provider. The deceased holder stored a seed phrase backup there. The executor has letters testamentary proving legal authority over the estate. The provider requires the executor to submit a formal legal request through specific channels. The executor does so. The provider responds that they can confirm an account exists but cannot provide access without a court order specifically naming the provider and the account. The executor returns to probate court. The court is unfamiliar with cloud storage access requests. The process takes a year. The seed phrase sits in cloud storage, visible on the account if anyone could log in, inaccessible while legal processes grind forward.

---

Authenticator Apps Without Backup

Two-factor authentication using authenticator apps generates codes on a specific device. If that device is lost, broken, or wiped, the codes cannot be generated elsewhere—unless backup codes were saved or the authenticator was synced to another location. Many users do not configure backups. The authenticator becomes a single point of failure that travels with the device.

A holder used an authenticator app for his exchange account, his email, and his password manager. The app was on his phone. He did not save backup codes. He did not enable cloud sync for the authenticator. His phone fell into a lake. The phone was destroyed. He bought a new phone. The authenticator app on the new phone was empty. He could not access his exchange account without the authenticator. He could not access his email without the authenticator. He could not access his password manager without the authenticator. Every recovery path led back to codes he could no longer generate.

A holder dies. Her son finds her phone. The phone is locked with a passcode no one knows. The phone contains the authenticator app that generates codes for her exchange account. The exchange requires the code to log in. The son cannot unlock the phone. He contacts the phone manufacturer. The manufacturer will not unlock the device. He contacts the exchange. The exchange will not bypass two-factor authentication without the code or extensive identity verification. The authenticator app is inches away, behind a passcode that died with his mother.

---

The Hidden Dependency Chain

Account dependencies are often invisible until recovery is attempted. The holder knows how to access their accounts because they traverse the dependency chain routinely. They do not document it because it feels obvious. After death, the chain becomes a puzzle with missing pieces.

A holder's Bitcoin is on an exchange. The exchange login requires a password stored in a password manager. The password manager requires a master password and two-factor authentication. The two-factor authentication uses an authenticator app. The authenticator app is on a phone protected by a PIN. The phone's PIN was never written down. The holder knew the PIN. No one else did. The entire chain—exchange, password manager, authenticator, phone—is inaccessible because one four-digit number was never recorded.

A holder stores her seed phrase in an encrypted file in cloud storage. The encryption password is stored in a password manager. The password manager is accessed via a browser extension tied to her user profile on her laptop. The laptop requires her fingerprint to unlock. After she dies, no one can provide her fingerprint. The laptop remains locked. The password manager remains inaccessible. The encryption password remains unknown. The seed phrase file sits in cloud storage, encrypted, unreachable.

---

When Providers Disappear

Account providers are companies. Companies shut down, get acquired, change policies, or discontinue products. An account that exists today may not exist in the form it exists today five years from now. The provider's lifecycle becomes part of the custody system's lifecycle.

A holder used a small cloud storage startup to store his seed phrase backup. The startup offered free storage with a clean interface. Five years later, the startup ran out of funding and shut down. Users were given thirty days to download their data. The holder had stopped checking that account. He missed the notice. His backup disappeared when the servers went offline.

A holder used an exchange that was later acquired by a larger company. The larger company migrated accounts to a new platform. The migration required users to re-verify their identity. The holder had died before the migration. His heirs did not know about the account. They discovered it years later while reviewing old tax documents. They contacted the new platform. The new platform had no record of the account—migration had failed for accounts that did not complete re-verification, and data for those accounts had been purged.

---

Time as the Decay Mechanism

Account dependencies decay over time. The longer the gap between the holder's last access and the recovery attempt, the more opportunity for accounts to be deleted, numbers reassigned, providers changed, or policies updated. Custody systems that work today may not work in ten years—not because of anything the holder did wrong, but because the external accounts they depend on have changed.

A holder set up his Bitcoin custody in 2015. He used the email provider, cloud service, and exchange that were popular at the time. By 2025, one provider has been acquired, one has changed its terms of service to require annual login, and one has discontinued support for his country. His custody setup, unchanged since 2015, now has three broken links. He discovers this only when he tries to access his Bitcoin for the first time in years.

A holder dies in 2024. Her heirs begin the recovery process in 2026. During those two years, her email provider deleted her account for inactivity. Her phone carrier reassigned her number. Her cloud storage provider changed its deceased-user policy to require court orders instead of death certificates. Each month of delay introduced new obstacles. The custody system that existed at her death no longer exists two years later.

---

Summary

Bitcoin recovery often depends on accounts the holder did not think of as part of their custody system: email addresses, cloud storage, phone numbers, password managers, authenticator apps. These accounts have their own lifecycles. Providers delete inactive accounts. Phone numbers get reassigned. Companies shut down or change policies. Authenticator apps generate codes only on specific devices that can be lost or locked.

When these account dependencies decay, the recovery path collapses. The Bitcoin remains on the blockchain, unchanged. The credentials to access it were stored in or routed through systems that no longer exist or no longer recognize the holder's identity. The failure is not a missing seed phrase or forgotten password—it is the disintegration of the infrastructure the holder built around their custody without realizing that infrastructure had an expiration date.

---

System Context

Bitcoin Custody Failure Modes

Bitcoin Custody When a Device Is Lost or Fails

Only One Person Knows Bitcoin Password as Single Point of Failure

← Return to CustodyStress