Cyclic Dependencies in Personal Security
In 2022, Terence Eden published a short essay titled I've locked myself out of my digital life. It described a hypothetical cascade: lightning strikes his house, destroying his phone and his fire-proof safe. His password manager needs a 2FA code from the phone. His TOTP backups live in cloud storage that requires the password manager. His handwritten recovery codes were in the safe. His emergency contact was his wife, who lost everything in the same event. He summarised it in a phrase that has stuck in security circles ever since:
"I am in cyclic dependency hell. To get my passwords, I need my 2FA. To get my 2FA, I need my passwords."
The lightning-strike scenario is hypothetical, but the underlying loop is not. Most people's recovery setups contain at least one cycle of this kind. They stay invisible during normal use, because in normal use everything works at once, and only surface when something has already gone wrong.
What a cycle is
A cycle in account recovery is a closed loop: A unlocks B, B unlocks A, and there is no path that doesn't pass through one of them. In normal use the loop is invisible. You already have access to both, so it doesn't matter which depends on which. The cycle only manifests under failure, and at that point it tends to be unrecoverable. The Bitwarden documentation puts this plainly: if recovery options don't grant access, "there is no way for Bitwarden to recover the account or its data." The same is true of most modern, end-to-end-encrypted services. By design, the vendor cannot help.
The four cycles most people actually have
In rough order of how often they cause real lockouts:
1. Email ↔ password manager. Your password manager (1Password, Bitwarden, Dashlane) requires email verification when you log in from a new device. Your email password is stored in the password manager. Lose the device, and recovery requires the email; the email requires the password manager. One user described exactly this on a community forum after their laptop died: "Can't get into my password manager or email because they're both locked behind each other."
2. Password manager ↔ its own 2FA. You enable 2FA on your password manager, which is the sensible thing to do. You generate the recovery codes and store them in the password manager. Now the codes that exist to recover the vault are inside the vault. A variant: you store the 2FA seed in an authenticator app (Authy, Google Authenticator) on a phone whose iCloud or Google account password is also in the vault.
3. Account ↔ recovery account. Two accounts list each other as recovery contacts. If both passwords are forgotten, or one provider locks an account and triggers verification on the other, neither resets. The arrangement is common because providers actively encourage it: most recovery flows ask you to nominate a second email, and most people supply the next-most-important account they own.
4. Phone ↔ everything. Your phone holds the authenticator app. Your phone's cloud account is recovered via SMS to that phone. The backup codes for that account are in your password manager. Your password manager is unlocked by 2FA from the phone. The graph closes on the phone, and the phone is the most-lost object you own.
These aren't edge cases. They are the default outcome of following common security advice ("use a password manager", "turn on 2FA", "set a recovery email") without explicitly mapping the resulting graph.
Why the cycles emerge
Account-recovery systems are designed as if each account stood alone. Each vendor's recovery flow assumes a working email, a working phone, a working second device. None of them check whether the other services in your life are reachable, because they have no way to. From the user's side, you only ever interact with one account at a time, never the whole graph. The shape of the graph only becomes apparent when something fails and you have to traverse it for real.
The deeper issue is that most recovery mechanisms are themselves just other accounts. A recovery email is an account. A recovery phone number is an account. A trusted contact is an account. Treating any of them as a root of trust is a category error, because they sit inside the same graph as the things they are meant to rescue.
What an acyclic plan looks like
The fix is not better hygiene inside the same graph. It is a root of trust that lives outside the graph entirely: something the recovery path can terminate at, with no further dependencies. A practical root of trust has three properties:
- Acyclic. Nothing inside it depends on the digital systems it is recovering. No vendor, no account, no device, no service that can be suspended or shut down.
- Durable. It survives the kinds of events that take out the rest of your systems: fire, theft, vendor shutdown, account suspension, the user's own forgetfulness over decades.
- Distributed. A single physical root is itself a single point of failure. The root must tolerate the loss of any one location or any one person.
Paper, stored well, satisfies (1) and (2). Threshold cryptography, specifically Shamir's Secret Sharing, adds (3): split the root key into m-of-n shares such that any m can reconstruct the secret but fewer than m reveal nothing. Distribute the shares across people, locations, and conditions of trust.
That is the design space PaperVault sits in. It is not a substitute for a daily-driver password manager; it is the layer beneath it, the place the chain terminates when every other recovery path has failed.
A small exercise
Independent of which tools you use, the exercise worth doing is this. Pick the three accounts you would lose the most by losing — typically email, primary password manager, and whichever account holds your financial life. For each one, write down what unlocks it on a brand-new device. Then write down what unlocks that. Keep walking the chain.
If the chain doesn't terminate at something physical, acyclic, and outside the digital graph, you have a cycle. You may not have found it yet.