Where your team actually keeps its secrets

A few weeks ago I sat in on a handoff between two operations leads, and the outgoing one pasted a tidy little spreadsheet into a Slack DM with the words “everything you need is in here.” I asked what was in it, and he said with no shame at all, “everything you need.”

That spreadsheet had the domain registrar, the payment processor, two cloud consoles, and three SaaS admin logins, all sitting in a chat thread that was going to live there until someone got around to deleting it. That is not a password problem; that is a storage problem.

So here is the thing leadership teams keep getting wrong. The shared credentials live wherever someone wrote them down first, and that is almost always somewhere with no access controls, no audit log, and no way to take a login back after a person leaves.

Spreadsheets, chat threads, sticky notes, a “passwords” page in a shared notebook; none of those are wrong because they are unsophisticated, they are wrong because they are the layer where a secret is stored, and that layer has the wrong properties.

It is worth saying out loud why this keeps happening. Nobody picks a spreadsheet because they think it is a great idea; they pick it because at 4:55 on a Friday, when someone needs the login to ship something, the spreadsheet is the only thing already in front of them.

The decision was made years earlier when the team did not put a vault in place, and every subsequent handoff inherits that gap.

The correct answer is a shared password vault. Bitwarden if you like open-source, 1Password if you want the cleanest experience, or Dashlane if your org already lives in it; pick one and stop comparing them.

All three give you zero-knowledge encryption, which means the vendor cannot read your passwords even with a subpoena. They also give you team-level grant and revoke, which is the actual mechanic you need, and you should turn on MFA on the vault itself because the vault is now the keys to the kingdom.

Here is what I would actually do, with a couple of hours and the team that runs the business. Open the vault, create a team, then migrate the highest-blast-radius credentials first, which means the domain registrar, the primary email account, and the payment processor, in that order.

Turn on MFA on each of those underlying services as you go, then start moving the long tail of SaaS admin logins one by one. The whole exercise is not a project, it is an afternoon.

The objection that comes up is always the same. “We don’t have time,” which is fair; the team is busy, and every fractional engagement starts in the middle of something already in motion.

But the cost of not doing this is not the spreadsheet sitting there benignly, the cost is the next handoff, the next departure, the next person who copies the spreadsheet to their personal laptop, and the next vendor breach that exposes a password that was reused on something more important.

So the move is not a security program, and it is not training, and it is not a policy document. The vault comes first.

Leadership teams that get this one piece right end up with a credible foundation for everything else, and leadership teams that skip it end up with a binder of policies sitting on top of a spreadsheet that anyone in the company can still open.