Getting a Small Team Onto a Password Manager

The shared spreadsheet is the visible part. Underneath it sits the real problem: a small set of passwords used across everything, known to everybody who has ever worked here, and impossible to change because nobody knows what would break if they did.

A password manager fixes that in a specific way. Every account gets its own long random password that nobody memorises, so somebody else's breach stops being your breach. Changing one password becomes a two minute job rather than a project with a risk register.

For a small team the second benefit matters as much as the first. You end up with a record of which accounts exist. Most businesses cannot answer that question at all, and it is the question that decides how long an offboarding takes and how expensive an investigation gets.

Set the expectation before you start. There is a fortnight of low grade annoyance, and after that the daily experience is quieter than what you have now. Most of the people who resist the change stop noticing it within a month of the switch.

It ends password reuse, which is what turns a leak at some service you signed up for years ago into a takeover of your email today. That alone justifies the licence for most teams.

It also gives you an anti phishing benefit that people underrate. The browser extension fills a password only on the domain it was saved against. On a convincing lookalike it does nothing at all, and that silence is a signal a tired person will notice when a well built login page is not.

What it does not do is worth saying plainly. It does not replace multi factor sign in. It does not stop somebody being talked into approving a payment. It does not protect an account whose live session was stolen from a browser after the person signed in properly. Treat it as one layer among several. It also does not repair a habit of pasting credentials into chat. Every one of these products has a way to share a secret properly. People have to use it, and somebody has to say something the first few times they do not.

The differences that matter for a small team are few. Shared vaults with access granted per group. An administrative route to recover a user's vault when they are unreachable. An activity log. A clean way to remove a leaver and keep what they held. Apps on the platforms your people actually use. And an export in a standard format.

That last item is the one nobody checks and the one that matters most in the long run. Export is your escape hatch. A manager you cannot leave owns your credentials rather than the other way round. Test the export during the trial, not two years later when you have a reason to move.

If you already run a single sign on platform, prefer a manager that connects to it, so joining and leaving flow through the process you already have. If you do not run one, do not buy one just to get there. The manager on its own is a large improvement.

Self hosting is offered by several products and is usually the wrong choice for a small team. You take on patching, backups and availability for the system holding every credential you own. Choose it deliberately, with a named person who will maintain it, or do not choose it.

Running the spreadsheet and the manager side by side feels safer and is the reason most rollouts never finish. Pick a date. Import everything. Then delete the spreadsheet, including its version history and the copies sitting in people's mailboxes.

Then rotate. Everything that lived in that file has been through email, through chat, through somebody's downloads folder and quite possibly a screenshot. Importing it does not make it secret again. Rotate the important accounts first: banking, domain registrar, DNS, payment processing, the email platform, and anything a customer can see.

Do the import as a working session rather than as an instruction. Book an hour with each person, sit with them, move their browser saved passwords into the vault, then clear the browser store while you are there. Left to themselves most people will do about half of it and then stop.

Turn off the browser's own password saving through policy afterwards. Otherwise you will have two stores again by the end of the quarter, and neither of them will be complete.

Structure the shared vaults around the work rather than around who happens to hold something today. One for finance. One for the website and hosting. One for marketing tools. One for infrastructure, restricted to the people who genuinely need it.

Personal work vaults stay personal, and anything shared goes into a shared vault from the first day. The credential that lives in one person's private vault is the credential you will be hunting for during their notice period.

Apply the same restraint you would apply to file permissions. Not everybody needs the vault with the payment gateway in it. Access to a vault is access to every secret inside it, and vault sprawl is much easier to prevent than to unwind.

Write down what each entry is for in the notes field, including which system it belongs to and who the account is registered under. A vault full of usernames with no context is only slightly better than the spreadsheet was, and the person who inherits it will be grateful.

There is usually one, and often it is the founder. They also tend to hold the most valuable credentials in the company: the bank, the domain, the app store account, the payment processor. They have a system that works for them and no interest whatsoever in your project.

Arguing about security does not work here, because they already know that argument and have already discounted it. What works is continuity. If you are unreachable for a week, who renews the domain. If your phone goes into the sea, who gets into the bank. Nobody has an answer, and that is a business problem rather than an IT preference.

Then do it with them in one sitting instead of sending instructions. Start with the accounts they open every day, so the first thing they experience is autofill making their morning quicker. Leave the awkward ones for a second session. Do not lecture, and do not touch anything personal unless they ask you to.

Make the emergency access arrangement explicit, whether that is the product's emergency contact feature or a sealed record held by a second director. Written down, tested once, reviewed when people change. That is usually the part that finally convinces the holdout.

This is where the manager earns its licence fee, and it only works if the structure was set up beforehand. On the day, the account is suspended, ownership of their vaults transfers to their manager, and their device sessions are revoked. That part takes minutes.

Then rotate everything they could reach. Not because you suspect them of anything. A shared credential carries no record of who used it, so after a departure you can no longer say who holds it. The vault tells you exactly which entries were within their reach, and that list is your rotation list.

Watch for the private vault problem. Where somebody stored a shared credential in their personal vault, it leaves the building with them. An administrative recovery feature covers that case, and finding out whether your product has one is a job for this week rather than for the week somebody resigns.

For a sudden or unhappy exit, run the same steps in a different order. Suspend first, rotate the critical accounts immediately, work through the rest during the day. Have that sequence written down in advance, because it is not a day for inventing procedure.

The master password becomes a single point of failure, and for personal vaults most products cannot recover it by design. Business plans generally offer administrative recovery. Turn it on, and make sure everyone understands what it means: an administrator can, through a defined process, reach a user's work vault.

Keeping the second factor seed in the same manager as the password is convenient and puts both factors in one place. For most small teams the trade is worth making, because in practice the alternative turns out to be codes written on paper. Decide it consciously, and keep your highest value accounts split across two devices.

A manager cannot help with accounts it does not know about. Run a discovery pass now and then using browser sign in reports, expense claims and the list of applications connected to your email platform. New accounts appear constantly, and the ones that never reach the vault are exactly the ones that survive an offboarding.

It also does nothing about business data sitting in a personal account somebody set up years ago. That is a separate job, and it usually surfaces during the migration. One more reason to migrate in a single push rather than gradually.