By David,
Ask ten MSPs where they keep client passwords and you'll hear ten different answers: a business password manager, the vault inside their documentation platform, a privileged access tool, a spreadsheet nobody admits to, or some mix of all four. Every one of them is holding the same thing: the keys to every client they serve.
This guide is for working out where those credentials should live. It covers why MSP credential stores are a prime target, the four kinds of tool MSPs use, the controls that matter whichever you pick, and the question most comparisons skip: where the data physically lives and who else could reach it. It's vendor-neutral until the section on Atlas Vault. For everything else a client record should hold, see MSP documentation best practices.
The short version: store as few standing credentials as you can (use GDAP, Windows LAPS and per-client admin accounts instead), and keep the rest in a store with per-client isolation, an audit record of every reveal, MFA through your own identity provider, rotation tracking and a tested break-glass plan. Then decide whether that store should sit in a vendor's cloud or in an Azure tenant you control.
The threat model: why MSP credential stores are a prime target
An attacker who breaks into one business gets one business. An attacker who breaks into an MSP's credential store gets every client at once. That leverage is why governments now publish guidance aimed squarely at MSPs.
In May 2022, the cybersecurity agencies of the US, UK, Australia, Canada and New Zealand issued a joint advisory, Protecting Against Cyber Threats to Managed Service Providers and their Customers. Several of its recommendations are about credentials: don't reuse admin credentials across customers, put MFA on every account with access to customer environments and treat those accounts as privileged, apply least privilege, and log the activity of the tools you use to deliver services.
Three public incidents show why:
- MSP tooling as the delivery route. In July 2021, attackers exploited Kaseya's on-premises VSA remote monitoring product and pushed ransomware through it. Kaseya put the direct impact at fewer than 60 of its customers, many of them MSPs, and fewer than 1,500 downstream businesses (CISA guidance for affected MSPs). That was a remote management tool, not a password vault, but it's the clearest example of one MSP tool reaching many clients at once.
- The password manager's own update channel. In April 2021, attackers compromised the in-place upgrade mechanism of Click Studios' Passwordstate, an on-premises enterprise password manager. For about 28 hours, customers who upgraded received a malicious DLL that collected stored entries, including usernames, URLs and passwords. Click Studios told affected customers to reset every password stored in the product (Malwarebytes).
- The vendor's cloud backups. In 2022, LastPass disclosed that an attacker had copied a backup of customer vault data. Website URLs in it were unencrypted. Usernames, passwords and notes were encrypted with keys derived from each user's master password, which LastPass doesn't hold (LastPass notice). Strong encryption held, but a stolen encrypted vault can be attacked offline for as long as the attacker likes, so its safety rests on how strong each master password was.
The lesson isn't "never use tool X". Each of those products was run by a competent vendor. The lesson is that every place a client credential lives is part of your attack surface: the vendor's cloud, its update channel, its backups, and your technicians' laptops. Fewer copies, in places you can see and audit, is the goal.
Before choosing where to store a client credential, ask whether you need to store it at all. The safest credential is one that doesn't exist.
First, store fewer credentials
A lot of what MSPs keep in vaults no longer needs to be a shared, standing password:
- Microsoft 365 and Azure admin access. Use granular delegated admin privileges (GDAP) through Partner Center instead of a stored global admin account in each client tenant. GDAP is least-privilege and time-bound, and each technician signs in as themselves.
- Local administrator passwords. Windows LAPS rotates each device's local admin password automatically and backs it up to Microsoft Entra ID or Active Directory. That removes the classic MSP mistake of one local admin password across a whole client.
- Named accounts over shared ones. Wherever a system supports per-technician accounts with MFA, use them. A shared credential can't tell you who used it.
What's left is the genuinely shared material: firewall and switch admin logins, line-of-business app accounts, vendor portals, Wi-Fi keys, service accounts, API keys, and the break-glass accounts you hope never to use. That is what the rest of this guide is about.
The options
MSPs typically choose from four kinds of credential store. They're not mutually exclusive, and plenty of MSPs run two.
1. A business password manager
Products such as 1Password, Bitwarden and Keeper are built around end-to-end encryption: entries are encrypted on the user's device with keys derived from the user's own secret, so the vendor stores ciphertext it can't read. Several offer MSP or provider consoles for managing many client organizations.
- Strengths: strong client-side encryption, excellent browser autofill, easy for end users, mature mobile apps.
- Weaknesses for MSP work: the credential sits apart from the documentation that explains it, so the firewall password is in one tool and the firewall runbook is in another. Licensing is usually per user. The encrypted data lives in the vendor's cloud, unless you choose a self-hosted edition where one exists.
2. The vault inside your documentation platform
IT documentation platforms such as IT Glue and Hudu include a password store next to configurations, contacts and runbooks.
- Strengths: the credential is next to the asset and the procedure it belongs to, which is what a technician needs at 2 a.m. Organized by client from the start.
- Weaknesses: encryption is typically server-side, so the platform holds the keys. IT Glue is SaaS in its vendor's cloud. Hudu also offers a self-hosted option, which moves the data but makes you responsible for running it. Our Atlas AVD vs IT Glue comparison covers the trade-offs in detail.
3. A privileged access management (PAM) tool
Enterprise PAM products such as CyberArk, Delinea Secret Server and BeyondTrust go further than storage: they check credentials out and back in, rotate them automatically against the target system, broker remote sessions so the technician never sees the password, and record those sessions.
- Strengths: the strongest controls available, including automatic rotation and session recording.
- Weaknesses: cost and complexity. They're built for large enterprises with dedicated identity teams, and they often need connectors or agents in each client environment. For a small or mid-sized MSP, a PAM rollout can become the project.
4. A vault in your own Azure tenant
The fourth option keeps the credential store inside cloud infrastructure you own. That can be as raw as Azure Key Vault itself, a self-hosted password manager on your own virtual machines, or a platform that deploys its application and database into your subscription.
- Strengths: you choose the region, the network exposure (including private endpoints), the backup policy and who has Azure access. Sign-in goes through your own Microsoft Entra ID and Conditional Access policies. Logs land in your workspace.
- Weaknesses: you own the operations. Raw Key Vault is built for application secrets, not for technicians browsing a client's credentials alongside its documentation. A self-hosted password manager is another server to patch.
| Business password manager | Documentation platform vault | PAM tool | Vault in your own tenant | |
|---|---|---|---|---|
| Where the data lives | Vendor's cloud (or self-hosted, where offered) | Vendor's cloud (or self-hosted, where offered) | Usually your infrastructure or the vendor's cloud | Your Azure subscription |
| Who holds the keys | Derived from each user's secret | Usually the platform | Varies | You (Key Vault) or the app you run |
| Next to the documentation | No | Yes | No | Depends on the tool |
| Automatic rotation against the target | Limited | Limited, often an add-on | Yes, a core feature | Depends on the tool |
| Session brokering and recording | No | No | Yes | Rarely |
| Typical pricing | Per user | Per user | Per user or per target, plus services | Azure consumption plus any software |
| Effort to run | Low | Low (SaaS) | High | Medium |
The must-haves, whichever you choose
Whatever the product, hold it to these five controls.
Per-client isolation
A technician working on Client A should not be able to see Client B's credentials by accident, and a compromised account scoped to one client should not expose the others. Check how the isolation is enforced. A folder or tag is a convenience. Separate vaults, separate permission scopes, or separate databases per client are a boundary. Ask the vendor which one you're getting.
An access log you'd be happy to hand to a client
Every reveal, copy, edit and share should be logged with who, what, when and from where. Two details separate a good audit trail from a decorative one: whether a reveal is recorded before the secret is returned (so a logging failure can't produce an unlogged reveal), and whether the log can be altered by an administrator. When a client asks "who has looked at our domain admin password this year?", you want a complete answer.
Rotation reminders, and real rotation where possible
Every credential should carry a last-changed date and a rotation interval, with the store warning you before it lapses. True automatic rotation, where the tool changes the password on the target system itself, is a PAM strength and is rarer elsewhere. At minimum, rotate after every staff departure and after any incident.
MFA, enforced by your identity provider
The store must require MFA, and ideally it uses your own Microsoft Entra ID sign-in, so Conditional Access, phishing-resistant methods, device compliance and sign-in risk apply to it the same way they apply to everything else. A separate username and password for the vault is one more credential to protect. The 2022 joint advisory is explicit that accounts with access to customer environments should have MFA and be treated as privileged.
Break-glass access that doesn't depend on the vault
Plan for the day the vault is unavailable: an outage, a lost identity provider, a ransomware incident. Microsoft's own guidance for emergency access accounts is a useful model: at least two cloud-only accounts, phishing-resistant authentication such as FIDO2 security keys, excluded from Conditional Access policies that could lock them out, every sign-in alerted on, and tested at least every 90 days. Keep their credentials physically separate from the vault they're meant to rescue. Also keep a protected offline export of the most critical client credentials, and know who is allowed to open it.
Three smaller things matter too: secure sharing (time-limited, revocable links rather than passwords pasted into email or chat), sensible offboarding (removing a technician's access in one place, ideally by disabling their directory account), and import and export (you shouldn't be locked in).
Where the data lives, and who could reach it
Most comparisons stop at features. For a credential store, location matters just as much, because it decides who else could be asked for your data, or could lose it.
Who holds a copy. With a SaaS password manager or documentation platform, your clients' credentials live in the vendor's cloud, encrypted, alongside many other customers' data. With a vault in your own tenant, the copy lives in a subscription you control, in a database that holds only your data. Fewer organizations holding a copy means fewer places it can leak from.
Who holds the keys. End-to-end encrypted password managers derive keys from each user's secret, so the vendor can't decrypt your vault even if compelled to hand it over. Server-side encryption, which most documentation platforms use, means the platform can decrypt. Where you use your own key in your own Azure Key Vault, you can see every use of it, and revoke it.
Who could be compelled to hand it over. Data held by a provider can be requested from that provider. In the United States, the CLOUD Act of 2018 covers electronic evidence held by US-based providers regardless of where it's stored (US Department of Justice). Microsoft is a US provider too, so hosting in your own Azure tenant doesn't put data beyond the reach of law; what it changes is that there's no extra third-party vendor in the chain, and no vendor-held key to decrypt with. If your clients have data residency or sovereignty requirements, the same thinking applies to credential stores as to any other data.
Who could breach it. A popular SaaS vault is a high-value target because it holds many customers' secrets at once. A vault in your own tenant is a smaller target, but its security now depends on your Azure hygiene: who has Owner on the subscription, whether the database and Key Vault are on private endpoints, and whether you'd notice an unusual sign-in. Why Atlas AVD runs inside your Azure tenant goes through that trade in more depth.
How Atlas Vault handles credentials
Atlas Vault is the credential store and IT documentation registry built into Atlas AVD. It takes the fourth approach: a vault in your own Azure tenant, next to the documentation it belongs to. Security claims are the ones most likely to be over-read, so here is exactly what it does, including what it doesn't.
Where it lives. Atlas AVD deploys its application, an Azure Database for PostgreSQL server and an Azure Key Vault into your own Azure subscription. Vault data is stored in that database. In an MSP deployment, every client tenant you manage gets its own PostgreSQL database with its own scoped database role, so one client's credentials aren't rows in the same tables as another's. Vault contents are never sent to the Atlas control plane, the central service that handles licensing, updates and support.
What's encrypted, and with whose key. Atlas encrypts each credential's secret, its TOTP seed and the secret fields on assets in the application, with AES-256-GCM, before they're written to the database. By default the encryption key is derived from a deployment key that's generated when Atlas is deployed and stored as a secret in your Key Vault. You can go a step further and point Atlas at an RSA key in Azure Key Vault: each secret then gets its own random data key, wrapped by your Key Vault key (RSA-OAEP-256), and if Key Vault can't be reached, Atlas refuses to read or write secrets rather than falling back. Usernames, URLs, notes, documents and the other registers aren't encrypted by the application; they're protected by Azure's encryption at rest for the database and by Atlas's access controls.
Atlas Vault isn't zero-knowledge. The application decrypts secrets on the server when an authorized user reveals one, which is what makes server-side audit, rotation and secure sharing possible. The flip side is that your Azure access control is part of the vault's security: anyone with enough rights over the app and its Key Vault in your subscription could reach the key. Keep Owner and Key Vault access on that subscription tight, and consider the private-endpoint option for the database and Key Vault.
Who can see what. Credential lists always show masked values. Revealing a secret, copying it or showing a TOTP code is a separate action, and for company credentials it's limited to Atlas administrators. Credentials in My vault are visible only to their owner and the people the owner grants, and administrators can't open them. In a multi-tenant deployment you can limit each technician to the client tenants they work on, and requests outside that scope are refused. Within a client tenant, access is set by role rather than per credential.
Every reveal on the record. Revealing, copying or generating a TOTP code writes an audit record before the secret is decrypted. If that record can't be written, the reveal is blocked. Each entry carries the user, the action, the credential, the time, the IP address and the browser. The audit tables are protected at the database level against updates and deletes, and entries are kept for 365 days. You'll find them on the Audit Log tab of the Audit page, filtered to Vault credentials, and you can export them to CSV, Excel or PDF for a client review.
MFA through your own directory. Atlas has no separate vault password. Users sign in with Microsoft Entra ID, so your MFA and Conditional Access policies apply to the vault as they do to everything else. For a stricter posture, turn on Re-authenticate to View Secrets. It's off by default. When it's on, users must have signed in again within the last 10 minutes before they can reveal, copy, rotate or share a secret.
Rotation reminders and rotation. Each credential has a Rotation Date and an Expiration Date. Atlas flags credentials whose last rotation is 90 days old or more, and emails you 30 days and 7 days before a credential expires, and again on the day. Rotate sets a new secret, generated or your own, keeps the previous versions in Version history, and lets you roll back. For credentials linked to a Microsoft Entra app registration, Atlas rotates the app's client secret automatically through Microsoft Graph, creating the new secret before it removes the old one. Atlas doesn't reset user, Active Directory or local administrator passwords on the target system. Use Windows LAPS for local administrator accounts.
Sharing without email. Secure Shares are links for a single credential or document. Each expires after between 1 hour and 30 days, can be one-time and passphrase-protected, and can be force-expired at any time. Atlas stores only a hash of the link's token.
Break-glass is yours to plan. Atlas Vault has no emergency-access feature, and its exports deliberately leave secrets out. That's the right default for a vault, and it means your break-glass plan lives outside it: emergency access accounts with FIDO2 keys in a safe, per Microsoft's guidance above.
Moving in. Atlas Vault imports credentials from CSV exports of LastPass, KeePass, 1Password and Bitwarden, from Azure Key Vault JSON, and from generic CSV or JSON.
Atlas Vault is included on every paid Atlas AVD plan from Starter up, including the MSP plans. If you're weighing it against a documentation platform specifically, read Atlas AVD vs IT Glue. For the full picture of what runs in your subscription and what reaches Atlas, read Why Atlas AVD runs inside your Azure tenant.
FAQ
What is the best password manager for an MSP?
There isn't one answer. Judge any option on per-client isolation, an audit record of every reveal, MFA through your own identity provider, rotation tracking and a break-glass plan, then decide where the data should live. A business password manager suits end-user passwords and autofill. A documentation platform vault keeps credentials next to runbooks. PAM tools add automatic rotation and session recording at a higher cost. A vault in your own Azure tenant keeps the data and keys in a subscription you control.
Is it safe to store client passwords in a documentation platform?
It can be, if the platform isolates clients, audits every reveal, enforces MFA and lets you see where the data lives and who holds the encryption keys. Most documentation platforms encrypt on the server, so ask how keys are managed and who could decrypt.
Should an MSP use the same admin password for multiple clients?
No. The 2022 joint advisory from CISA and its partner agencies tells MSPs not to reuse admin credentials across customers. Use separate credentials per client, Windows LAPS for local administrator accounts, and GDAP instead of standing global admin accounts in Microsoft 365.
Where should an MSP keep break-glass credentials?
Outside the system they're meant to rescue. Follow Microsoft's emergency access guidance: at least two cloud-only accounts per tenant with phishing-resistant authentication such as FIDO2 security keys, stored securely in separate locations, alerted on every sign-in and tested at least every 90 days.
Does Atlas Vault encrypt passwords with my own key?
Yes. Secrets are encrypted with AES-256-GCM using a key derived from a deployment key stored in your own Azure Key Vault. You can also configure envelope encryption with an RSA key in Azure Key Vault. Notes, usernames and documents aren't encrypted by the application; they rely on Azure's encryption at rest for the database.
Can Atlas staff see the credentials in my Atlas Vault?
Vault data is stored in the database in your Azure subscription, and Vault contents aren't sent to the Atlas control plane. Atlas staff have no Azure role on your subscription, and the Atlas application has no vendor remote-access path into your deployment.
Does Atlas Vault rotate passwords automatically?
For Microsoft Entra app registration client secrets, yes. For other credentials, Atlas tracks rotation dates, flags overdue ones, emails expiry alerts and records each manual rotation with version history. It doesn't change passwords on the target system itself.
Incident details in this article come from public sources, linked inline. Microsoft guidance is taken from Microsoft Learn as of October 2026. Atlas Vault behavior is described as of October 2026.