At 30 clients, a shared spreadsheet has long since become unmanageable, and even a well-maintained password manager vault becomes a search problem. With 30 environments, each holding dozens of credentials, a flat list means navigating hundreds of entries to find the right one. The lookup time under incident pressure is unacceptable, and the risk of exposing one client's credentials while searching for another's is real.
Here is the organizational model that holds up at 30 clients and scales to 60.
One vault per client, not one vault for all
The foundational rule at this scale: every client gets a completely isolated credential environment. No shared pools, no cross-client folders, no "MSP general" vault. A tech working a ticket for Client A should be able to look at their screen and confirm, visually, that they are only seeing Client A's credentials. The risk of cross-client confusion is not theoretical at 30 clients. Naming conventions that looked fine at 10 clients start to collide at 30.
Isolation also simplifies compliance. When a client in a regulated industry asks you what credentials your team has to their systems, you should be able to pull a complete, accurate list in under two minutes. That is only possible if their data is isolated.
Three tiers within each vault
Within each client vault, use three tiers based on privilege and risk:
Tier 1: Privileged access. Global admin accounts, cloud platform root credentials, network device management access, break-glass accounts. These require explicit role authorization to view and generate an access log on every view.
Tier 2: Service accounts and integrations. API keys, service account credentials, backup tool access, monitoring agent keys. Access logged, viewable by full team with senior tech role for higher-risk items.
Tier 3: Standard access. Local admin credentials, application-specific logins, low-privilege service accounts. Access logged, viewable by full team with standard tech role.
Naming convention that survives staff turnover
Your naming convention needs to communicate the credential's identity to a tech who has never worked that client before. The format: [Platform/System] - [Account Type] - [Context/Qualifier].
Examples: "Microsoft 365 - Global Admin", "Cisco Meraki - Dashboard Admin - Production", "Veeam - Backup Service Account - PROD-SQL-01". The platform always first, so alphabetical sorting groups all Microsoft 365 credentials together. The account type second, so a tech can distinguish between admin and service accounts in a glance. The qualifier third for disambiguation within the same platform.
Rotation by tier, not by calendar
A single rotation schedule for all credentials ignores the risk profile difference between a cloud admin account and a local workstation account. Tier 1 credentials rotate every 90 days and on every offboarding. Tier 2 every 180 days. Tier 3 annually or at offboarding. Mark each credential with its tier and its last rotation date. Any credential past its rotation interval is visibly stale, not invisibly risky.
Access review on every offboarding
When a tech leaves your team, every credential that was in their access scope needs to be rotated. At 30 clients with hundreds of credentials, that is a significant task without a tool that can answer "what did this person have access to?" in seconds. Build your access control model so that question has a clear, auditable answer before you need it.