Password managers for shared responsibility

A password manager can remove the need to remember dozens of credentials and make committee succession less fragile. It should also make responsibility clearer. Putting every password in one vault that every member can open simply relocates an access problem.

Choose a setup with named users and a deliberate distinction between personal credentials and organisational secrets. Where a service offers individual accounts or delegation, use that feature. A shared vault is useful for credentials that genuinely need to be held by the organisation; it is not a reason to share every login.

Choose for the people who will use it

The NCSC password-manager buyers guide recommends considering usability, security and recovery together. Trial the product with your actual devices and working patterns. Ask a less confident user to save a new credential, find an existing entry and sign in from another supported device.

Check organisational administration, permissions, export, recovery and support in the proposed plan. Do not assume features shown in a demonstration are included in every edition. Ask what administrators can see or recover, and explain that clearly to users before adoption.

For a co-op using shared shop computers, test separate device user accounts and the lock behaviour between shifts. A vault left unlocked on a shared screen can expose credentials to the next person, regardless of how strong its encryption is.

Design a small set of vaults

• Personal work: the individual's work credentials, under the agreed organisational policy.
• Operations: limited shared credentials needed by current operators.
• Finance: credentials available only to authorised finance roles; respect each service's rules about named access.
• Administration: domain, hosting and other high-impact access for designated administrators.
• Emergency recovery: tightly controlled material with an explicit access procedure.

This is an illustrative structure. A three-person worker co-op may need fewer vaults, while a larger organisation will need more separation. Keep the explanation short enough that people can reliably choose the correct location.

Use entries with a service name, verified sign-in address, account purpose, owner and a brief note about dependencies. Do not store a long incident plan inside the only vault that becomes inaccessible during an incident. Put non-secret operating instructions somewhere authorised people can reach independently.

Plan recovery before importing everything

Identify what happens if someone forgets their primary password, loses a device or leaves unexpectedly. Recovery features differ: some allow an authorised administrator to assist, others depend on a recovery key or preconfigured emergency contact. Test the supported method on a trial account.

Protect the vault account itself using the strongest suitable sign-in options and tested recovery methods. Avoid a circular arrangement in which the only code needed to open the vault is stored inside the locked vault. Record who can authorise emergency access and how its use will be logged.

If you create an export for migration or continuity, understand its format. It may contain readable secrets. Restrict, encrypt where appropriate, account for and securely remove temporary exports after the agreed task. A forgotten downloads-folder copy can undermine the entire setup.

Introduce it with a practical exercise

1. Choose one ordinary service and one important administrative service for the pilot.
2. Create named vault users and grant only the needed access.
3. Save the verified login and generate a unique password where a password is still required.
4. Have a second authorised person find and use the appropriate organisational entry.
5. Try the recovery process and check the resulting notifications or logs.
6. Remove a test user and identify which known shared credentials would need changing.
7. Expand only after the participants can repeat the steps.

For an illustrative rotating committee, the website administrator can hold hosting access while the newsletter editor gets only the publishing tool. Both can work without being exposed to unrelated finance credentials.

Removing someone from the password manager does not make a password they previously saw unknowable. Include rotation of relevant shared credentials in your offboarding checklist. Review stale entries so the next person does not try an obsolete account during an emergency.

Use the technology health check to identify the credentials whose ownership and recovery need attention first.