Managing credentials across dozens of client environments without a consistent system is a liability that most MSPs do not fully recognize until something goes wrong. A tech leaves with unrotated passwords in their head. A client gets breached and the audit trail shows credentials were shared by five techs. A password manager vault grows so large that finding the right entry takes longer than the reset would have.
Here is a framework that has worked for shops at the 20 to 60 client scale.
Layer 1: Client isolation
Every client gets its own isolated credential environment. No shared vaults across clients, no "general MSP" pool that holds records from multiple environments. This is not just a security requirement. It is a workflow requirement: when a tech is working a ticket for Client A, they should only ever see Client A's credentials in their context.
Cross-client credential leakage is one of the highest-risk events an MSP can trigger. It also creates compliance problems for clients in regulated industries. Isolation at the vault level removes the possibility of accidental exposure.
Layer 2: Type-based categorization within each client
Within each client vault, organize credentials by type: admin accounts, service accounts, network devices, cloud platforms, and client-specific applications. Use consistent naming. The format that has worked well is: [System/Platform] - [Account Type] - [Context]. For example: "Microsoft 365 - Global Admin - Break Glass" or "Cisco Meraki - Dashboard Admin - Production".
Consistent naming means a tech who has never worked the account can still find the right credential in under 30 seconds.
Layer 3: Rotation schedules tied to risk tier
Not all credentials carry the same risk. A break-glass admin account for a healthcare client and a local admin account on a workstation are not in the same category. Tier your credentials by risk and attach rotation schedules accordingly.
A simple tiering: Tier 1 (privileged admin, cloud platform root, network device management) rotates every 90 days. Tier 2 (service accounts, application integrations) rotates every 180 days. Tier 3 (standard user escalations, low-privilege service accounts) rotates annually or at offboarding.
Layer 4: Access control by role, not by person
Access to a client credential vault should be gated by role assignment, not by individual permissions. When someone joins or leaves the team, you update their role, and the access changes cascade automatically.
This also applies to access levels within a vault. Tier 1 credentials should require explicit senior tech or engineer role before access is logged. Tier 2 and 3 can be accessible to the full team with logging.
Layer 5: Audit logs that prove what happened
Every credential access event should generate a log entry that includes: who accessed, which credential, when, and from which ticket or session. This is not optional if you have clients in regulated industries. It is also the only way to answer "who had access to what" after a security event, which is the question every client will ask if something goes wrong.
The tool question
This framework can be implemented in a variety of tools, but the tool needs to support client isolation natively, not as a naming convention you maintain manually. If you are managing isolation by prefixing every vault entry with a client code, you are one naming error away from a cross-client exposure.
The tool also needs to integrate with your runbooks. A runbook step that says "reset the admin password" should be able to link directly to the credential it is describing, not require the tech to switch to a separate application and search.