The keys only I hold

Every founder is told about the bus factor, and the version they are told is about knowledge: what would the company lose if you were unreachable for a month. For an engineer-founder that framing misses the sharper problem. Knowledge can be written down, and most of mine is in repositories and runbooks. Credentials cannot be written down, or rather they can, and then they are a different problem. The dangerous list is not the things only I know how to do. It is the keys only I hold, and among those, the ones that can never be reissued.

More of us than there were

This is not a niche worry. Carta's solo founders report puts the share of new startups on its platform led by a single founder at 35 percent in 2024, more than double the share in 2015, with 17 percent in 2017 and 29 percent in 2023. A third of new companies now start with one person holding every credential, and the data also shows those companies are less likely to raise venture capital, which is to say less likely to acquire the second and third pairs of hands that would otherwise dilute the problem by accident.

Sort by irreversibility

The instinct is to delegate the credentials you use most, because those are the ones whose absence would be felt first. That is the wrong sort key. The right one is what happens if the credential is lost or its holder is unreachable, and specifically whether it can be reissued, by whom, and how long that takes. I keep the list as a ladder with four rungs.

At the bottom, credentials recoverable in hours by anyone with an email address: a chat admin login, a SaaS dashboard, most vendor consoles. Losing them is an afternoon. Above that, credentials recoverable in days through a support process with identity checks: the cloud account's root user, a registrar account, an Android app's upload key, which Google's Play App Signing lets a developer reset through a request. Above that, credentials recoverable only with the cooperation of a specific institution and a specific person, such as a company bank mandate or a signing authority registered to one name. And at the top, credentials that cannot be reissued at all: an Android app signing key from before Play App Signing, a wallet's seed, a certificate authority's root, an encryption key protecting data that has no other copy.

The rule is to delegate from the top rung down. The bottom rung barely needs a plan; a shared inbox for password resets covers it. The top rung needs a ceremony, because there is no recovery, and the ceremony has to happen while the founder is present, well, and not in a hurry. Most founders do the opposite, sharing the dashboards because a colleague asked for access and never touching the signing key because nobody asked.

What I did with the top rung

Eight Android apps ship from the SocialSure account, and the first thing the ladder changed was to move as many of their keys off the top rung as possible. Apps enrolled in Play App Signing have their app signing key held by Google, and what I hold is an upload key, which is a days-rung credential with a documented reset. That one enrolment demotes a key from never to days, and it is the single highest-value move available to any Android developer who has not made it.

For what remains on the top rung, the answer is split custody, and the tool is Shamir's secret sharing, which I have used in applied cryptography work and which is simpler than its reputation. The secret is split into three shares such that any two reconstruct it and any one alone reveals nothing. One share stays with me, one goes to a second person the company trusts, and one goes to a third party with no operational role, a lawyer or a family member, with written instructions. No single share is useful, no single person is a point of failure, and reconstruction needs two people to agree that it is time.

Why frequency of use is the wrong sort

It is worth saying why the instinct to delegate by frequency fails, because it fails in a way that feels like success. The credentials used every day are the ones colleagues ask for, so they get shared, and the sharing feels like progress on the bus factor. But daily credentials are almost always on the bottom two rungs: if the person holding them vanished, a password reset or a support ticket would restore access within the week. The company would be inconvenienced and would survive. The credentials on the top rung are used rarely, sometimes once a year at a key rotation or an app's first release, and nobody asks for them because nobody needs them, until the day they are the only thing that matters and the only person who held them cannot be reached.

The ladder inverts the priority on purpose. The rarely used, never-reissuable key gets the ceremony first. The daily dashboard gets a shared inbox last. Done in that order, the exercise front-loads the one hour of work that cannot be done after the fact, and leaves the easy hours for whenever they happen.

The limit the ladder taught me

The escrow has a failure mode that the cryptography does not cover, and it is the one I nearly built. A split key does not help if the process to reassemble it is also only in the founder's head. Which tool reconstructs the shares, in what format, on which machine, with what verification that the result is the right key, what to do with the key once it exists, and whom to tell: all of that is a procedure, and a procedure known to one person is a top-rung credential wearing a different costume. So the ceremony produces two things, the shares and a written, rehearsed runbook, and the runbook is tested by the second person reconstructing a dummy secret without me in the room. The first rehearsal found four steps I had never written down.

The same limit applies one rung lower. A cloud root credential in a password manager is only delegated if the second person can open the password manager, which means the password manager's own recovery is on the ladder too, and so is the phone that receives its second factor. The ladder is recursive, and the way to stop the recursion is to reach a rung where recovery goes through an institution rather than a person, and to make sure the institution has a second name on file.

The list, once

The exercise is a single afternoon: write every credential the company depends on, put each on a rung, and for each rung write who else can act and how. The top rung gets an escrow and a rehearsed runbook. The next gets a second named person at each institution. The lower rungs get a shared inbox. Then the list is reviewed whenever a new credential is created, because every new key arrives on some rung, and the ones that arrive on the top rung are the ones that will matter on the day nobody can reach me.