We enforced a password manager on a Friday. By Monday we had our first 2am lockout, and it taught us the rollout order we should have used.
This is the small-team version — no enterprise SSO, no security team, just a ten-person company that kept its shared logins in a spreadsheet called logins_FINAL_v3.xlsx.
What went wrong
The founder's vault was the only path to production. DNS registrar, email admin, cloud console — all in one personal vault, guarded by one phone. That phone was on a plane at 1:47am when the mail queue died. Recovery "existed." It required the other recovery admin to click a request and approve it. He was asleep. The click is a lockout with extra steps.
Half-migrated is the dangerous state. After week one, some passwords lived in the vault, some in the spreadsheet, some in both, and none of them had an owner of record. Nobody rotated anything, because nobody was sure which copy was the true one.
Shared logins in personal vaults. The billing portal was in the finance person's vault. She was on leave. The sticky note in the shared drive had the old password, which of course still worked on the old billing portal, which is how we spent 40 minutes resetting a password for an account we'd migrated.
Scripts in a human vault. Someone "secured" the CI token by putting it in their vault. The token then expired while that person was sick, and nobody else could see or rotate it. Deployments were down longer than the incident.
The order we use now
- Break-glass first, passwords second. Two recovery paths that don't share a phone, time-delayed emergency access (granted automatically if unanswered — configure it, then wait out the delay once on a test account so you know the real number), and a printed emergency kit stored like any other secret. Test the lockout path on day one. This is the step that prevents the 2am lockout.
- Inventory before import. Every login, who holds it, whether it's reused, what breaks if it's lost. The inventory is the rollout — skip it and you're importing chaos into a nicer interface.
- Pilot with two volunteers and the worst passwords. Import theirs, then rotate the three most dangerous ones (registrar, email admin, cloud root) during the pilot. A pilot that retires a reused password proves the tool. A pilot that only adds convenience proves nothing.
- Shared logins go in shared collections. Never personal vaults. Named access, split by system, not by person.
- Enforce with a date. Announce the spreadsheet's decommission date, keep it, archive it read-only. Enforcement without a date means "we use a password manager" and "we use a spreadsheet" stay simultaneously true for years.
- Wire offboarding the same week. Shared-collection access revoked in the same hour as email. It's a two-minute edit — if it takes longer, your collection structure is wrong.
The maintenance that keeps it true
- Monthly, 15 minutes: the vault's health report — reused, weak, no-MFA. Three fixes a month beats an annual purge nobody finishes.
- Quarterly, 30 minutes: shared-collection access review, one break-glass drill, and the export test — download the vault export, verify it decrypts, store it with your backups.
- The insight that stuck: a password manager doesn't remove lockout risk, it concentrates it. The rollout's real job is building the recovery paths first and enforcing second.
We packaged our incident-response and ops material for small teams at HIVE80lab:
- 🆓 The First 30 Minutes — free one-page incident quick-start checklist
- 📦 Ops Starter Kit — $14, incident response for small teams
- ⚙️ Automation Starter Pack — $19, pick-first workflows
Launch week: 30% off with code HIVE-LAUNCH30.
The full page (lockout scenarios, service-account rules, maintenance pass) is on our ops-notes site: Password Manager Rollout for Small Teams
Top comments (0)