Manage a shared credential vault for a distributed assistant team

Inventory the credentials the team actually uses

Start with the logins the team uses in a normal week, including the client's tools, the provider's tools, and the accounts that only one person touches. Ask each assistant to list the credentials they hold and where they are stored. The answer often includes a personal password manager or a note that no one else can see. A vault cannot govern accounts it does not know about.

Mark each credential as personal, shared, or service-level, because each type needs a different owner. Personal accounts should not be shared at all, while service accounts may need a rotation schedule. Record the client, the task, and the person who approves access. That map is the foundation for every later decision.

Choose one vault and one owner

Choose a single approved vault and make it the only place a shared credential may live. A second tool creates a shadow inventory that no one can audit. Name one owner who can add users, review access, and approve recovery. The owner should be a role rather than a person so the process survives a departure.

Set the vault's defaults before importing anything, including multi-factor authentication, session timeout, and a sharing policy. Turn on the audit log and confirm that it records views as well as edits. Review the defaults with the client's security contact. A vault with weak defaults is only a tidier version of the old spreadsheet.

Import credentials in a controlled pass and delete the old copies as each entry is confirmed. A parallel spreadsheet left active will be used during the first urgent request. Record the date each credential moved and who verified it. The migration is complete only when the old store is empty and disabled.

Group access by task, not by seniority

Create groups around the work, such as inbox triage, billing follow-up, or scheduling, and add people to the group that matches their tasks. A senior assistant does not automatically need every credential. Task groups make it obvious which access to remove when a duty ends. They also reduce the temptation to grant broad access for convenience.

Keep administrative, export, and billing rights in a separate group with a small membership. Review that group on a different schedule from the routine work. If a client tool does not support granular roles, add a compensating review step. The control should match the risk of the tool rather than the size of the team.

Set a joining and leaving routine

Write a short checklist for the first day and the last day. On the first day, create the named account, enroll the second factor, add the task groups, and record the approval. On the last day, remove the groups, revoke sessions, rotate shared secrets the person could read, and confirm the removal. Both checklists need an owner and a date.

Test the leaving routine before it is needed. Walk through the steps with a team member and note where the vault or the client tool blocks a clean removal. Some tools keep a session alive after a password change, so revoke sessions explicitly. A leaving routine that has never been rehearsed usually misses one of these steps.

Require multi-factor authentication and recovery proof

Require a second factor for every vault user and for the client accounts that support it. Prefer an authenticator app or a hardware key over SMS where the tool allows a choice. Store recovery codes in the vault under a separate restricted entry. The second factor protects the credential even when the password is exposed.

Test the recovery path for one account each quarter and record the result. A recovery process that no one has tried may depend on an old phone number or a departed employee. Keep the test non-disruptive by using a low-risk account. The goal is proof that the team can recover without bypassing the vault.

Rotate a shared secret after any view by someone outside the current task group, including a temporary helper. Rotation is cheap when the credential is in one place and expensive when it is scattered across notes. Update the dependent systems in the same window and confirm each one works. Record the rotation date so the next reviewer knows the age of the secret.

Review shared secrets on a schedule

Review the vault's membership and shared entries once a month and after any role change. Remove accounts that no longer match a task and rotate secrets that were viewed by someone who has left. Check the audit log for unusual views or failed attempts. A short review is more sustainable than an annual cleanup.

Ask the client whether their own access list matches the vault. A person removed from the vault may still hold a direct account that the client created. Reconcile the two lists and close the gap. The provider's vault and the client's identity system must tell the same story.

Plan for a locked-out assistant

Write what an assistant should do when a second factor is lost or a vault session fails during a client deadline. Name the vault owner, the client contact, and the temporary access path. Set a time limit for the temporary access and a review after it ends. A lockout handled by an unrecorded workaround defeats the vault.

Keep at least two people who can administer the vault and reach the client's security contact. One administrator is a single point of failure for the whole team. Document the escalation route in the same place as the task instructions. The plan is complete when a backup administrator can follow it without calling the owner.