Rolling out a password manager for a 5-person business

Why this matters to you

Your 2-minute quick win

Open your team chat and send this line now: ‘From today, we will stop sending passwords in chat or email. Put new work passwords in the password manager only.’ Success looks like a clear reply from each of the five staff members that they understand the new rule.

In a five-person business, weak password habits spread fast. One person reuses a favourite password. Another writes one in a notes app. A third sends a shared login by email. Soon, the same few passwords protect email, accounting, cloud storage, and admin tools.

The UK National Cyber Security Centre says people often cope with too many passwords by reusing them or choosing common ones. Attackers exploit exactly those workarounds. A password manager gives staff a safer way to create and store credentials in one vault, protected by one master password.

This matters even more in a small team because each person often has broad access. The owner may manage banking, payroll, supplier portals, and website hosting. One office manager may touch invoices, HR files, and customer email. If one reused password is stolen, the damage can spread across many accounts.

The same source also stresses usability. If the tool is hard to use, staff will ignore it and old habits will stay. For a five-person rollout, the best choice is usually the one that works on the devices and browsers your team already uses and makes saving, generating, and filling passwords easy.

What you are protecting

You are protecting the accounts that keep the business running day to day. That includes work email, file storage, invoicing tools, banking access, domain registrars, social media, website hosting, and supplier portals.

You are also protecting shared operational access. The NCSC says password sharing is not recommended, but some organisations still face cases where it happens. In a very small business, that often means a shared social account, a registrar login, or a hosting account used by more than one person.

You are protecting the difference between personal and work logins too. Some enterprise password managers offer personal vaults as well as work vaults. The NCSC warns that work passwords should not be accessible from the home vault and vice versa, and that it should be very difficult to save a password to the wrong vault by accident.

Finally, you are protecting the quality of future passwords. Many password managers can generate random passwords and highlight password reuse. That means the project is not only about storing old passwords in a nicer place. It is about changing how the team creates passwords from this point onward.

What it costs you if you skip this

If you skip a password manager, staff usually keep doing what feels easiest. They reuse passwords, choose short memorable ones, or store them in scattered files. That leaves attackers with simple paths into several accounts at once.

You also lose visibility. The NCSC notes that password managers can help you understand how passwords are used in your organisation. Without one, a small business owner often does not know which staff member holds which login, which passwords are shared, or which old accounts still exist after someone changes role.

Recovery gets messy too. When passwords live in browsers, notebooks, chat threads, and memory, a leaver or an urgent reset becomes a scramble. People waste time hunting for the current password, guessing which version is real, and changing accounts one by one.

Skipping MFA on the password manager adds another cost. The NCSC says MFA should be used on all cloud-sync password managers, and wherever the manager stores passwords for privileged or sensitive accounts. Without MFA, an attacker who gets the master password may reach the whole vault with no second barrier.

There is also a hidden cost in poor tool choice. If the manager does not support your team’s platforms or key browsers, staff will fall back to insecure workarounds. That means you pay for a tool and still keep the old risk.

Step by step

1. List the five people and the devices they actually use: for example Windows laptop, MacBook, iPhone, or Android phone, plus their main browser such as Chrome, Microsoft Edge, Firefox, or Safari. Done correctly looks like one short table that shows every staff member, device, and browser on one page, because the NCSC says platform and browser support are key checks before rollout.

2. Choose the password manager type. If people need the same passwords on more than one device, pick a cloud-sync manager rather than an on-device manager. Done correctly looks like a written note that says why you chose cloud-sync or on-device, based on how your staff work.

3. Check the vendor page for multi-factor authentication, browser extension support, password generation, security auditing, data export controls, update process, and account recovery. Done correctly looks like a shortlist where each feature is marked yes, no, or unclear, with unclear items removed from consideration.

4. Reject any option that does not work on all current and intended platforms used by the team. Done correctly looks like every staff device and browser from step 1 being covered, with key features such as auto-fill available where people log in most often.

5. Decide your recovery position before you create accounts. The NCSC warns that recovery methods can be exploited to gain access to credentials, especially if the service provider is responsible for recovery. Done correctly looks like a simple rule in writing: either no recovery beyond the user’s decryption key, or a named admin-led recovery method that you accept after weighing the risk.

6. Turn on MFA for every password manager account as part of setup, not later. Done correctly looks like each user seeing the vault sign-in protected by the master password and a second factor, because the NCSC recommends strong user authentication for cloud-sync managers.

7. Create one short business password rule and send it to the team. Use plain words: unique password for each work account, generate new passwords in the manager, no passwords in email or chat, and use MFA where offered. Done correctly looks like one message everyone can save, not a long policy nobody reads.

8. Install the app and browser extension on each person’s main work device first. Done correctly looks like the extension icon visible in the browser toolbar and the user signed in to their vault on that device.

9. Add the highest-risk accounts first: work email, domain registrar, website hosting, finance tools, cloud storage, and any admin account. When changing a password, use the manager’s password generation feature rather than typing one yourself. Done correctly looks like a saved entry in the vault and a successful sign-in with the new generated password.

10. Separate shared passwords from individual passwords if your product supports shared groups or shared vaults. The NCSC says users should be able to see the difference between shared and individual passwords. Done correctly looks like staff seeing clearly whether an entry is shared or personal before they open it.

11. For each shared account that must exist for now, limit access to the smallest set of people who need it. Done correctly looks like only named users having access, with the admin able to add or remove people and the system logging who accessed the shared password and when, if the product offers that feature.

12. Test auto-fill on real sites your team uses every day. The NCSC says the manager should only offer credentials for the site they are saved for and should never offer all stored credentials to any website visited. Done correctly looks like the right login appearing on the right site, and nothing unrelated being offered elsewhere.

13. Run the manager’s built-in password audit or health check if it has one. The NCSC notes that some managers can indicate password quality, warn about reused passwords, and flag compromised services. Done correctly looks like a short list of reused or weak work accounts that you can fix next.

14. Set one export rule on day one. Because exported passwords may become plain text, the NCSC says export should be protected, and an administrator should be able to disable or audit it where supported. Done correctly looks like a clear instruction that nobody exports vault data unless a named owner approves it for migration.

15. Write a joiners and leavers note for your five-person team, even if nobody is leaving now. Include who removes access, which shared passwords must be changed, and how admin rights are reviewed. Done correctly looks like a short checklist stored with your business procedures.

Illustrative example

Emma runs a five-person design studio. Before the rollout, her team reused a few familiar passwords across email, file storage, supplier portals, and the website host. One freelancer had once been sent the hosting password by email, and nobody was fully sure whether it had been changed since.

Emma started with a simple inventory. She wrote down each person, their devices, and their browsers. Two staff used Windows and Chrome. One used macOS and Safari. Emma used an iPhone as well as a laptop. Her operations lead used an Android phone and Microsoft Edge.

That list pushed her toward a cloud-sync password manager. An on-device product would not fit the way the team moved between laptops and phones. She then checked whether the product supported MFA, browser extensions, password generation, security auditing, and clear separation between shared and individual passwords.

Before creating accounts, Emma made one decision about recovery. She knew recovery can reduce the pain of a forgotten master password, but the NCSC warns that recovery methods can also create a path to the vault. She chose a product whose recovery approach matched the team’s risk tolerance and wrote down who would manage it.

Next, Emma created accounts for all five staff and required MFA during setup. She did not leave it for later. Each person signed in with a master password and then added the second factor. Emma watched until each person could lock the vault, unlock it again, and see that the vault opened only after both steps worked.

Then the team installed the browser extension on their main browser. Emma asked each person to save one low-risk account first, then fill it again from the vault. They could see the extension offer the right credentials on the right website. That small success built trust before they touched more sensitive systems.

After that, Emma tackled the most important accounts in order. First came work email. Then cloud storage. Then the domain registrar. Then the website host. For each account, the team changed the password using the manager’s generator and saved the new credential straight into the vault. They stopped typing memorable words and dates.

For the website host and a shared social account, Emma used the manager’s shared access feature. The two people who needed those accounts received access. The three who did not need them never saw them. Emma also checked that staff could tell shared entries from their own individual entries at a glance.

At the end of the afternoon, Emma ran the manager’s audit view. It showed which work passwords were still reused and which old entries still needed replacing. She made a short follow-up list for the next day. By close of business, the riskiest accounts had unique passwords, the vaults were protected with MFA, and passwords were no longer moving around by chat or email.

The near-miss

Now replay Emma’s day with one skipped check. This time, she does not test auto-fill on real sites. A staff member visits a lookalike page after clicking a bad link in a hurry. The extension does not offer the saved password, because the site is not the one the credential was saved for.

That was the warning sign. But the staff member is used to old habits. Instead of stopping, they open an old note, copy a password, and paste it into the fake page. Because that reused password also works on the email account, the mistake creates a much bigger problem than a single bad login page.

The concrete lesson is simple. If the manager does not offer the credential on the site you expected, stop and check the address rather than bypassing the tool. One skipped usability check can send a user back to unsafe workarounds in the very moment the tool was meant to help.

How to check it worked

Start with behaviour, not just installation. Ask each of the five staff members to sign in to one normal work account using the manager. If they can unlock the vault, use the saved credential, and complete the login without looking elsewhere, the basic habit has started to stick.

Next, inspect your highest-risk accounts. Work email, registrar access, hosting, and finance tools should now have unique passwords generated by the manager. If you still find a familiar old password reused across more than one of those services, the rollout is not finished.

Check MFA on the vault itself. Each staff member should need the master password plus the second factor to access the cloud-sync vault. If one user can still log in to the manager with only a password, fix that before moving on.

Check shared access carefully. People should be able to see which entries are shared and which are personal. Only the staff who need a shared account should have access. If your product offers logs for shared passwords, confirm that access is being recorded.

Check export controls and admin rights. If your chosen manager allows export, make sure staff know your export rule. If you use an enterprise-style admin role, confirm that administrator access is audited and that admins cannot see individual passwords unless they are part of a shared password group, as described by the NCSC.

Finally, ask one simple question: did this reduce workarounds? If staff still keep passwords in notes, spreadsheets, or email drafts, you have not completed the rollout. The NCSC is clear that security benefits are lost when users do not find the tool useful and usable.

Test yourself

Question: When is a cloud-sync password manager usually a better fit than an on-device manager?

Answer: When staff need the same passwords on more than one device, such as a laptop and a phone.

Question: What should you require on all cloud-sync password manager accounts?

Answer: MFA, so the vault needs the master password and a second factor.

Question: What should you do if the manager does not offer a saved password on a site you expected?

Answer: Stop and check the site address instead of copying a password in by hand.

Common mistakes

Picking a tool before checking devices and browsers is a common mistake. The NCSC says missing platform support pushes users into insecure workarounds. In a five-person business, one unsupported Mac or one missing Safari extension is enough to break consistency.

Turning on the manager but not MFA is another mistake. The vault becomes a very attractive target because it can contain access to many accounts. MFA adds a second barrier that the NCSC recommends for all cloud-sync managers.

Some teams import passwords but never change the worst ones. That keeps the old risk alive inside a new tool. The first afternoon should always include changing passwords for the most important accounts, using the generator rather than recycling something memorable.

Another mistake is treating shared passwords as normal. The NCSC does not recommend sharing passwords between individuals, even if many organisations still face situations where they have not yet moved to better alternatives. If sharing must exist for now, keep it visible, limited, and easy to revoke.

Ignoring export risk is also dangerous. A plain text export is useful for migration, but once exported, those passwords are unprotected. If you allow export with no rule, you create a fast path for accidental loss or malicious copying.

Finally, do not overcomplicate the master password policy. The NCSC warns that policies which place a huge burden on users encourage insecure workarounds. The whole point of the manager is to reduce daily memory load while still improving password quality across services.

Level up

Once the basic rollout works, take one concrete next step: choose a business or enterprise tier if you need centralised management. The NCSC notes that enterprise solutions are usually a paid service and can add useful controls such as an overview of which accounts are in a user’s vault, visibility of a user’s password audit score, shared-password access control, and the ability to mandate MFA for the vault.

For a five-person business, that matters most when one owner or operations lead needs a clean joiners and leavers process. Centralised visibility makes it easier to remove access, change shared passwords, and support staff who still have reused passwords left in their vault.