Your API keys have a bus factor of one

API keys don't come with a succession plan. Your OpenAI account has credits sitting on it, your AWS root user has an admin key living in a .env file, and a cron job somewhere bills a card every month for a service only you remember signing up for.

Developers have a word for this: bus factor, the number of people who'd need to disappear before a project stops working. Most personal infrastructure runs on a bus factor of one. You.

Why this isn't hypothetical

GitGuardian's 2026 State of Secrets Sprawl report counted 28.65 million new hardcoded secrets pushed to public GitHub in 2025, a 34% jump over the year before. Most of those leak because a key ends up somewhere nobody was tracking. A key nobody else knows exists has the same root problem, just pointed at your own family or team instead of an attacker.

npm's policy is blunt about what happens next: account ownership can't be inherited. If you're the sole publisher of a package and you die, it keeps running until it breaks, and nobody can ship a patch unless you'd already named a co-maintainer while you were around to do it.

The most expensive version of this played out at QuadrigaCX. When founder Gerald Cotten died in 2018, he was reportedly the only person who could move funds out of the exchange's cold wallets, and roughly $190 million in customer crypto became unreachable. Court filings later surfaced other irregularities in how those wallets were run, but the underlying problem, one person holding the only working key, is the same one every solo developer and small team is carrying today, just at a smaller scale.

Handing over access isn't the fix either

In 2018, the maintainer of the popular npm package event-stream handed publish rights to a stranger who'd emailed asking for them. Two weeks later, code targeting Bitcoin wallets turned up in a dependency that millions of projects pulled in automatically. Access without context is its own kind of risk. What you actually want to leave behind is information, not a key in the wrong hands.

Big companies handle this by keeping two systems apart. A secrets manager decides who can touch a credential. A separate runbook or on-call doc explains what the thing is, why it matters, and what to do if the person who understands it best is unreachable. Neither system does the other's job on its own. A solo developer or a two-person team usually has the first part, a password manager, and nothing playing the second role.

What to write down instead of handing over

For each account: what it is, where the credential actually lives, never the credential itself, what it's worth, and what should happen to it: hand over, shut down, export, cancel the billing. The key stays exactly where it already is, in your password manager, a .env file, a hardware token.

LegacyApp holds the map, not the key: encrypted notes on your phone with a backup in your own Google Drive or iCloud, never on LegacyApp's servers. It checks in periodically, and only after your trusted friends confirm something happened does it hand your notes to the person you picked.

None of this needs a handoff ceremony or a shared root password. It needs one accurate note per account, written down before it's the only option left.