How to Configure a Password Vault

Who This Guide Is For

This guide is for operations leads and IT managers who have decided to implement a password vault and need to set it up properly. You are replacing an informal system (credentials in spreadsheets, email threads, messaging apps, or people’s memories) with structured, encrypted credential management.

Before You Start

You should have your vault system selected or built. This guide covers configuration and migration, not selection. You should also have a list of the team members who will need access and a rough idea of which credentials they currently use. If you are still evaluating whether you need a vault, What Is a Password Vault covers the concept.

Step 1: Design Your Folder Structure

Before adding any credentials, plan how they will be organised. The structure should match how your team thinks about credentials, not how the vault software defaults.

The most common and effective structure is by client or project, with a shared folder for internal credentials:

• Internal: company-wide credentials (hosting accounts, shared tools, infrastructure)
• Client A: all credentials related to Client A’s systems
• Client B: all credentials related to Client B’s systems

Within each folder, group by system type if the client has many credentials: hosting, CMS, email, APIs, third-party tools. For clients with fewer than ten credentials, a flat list within the client folder is simpler and easier to scan.

Do not over-engineer the structure. Three levels deep is the maximum before navigation becomes frustrating. If you need more depth, your folders are too granular.

Step 2: Define Access Roles

Decide who can see what before adding anyone to the vault. Role-based access is the difference between a vault that improves security and a shared spreadsheet with encryption. For a full treatment of how to structure access roles across systems, How to Implement Role-Based Access Control covers that in detail.

Common role structure:

• Admin: can manage users, create folders, and see all credentials. Limit this to one or two people.
• Project member: can view and use credentials for the projects they are assigned to. Cannot see other projects.
• Read-only: can view credentials but not edit them. Useful for stakeholders who need access but should not be changing passwords.

The key principle: access should follow project membership. If someone is working on Client A’s project, they see Client A’s credentials. When they are removed from the project, their access is revoked. This prevents the accumulation of access that makes offboarding difficult.

Test the access model with a real scenario before rolling it out: “If a developer joins Client B’s project, what credentials do they automatically see? What should they not see?” If the answer does not match your configuration, adjust the roles.

Step 3: Migrate Existing Credentials

Gather every credential that currently exists across your organisation. This is the step that takes longest because credentials are scattered. Check:

• Shared spreadsheets and documents
• Email threads (search for “password”, “login”, “credentials”)
• Messaging app history
• Browser saved passwords on shared machines
• Physical notes or documents

For each credential, record: the system it accesses, the URL, the username, the password, and who currently has access. Then enter them into the vault under the appropriate folder.

Verify each credential works as you migrate it. Migrating a stale password means migrating a problem. If a credential does not work, update it at the source and enter the correct one. This is the best opportunity you will have to clean up your credential inventory.

Step 4: Rotate Compromised and Shared Credentials

Any credential that was stored in a spreadsheet or sent over email should be considered compromised. After migrating it to the vault, change the password at the source and update the vault entry.

Prioritise by risk: hosting and server access first, then admin panels and CMS logins, then third-party tool accounts. You do not need to rotate every credential on day one. Work through the list over the first two weeks, starting with the most sensitive.

Going forward, establish a rotation schedule. Credentials for critical systems should be rotated every 90 days. Credentials for lower-risk systems can rotate every six months. The vault should make rotation painless: change the password at the source, update the vault entry, and everyone with access automatically sees the new credential.

Step 5: Onboard the Team

Give each team member their vault account with appropriate role assignments. Walk them through the three actions they will use daily: finding a credential, copying it, and (for those with edit access) adding or updating one.

The critical adoption message: the vault is the only place credentials live now. Emailing a password, sending it over chat, or saving it in a browser is no longer acceptable. This is a security policy change, not just a tool change. Reinforce it in the first two weeks by redirecting any credential shared outside the vault: “I have added this to the vault under [folder], please access it there.”

Disable or delete the old credential stores once migration is complete. Archive the spreadsheet. Delete the shared document. If the old store remains accessible, people will use it out of habit.

Common Mistakes

• No folder structure before adding credentials. Dumping hundreds of credentials into an unstructured vault creates the same findability problem as the spreadsheet it replaced. Design the structure first.
• Everyone gets admin access. Admin access means access to everything. Most team members need project-level access only. Over-permissioning defeats the purpose of the vault.
• Migrating without verifying credentials work. A vault full of stale passwords is a vault nobody trusts. Verify each credential during migration.
• Not rotating after migration. If a credential was in a spreadsheet for two years, moving it to a vault does not undo the exposure. Rotate it.
• No enforcement of the new policy. If the team can still email passwords without consequence, the vault becomes optional. Make the vault the only accepted method from day one.

What Good Looks Like

A well-configured vault looks like this: every credential is in one place, organised by client or project. Team members see only the credentials they need for their current work. When someone leaves, their access is reviewed and revoked within the hour. Credentials are rotated on a schedule, and the audit log shows who accessed what and when. Nobody emails passwords. Nobody stores them in spreadsheets. The vault is the single source of truth.

Next Steps

If the vault is part of a broader system rollout, How to Roll Out a New Internal System covers the deployment process. For the system-level view of what a password vault does and why it matters, see Password Vault System. The vault also fits into a broader Security Hardening programme if credential management is one part of a larger security review. For other Implementation Guides, or if you want the vault built and configured for you, get in touch.